Ich frage mich, wie Benutzer die Verwaltung von JNDI-Ressourcen über mehrere Instanzen ihres Tomcat Application-Servers hinweg verwalten. Nehmen wir zum Beispiel meine Datenbank-JNDI-Ressource. Es wird in meiner Datei /conf/context.xml und in den Verweisen aus meiner web.xml-Datei für Apps deklariert.
Diese JNDI-Ressource muss unabhängig auf meiner Entwicklungsbox, Staging-Box und Produktionsbox definiert sein. Was ist, wenn ich eine neue Instanz einer Entwickler- / Staging- / Production-Box einrichten möchte? Das bedeutet, ich muss den Ressourcennamen in der Datei context.xml für jede neue Instanz, die ich erstelle, neu erstellen. Aus Sicht der Einrichtung ist dies ein Ort, an dem ein menschlicher Fehler auftreten könnte, der dazu führen könnte, dass ein Anwendungsserver auf die falsche DB zeigt.
Ich finde das umständlich und verwirrend, da ich sowohl die Anzahl der Entwickler in meinem Projekt als auch die Anzahl der Produktionsserver, die ich verwenden kann, skaliere.
Machst du es einfach Teil deines Setups oder erstellst du ein Setup-Skript, das sich bei jeder erneuten Installation von tomcat und der Einrichtung einer Box darum kümmert? Oder gibt es eine andere Ebene der Indirektion, die dies erleichtern könnte?
Ich gehe davon aus, dass Sie für eine bestimmte Ressource in jeder Umgebung den gleichen JNDI-Namen verwenden. Andernfalls müssten Sie Ihren Code so bearbeiten, dass er auf den Namen der neuen Ressource (JNDI) verweist.
Die Einrichtung der Umgebung beim ersten Mal kann fast unmöglich vorher getestet werden. Es gibt keine Möglichkeit zu überprüfen, ob eine Zeichenfolge, wie die Produktionsdatenbankverbindungszeichenfolge, nicht fettfinged wurde, bis Sie sie tatsächlich verwenden müssen. Es ist die Natur der Umgebungskonfiguration. Wenn Sie die Wahrscheinlichkeit von Fehlern reduzieren möchten, müssen Sie zunächst sicherstellen, dass jeder Ressource ein Name zugewiesen wird, der unabhängig von der Umgebung verwendet wird, in der sie gehostet wird. Erstellen Sie einen dbConnectionString-Ressourcennamen in einer Eigenschaftendatei, die auf jndi: / jdbc / myproject / resources / dbConnectionString verweist, und stellen Sie sicher, dass alle Umgebungen dieselbe Ressource deklarieren. Im Folgenden haben wir den Code isoliert von diesen Arten von Umweltabhängigkeiten gehalten. Davon abgesehen müssen Sie immer manuell überprüfen, ob die Konfiguration eines bestimmten Servers die entsprechenden Werte für die definierten Ressourcen verwendet.
HINWEIS: nie Erstellen von Ressourcennamen wie " dbProdConnectionString ", " dbQAConnectionString ", " dbDevConnectionString ". Sie werden den Zweck besiegen, manuelle Eingriffe zu eliminieren, weil Sie dann einen Umleitungsschritt hinzugefügt haben, der eine Codeänderung (um den Code auf den richtigen Ressourcennamen zu verweisen) und Build (um die Änderungen in Ihre WAR-Datei zu packen) benötigt ) wenn Sie zwischen Umgebungen wechseln.
Wir haben eine Ordnerstruktur für die umgebungsspezifischen Eigenschaften erstellt. Unter diesem Ordner haben wir Ordner für jede spezifische Umgebung erstellt, die auf die Bereitstellung ausgerichtet ist, einschließlich der lokalen Entwicklung. Es sah so aus:
%Vor%In jedem Ordner legen wir parallele Kopien der Eigenschaften / Konfigurationsdateien ab und legen die verschiedenen Konfigurationen nur in der Datei im entsprechenden Ordner ab. Das Geheimnis bestand darin, den Klassenpfad der Implementierungsumgebung zu steuern. Wir haben auf jedem Server einen PROPERTIES-Klassenpfadeintrag definiert. Bei Prod würde es auf "$ ProjectDir / Properties / Prod" gesetzt werden, während bei Test die gleiche Variable auf "$ ProjectDir / Properties / Test" gesetzt wäre.
Auf diese Weise können wir Datenbankverbindungszeichenfolgen für die vorkonfigurierte dev / test / prod-Datenbank haben und müssen nicht jedes Mal in der Eigenschaftendatei auschecken / in die Eigenschaftendatei wechseln, wenn wir für eine andere Umgebung erstellen möchten.
Dies bedeutete auch, dass wir die gleiche .war / .ear-Datei für Test and Prod bereitstellen konnten, ohne sie neu zu erstellen. Alle Eigenschaften, die nicht in der Eigenschaftsdatei deklariert wurden, wurden auf ähnliche Weise behandelt, indem in jeder Umgebung derselbe JNDI-Name verwendet wurde, jedoch Werte verwendet wurden, die für diese Umgebung spezifisch waren.
Implementieren Sie mehrere Webanwendungen, die freigegebene Ressourcen verwenden müssen?
Wenn nicht, gibt es absolut keinen Grund, Ihre Ressourcen in /conf/context.xml zu deklarieren. Sie sollten stattdessen in einer separaten Datei für die Datei context.xml Ihrer Webanwendung deklariert werden, die in Ihrer WAR-Datei als /META-INF/context.xml bereitgestellt wird. Diese Datei sollte zusammen mit Ihrer web.xml in Ihr Quellcodeverwaltungssystem eingecheckt und als Teil Ihres Builds bereitgestellt werden - keinerlei manuelle Eingriffe.
Wenn Sie mehrere Webanwendungen mit freigegebenen Ressourcen bereitstellen, können Sie entweder eine benutzerdefinierte Ressourcenfactory schreiben, die dieselbe Ressource mehreren Webanwendungen zur Verfügung stellt (siehe Tomcat-Dokumentation , am Ende der Seite) und verwenden Sie den oben genannten Ansatz oder - zumindest für Entwicklungsumgebung - Sie können automatisch ändern (oder sogar ersetzen, wie Standard tut dies) nichts) /conf/context.xml als Teil Ihres Builds. Für den Produktionseinsatz ist das natürlich nicht empfehlenswert.
Wenn Sie das Springframework verwenden, können Sie dieses Problem sehr einfach mit PropertyPlaceholderConfigurer . Mit dieser Klasse können Sie die Definitionen in externe Eigenschaftendateien verschieben. Die Konfiguration der Datenquelle ist wie folgt:
%Vor%Die Eigenschaften selbst sind in einer Standard-Eigenschaftendatei definiert:
%Vor%Für die tatsächlichen Eigenschaften haben Sie zwei Optionen:
Fügen Sie die Eigenschaftendatei extern in das Dateisystem ein, sodass sie auf jedem Computer anders ist:
%Vor%Fügen Sie Ihrem Server die folgende Systemeigenschaft hinzu -Denv = [Entwicklung | Test | Produktion]. Fügen Sie dann drei Konfigurationsdateien in Ihr Verzeichnis WEB-INF / classes ein: jdbc-development.properties, test-development.properties und production-development.properties. Die Kontextkonfiguration lautet:
%Vor%Der Punkt von JNDI ist, dass umweltrespezifische Ressourcen unabhängig definiert werden. Ihre Entwicklungs-, Bereitstellungs- und Produktionsumgebungen sollten nicht dieselbe Datenbank teilen (oder JNDI wurde in jedem Fall so konzipiert, dass für jede Umgebung separate Datenbanken zugelassen sind).
Wenn Sie auf der anderen Seite versuchen, mehrere Tomcat-Server zu laden, und Sie wollen, dass alle Instanzen die gleiche Konfiguration haben, würde ich denken, dass Sie Ihre context.xml immer teilen können und die gemeinsamen Bits in a gemeinsame Datei Hier ist die Tomcat-Dokumentation, die über context.xml spricht .
Wie Sie diese verwalten, bleibt Ihnen überlassen. Es kann einfach sein, wie beispielsweise eine "template" context.xml-Datei, die Sie jedes Mal mit dem Erstellen einer neuen Tomcat-Instanz beginnen (diese in einem Quellcodeverwaltungssystem, insbesondere in einem verteilten System, kann hilfreich sein). Oder Sie könnten ein Skript schreiben, um dies zu tun.
Wenn Sie mehr wollen, glaube ich, dass es Produkte gibt, die ein nettes UI um den gesamten Prozess legen. Eine, die meiner Meinung nach SpringSource tc Server ist.
Meine Lösung bestand darin, alle Definitionen in eine server-template.xml -Datei zu schreiben und dann eine clevere XSLT-Transformation zu verwenden, um das endgültige server.xml für jede Instanz zu generieren. Ich benutze eine Ameisen-Build-Datei, um alle Dateien für eine Tomcat-Installation zu kopieren, und lasse ein server.xml aus der Vorlage erstellen. Alles ist in CVS gespeichert, sodass ich die Installation schnell wiederherstellen kann, ohne befürchten zu müssen, dass etwas nicht funktioniert. So sieht die Vorlage aus:
Wie Sie sehen können, definiere ich die Standardeinstellungen und spezialisiere dann die Einstellungen. In der Umgebung überschreibe ich dann einige Dinge (lokales System bekommt einen kleineren Pool als Produktions- und Integrationstest).
Das Filterscript sieht so aus:
%Vor%Wenn Sie ein entferntes JNDI-Verzeichnis an Tomcat's "globales" JNDI-Verzeichnis binden können, könnten Sie diesen Mechanismus verwenden: Verwenden einer JNDI-Datenquelle, die von einer anderen Anwendung mit Tomcat erstellt wurde
Grüße.
Tags und Links tomcat jndi deployment production-environment