property-Konfigurationsdatei für webApp(war) - wohin) - /conf/Catalina/<host>/ ?

[dermoritz]

Ich habe leider kaum Ahnung von der Konfiguration und dem Betrieb von Web-Servern. Ich baue eine Webanwendung wleche ein properties-Datei benötigt um bestimmte Ressourcen zu finden.
Aus meiner Sicht gehört die Datei in das Wurzelverzeichnis der Webanwendung also bei Tomcat:
tomcat/webapps/meineAnwendung/config.porperties

Ist das so? Bzw. wünscht sich ein Betriebler nun, dass ich diese unter /conf/Catalina/<host>/ ablege. Macht das Sinn? den "<host>" müsste ich ja dann wissen und fest in meiner Anwendung verdrahten? Der ORdner scheint für eine andere sorte Dateien gedacht zu sein oder?

 

[fastjack]

Aus meiner Erfahrung kann ich sagen, daß die Betriebler keine Props anpassen wollen. Schreib doch eine kleine JSP-Seite, die die Installation durchführen kann und die Einstellungen dann in einer DB, oder sonstwo speichert (ähnlich wie MediaWiki).

 

[nillehammer]

Ist das so? Bzw. wünscht sich ein Betriebler nun, dass ich diese unter /conf/Catalina/<host>/ ablege. Macht das Sinn? den "<host>" müsste ich ja dann wissen und fest in meiner Anwendung verdrahten?

Nein, es macht keinen Sinn, sie dorthin zu legen.

Wo man sie am besten hinlegt, hängt davon ab, was Du konfigurieren willst. Z.B. Hibernate oder log4j erwarten die Dateien ja an einer ganz bestimmten Stelle (innerhalb des Anwendungsordners).

Eigene properties Dateien würde ich mit in die Packages der Anwendung legen. Sie gehören ja schließlich zur Anwendung. Auf die Weise kannst Du völlig unabhängig von physischen Dateipfaden oder virtuellen Hosts/Anwendungspfaden zugreifen (nämlich als Classpath Resource). Außerdem ist auch sicher gestellt, dass sie bei einem build im war-File landen und damit auch mit deployt werden, wenn es Änderungen gab.

Der ORdner scheint für eine andere sorte Dateien gedacht zu sein oder?

Ja

 

[dermoritz]

Danke für die Infos.

Im Moment ist die Properties-Datei in der war. Sie muss zum anpassen herausgeholt und dann wieder reingepackt werden - das wollen die Betriebler nicht (kann ich verstehen).
(diese Datei enthält urls(loakale), pfade, username/ pw usw.)
Deswegen finde ich sie herauszuholen nicht schlimm - solange sie in einem Pfad relativ zur Anwendung selbst ist Anwendung/config.properties oder Anwendung/conf/config.properties

 

[nillehammer]

Im Moment ist die Properties-Datei in der war. Sie muss zum anpassen herausgeholt und dann wieder reingepackt werden - das wollen die Betriebler nicht (kann ich verstehen).

Kann ich auch verstehen. Ich würde an einer Produktivanwendung nicht herumbasteln. Es muss dafür meiner Meinung nach immer ein Releasezyklus durchlaufen werden. Ein Workaround wäre, den Webcontainer so zu konfigurieren, dass er das war auspackt (Stichwort: Exploded). Aber auch das ändert nichts daran, dass man in der Produktionsumgebung eher nicht quick and dirty an Dateien rumspielen sollte.

Anwendung/conf/config.properties

Würd ich nicht machen. Die Datei ist ohne weitere Schutzmaßnahmen für den Endnutzer der Anwendung mit seinem Browser direkt aufrufbar. Das will man ja im Zweifel eher nicht. Außerdem kriegst Du nur über das Filesystem Zugriff. Besser ist der Ordner WEB-INF/classes (oder in irgendeinem jar unter WEB-INF/lib) also wie schon geschrieben irgendwo da, wo auch die Java-Klassendateien liegen. Dann kannst Du auf die properties-Datei als Klasspathresource zugreifen. Da können Dir dann physische Ordnerstrukturen völlig egal sein.

 

[dermoritz]

ok, im moment ist die Datei in web-inf/classes (die war-datei wird ja beim deployment ausgepackt). Das Problem ist nur, das der Deployvorgang scheitert, da die Anwendung nicht korrekt konfiguriert ist (es sei denn man ändert die properties vorher in der war-Datei).

Also dein Vorschlag ist, die Datei da zu lassen wo sie ist [war|appOrdner]/web-inf/classes/? Oder gibt es eine Alternative dies es dem Betrieb etwas leichter macht?

 

[nillehammer]

Mir ist überhaupt nicht klar, warum der Betrieb nach dem Deployment Deiner Anwendung noch in Konfigurationen rumfummeln muss. Eine fertige und vollständige Webanwendung muss direkt nach dem Deployment laufen.

Wenn Der Betrieb die Hand auf irgendwelchen Passwörtern für Resourcen (Mail, Datenbanken) oder so hat, die er nicht rausgeben will, dann bietet es sich an, den Zugriff auf diese Resourcen über den Container (Tomcat) managen zu lassen. Das kann der Betrieb völlig unabhängig von der Entwicklung konfigurieren. Deine Anwendung holt sich die Resourcen dann über JNDI.

 

[dermoritz]

Nillehammer das ist wahrscheinlich die sauberere/schönere Lösung. Aber in meinem Fall ist es eben ganz "klassisch": die Resourcen werden in einer Propertiesdatei referenziert und ich liefere eine Datei ohne Werte aus und ein Handbuch beschreibt was wo eingetragen werden muss.

Aber bei Gelegenheit werde ich mir JNDI mal anschauen (bin beim einrichten von Beispielanwendungen mal darüber gestolpert)

 

[fastjack]

Schau dir mal an wie MediaWiki installiert wird.

 

[dermoritz]

wie andere AMP Geschichten auch? A,M,P installieren und dann in ini Dateien rumfuhrwerken bis es geht? (hab Installation - MediaWiki nur kurz überflogen )