Pfad zum Konfigurationsfile von Servletanwendung "dynamisieren"

[dflasjjs]

Hi,

ich habe ne Servlet-Anwendung. Dazu gehört ein Konfigurationsfile (XML) in dem alle relevanten Daten stehen. Momentan habe ich den Pfad dazu hart codiert: "/var/log/rm.xml". Ich möchte nun gerne realisieren, dass man den Pfad "von außen" anpassen kann. Gerade wenn man den Anwendung auf Windowssystemen laufen lässt würde dies sich ja anbieten. ;-)

Wie realisiere ich das am besten?

 

[Noctarius]

Properties Files

 

[dflasjjs]

Aber für die müsste ich doch auch einen Pfad wählen...

Ne andere Frage, kann ich nicht irgendwie einen relativen Pfad für die XML-Datei wählen, so dass es auf jedem System funktionieren würde, irgendwie im selben Projektverzeichnis?

 

[Chumax]

public String getJarPath() {

		File jar = new File(this.getClass().getProtectionDomain().getCodeSource().getLocation()
				.getPath());
		String jarpath = jar.getAbsoluteFile().toString();
		return jarpath;
	}

Damit bekommste den absoluten path zum programm raus.

 

[dflasjjs]

Ich bekomme dann sowas wie: /opt/tomcat/webapps/RM/WEB-INF/classes/core/XmlFacade.class
Gibt das auch, damit ich irgendwie nur bis zum WEB-INF-Verzeichnis komme, ohne jetzt irgendwelche Stringoperationen zu machen?

Wenn ich /opt/tomcat/webapps/RM/WEB-INF/ bekäme könnte ich dort ja mein XML-File abspeichern.

 

[Noctarius]

[c]ServletContext.getRealPath("/WEB-INF/config/myconfig.properties");[/c]

 

[dflasjjs]

Ich danke dir!

 

[dflasjjs]

Mir ist nun gerade aufgefallen, dass

ServletContext.getRealPath("/WEB-INF/config/myconfig.properties");

Nur im einen Servlet funzt, meine Klasse die die für den Dateiaufruf zuständig ist, ist aber ne ganz normale Klasse. Dort würde ich das gerne einbauen, damit ich inkosistenzen vermeiden kann.
Habe ich da auch irgendeine Chance?

 

[Noctarius]

Den ServletContext in dieser Klasse setzen beim aufrufen, instanzieren, was auch immer. Halt den ServletContext innerhalb dieser Klasse zur Verfügung stellen.

 

[dflasjjs]

Dann hab ich die selben Probleme wie jetzt (momentan setze ich beim Aufrufen den Pfad). Allerdings möchte ich das eigentlich vermeiden. Habe ich keine Möglichkeit das ohne ServletContext zu machen, irgendwie vllt mit getClass oder sowas?

 

[maki]

Dann hab ich die selben Probleme wie jetzt (momentan setze ich beim Aufrufen den Pfad). Allerdings möchte ich das eigentlich vermeiden. Habe ich keine Möglichkeit das ohne ServletContext zu machen, irgendwie vllt mit getClass oder sowas?

Was willst du denn genau machen?

Laut Servlet Spek. ist die Nutzung von java.io.File etc. nicht erlaubt, Dateien im Classpath bzw. in der WebApp sollten per Stream geladen werden, du solltest dich auch daran halten, alles andere ist meist ein dreckiger & nicht portabler Hack.

 

[bygones]

und warum bekommt die Klasse die die information braucht nicht einfach den Pfad reingereicht ?
zb im servlet:

String path = ServletContext.getRealPath("/WEB-INF/config/myconfig.properties"); // ist doch ein String ?
DieKlasse k = new DieKlasse(path);
k.machIrgendwas();

dann kann die Klasse mit dem Pfad machen was sie will ?

oder was versteh ich heir nicht ?

 

[dflasjjs]

@bygones: So wie du es sagst, ist es momentan implementiert. Allerdings wird die Klasse nicht immer an der selben Stelle initialisiert, sondern u.U. an mehreren (je nach Funktion) und dann müsste ich im Falle einer Pfadänderung durch die ganzen Dateien tingeln und das ändern. Ich hätte den Pfad daher lieber an einer zentralen Stelle (an der, in der ich ihn auch nur brauche) und das war. Vorher wars ja genau so. Ich hatte dort eben einfach einen absoluten Pfad stehen.

@maki: java.io.File habe ich in den Servlets auch nicht drin, sondern nur in einer ganz normalen Klasse die die Dateiarbeit übernimmt, ich hoffe das geht dann i.O..

Ich glaube ich nehme einfach Chumax Vorschlag und säge hinten die paar Unterordner ab. Dann sollte es ja gehen.

 

[maki]

@maki: java.io.File habe ich in den Servlets auch nicht drin, sondern nur in einer ganz normalen Klasse die die Dateiarbeit übernimmt, ich hoffe das geht dann i.O..

Das gilt für ganze WebApp, nicht nur für Servlets...

Lade die Property Datei doch als Stream aus dem Classpath, geht immer, ist erlaubt und portabel

Smartly load your properties - JavaWorld

 

[dflasjjs]

Hmm hört sich ganz gut an, werde ich mir mal angucken. Danke

 

[dflasjjs]

Okay, laden kann ich die nun. Funzt super und ist viel einfacher als vorher. Durch welche Methode kann ich den Kram denn abspeichern? Hast du da auch noch sonen Artikel für?

 

[maki]

Was meinst du mit "Abspeichern"? Etwa in eine Jar schreiben?

Gar nicht.

Was genau hast du denn vor...

 

[dflasjjs]

Ich habe eine XML-Datei. Dort sind alle Daten der Webanwendung abgespeichert. Beim Startes des Webservers soll die XML-Datei geladen werden und alle Objekte werden initialisiert (funktioniert bereits). Beim Beendes des Server sollen natürlich alle Objekte wieder ins XML-File zurück.

 

[maki]

So wird das nicht gehen...

Um was für Konfig Einstellungen handelt es sich denn?
Werden diese in der WebApp geändert(sonst macht das Speichern wenig Sinn ), wenn ja wie?
DB Konfig Daten etc. speichert man in WebApps "traditionell" in der web.xml, diese können dann vom Admin des ServletContainers editiert werden, dadurch muss auch nix in den Jars der Webapp selbst geändert werden (was nicht geht).

 

[dflasjjs]

Es handelt sich nicht um Konfigurationsdaten, sondern um die Nutzdaten, diese werden natürlich auch in der Applikation verändert. Diese Serialisier/Deserialisiere ich anschließend mit XStream.

 

[maki]

Es handelt sich nicht um Konfigurationsdaten, sondern um die Nutzdaten, diese werden natürlich auch in der Applikation verändert. Diese Serialisier/Deserialisiere ich anschließend mit XStream.

Tja, ich würde sagen da stimmt etwas mit dem Design an sich nicht

Du würdest ja auch nicht versuchen "Nutzdaten" in eine EXE oder DLL zu speichern, oder?

Dazu kommt, dass Serialisierung kein Ersatz für eine DB ist, Serialisierung hat andere Einsatzgebiete.
Wie wäre es mit einer DB?
Alternativ wäre es möglich, diese XML Dateien ausserhalb der WebApp und des ServletContainers abzulegen, mit java.io.File...

 

[dflasjjs]

Wieso? XML ist doch extra für Daten... warum soll man das nicht machen? Wenn die Daten so gering sind, dass sich eine DB nicht lohnt, dann ist es doch auch üblich es in Textdateien abzuspeichern, dachte das ist legitim.

Ich brauchte irgendeine Form der persistenten Datenspeicherung. Eine DB ist für die paar Daten (und vor allem die wenigen Zugriffe) viel zu mächtig.

Gibts denn keine Alternative zu java.io.File Daten in eine XML-Datei zu bekommen?

 

[maki]

Wieso? XML ist doch extra für Daten...

XML schon, aber wie gesagt, Serialisierung hat einen anderen Anwendungsbereich als DBs zu ersetzen.
zB. lassen sich serialisierte Daten nie wieder Deserialisieren wenn sich die Klasse zu sehr geändert hat

Wenn die Daten so gering sind, dass sich eine DB nicht lohnt, dann ist es doch auch üblich es in Textdateien abzuspeichern

Nein, sowas ist nicht üblich, vor allem in Java hört sich eher nach Perl an...
Es gibt natürlich die Möglichkeit das zu machen, aber üblich ist es nicht...

Es gibt einige Embedded DBs für Java, zB. HSQL, H2 Derby, etc. pp.

Ansonnsten kannst du ja die Daten ins Filesystem schrieben, ausserhalb der WebApp/Servletcontainers.

 

[dflasjjs]

Ansonnsten kannst du ja die Daten ins Filesystem schrieben, ausserhalb der WebApp/Servletcontainers.

Was müsste ich denn dafür machen? Hast du da irgendeine Seite/Tut oder sowas. Kann mir jetzt nicht wirklich was drunter vorstellen...

 

[maki]

Mit [c]java.io.File[/c] auf eine Datei zugreifen die zB. unter C:\ liegt.

 

[dflasjjs]

Ich dachte das so ist scheiße und soll man nicht benutzen? Hatte es ja in Post 13 vor...

 

[maki]

Ich dachte das so ist scheiße und soll man nicht benutzen? Hatte es ja in Post 13 vor...

Ja, aber du hast du ja nicht von deiner Idee Serialisierung zur Datenspeicherung zu nutzen nicht abbringen lassen, und verglichen damit ist java.io.File in WebApps gar nicht soo schlimm
bzw. lässt keine "sauberen" Möglichkeiten mehr zu

 

[dflasjjs]

Hehe, okay... ich werde es erst mal so machen und wenn das nächste Update dort ansteht werde ich eine DB einbauen