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



## dermoritz (2. Jan 2012)

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 (2. Jan 2012)

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 (2. Jan 2012)

> 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 (2. Jan 2012)

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 (2. Jan 2012)

> 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 (2. Jan 2012)

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 (3. Jan 2012)

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 (3. Jan 2012)

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 (4. Jan 2012)

Schau dir mal an wie MediaWiki installiert wird.


----------



## dermoritz (5. Jan 2012)

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


----------

