# JBoss - Deploy Verzeichnis zur Laufzeit ermitteln



## rarup (9. Jul 2009)

Hallo,
ich habe eine Anwendung mit Falcelets die im JBoss/Tomcat läuft.
Wie kann ich im Java-Code meiner Bean herausfinden wohin ich deployed wurde (was ja ein "temporäres" Verzeichnis ist).
Wenn ich "File file = new File("bla"); file.getAbsolutePath()" befrage befinde ich mich im Startverzeichnis des JBoss (also "[...]/bin"). Ich bräuchte jedoch "[...]/server\default\tmp\deploy/tmp[??????]") und zwar zur Laufzeit innerhalb einer Java-Bean.
Weiss jemand die Lösung?

Danke + Grüße, Rainer


----------



## maki (9. Jul 2009)

Darf man fragen wozu du das bauchst?
Schreiben solltest du sowieso nicht ins Deploy Verzeichniss, Classpath Ressourcen lädt man am besten als Ressource und nicht als File.


----------



## rarup (9. Jul 2009)

erstmal danke für die Antwort, aber warum muss ich meine intention erläutern? Es geht um eine Designfrage.


----------



## maki (9. Jul 2009)

rarup hat gesagt.:


> erstmal danke für die Antwort, aber warum muss ich meine intention erläutern? Es geht um eine Designfrage.


Eben, so eine Anforderung klingt imho sehr seltsam, deswegen frage ich ja


----------



## rarup (9. Jul 2009)

Was ist daran seltsam deployte Konfigurationsadateien auslesen zu wollen ohne manuel einen Pfad konfigurieren zu wollen? Natürlich kann ich a) die Konfigurationsdatei manuel kopieren und b) manuel konfigurieren wo sie zu finden ist. Aber wenn es auch einfacher geht ...


----------



## maki (9. Jul 2009)

rarup hat gesagt.:


> Was ist daran seltsam deployte Konfigurationsadateien auslesen zu wollen ohne manuel einen Pfad konfigurieren zu wollen? Natürlich kann ich a) die Konfigurationsdatei manuel kopieren und b) manuel konfigurieren wo sie zu finden ist. Aber wenn es auch einfacher geht ...


Wie gesagt, solltest so etwas nicht per File machen.
Wenn sich die Datei im Classpath befindet, sollte sie als Ressouce geladen werden.

Wo befindet sich deine Datei denn in der WebApp?


----------



## rarup (9. Jul 2009)

wie gesagt, die Datei(en) werden deployed (sie befinden sich im war-file). Sie befinden sich also unterhalb des deploy-Verzeichnisses. Auch eine Lösung existiert (siehe meinen Beitrag oben). Es geht mir lediglich um die Möglichkeit einer alternativen Lösung.
Als Ressource können sie nicht geladen werden (aber bitte nicht fragen warum, denn eigentlich wollte ich eine Antwort auf die Frage ob man den Deploypfad in der Bean ermitteln kann und nicht das dazugehörige Problem in aller Ausführlichkeit erläutern .. glaub mir, du willst das auch alles garnicht wissen


----------



## maki (9. Jul 2009)

Laut Spek. muss soweit ich weiss das war file gar nicht entpackt werden bzw. kein erreichbarer Pfad für die WebApp sein, deswegen mein Einwand, so etwas ist nicht sauber.
Als Classpath Ressourcen können nur Dateien geladen werden, die auch im CP sind 
Aber wenn sie im CP sind, spielt der echte Pfad im Dateisystem keine Rolle mehr.


----------



## kaosmaki (23. Jul 2009)

Wenn man seinen Container kennt, kann man evtl. Umgebungsvariablen nutzen. Der gibt z.B. schon mal Aufschluss über das lib-Verzeichnis des Servers. von daher kann man sich ggf. ins richtige Verzeichnis, z.B. Deploy-Verzeichnis hangeln.
Ein bisschen "dirty", aber es geht.
IMHO _kann_ es durchaus sinnvoll sein: Wenn man Ressourcen laden möchte, ohne die Appllikation neu zu bauen oder zu deployen und man diese Ressourcen nicht in der DB ablegen möchte.


----------



## FArt (4. Aug 2009)

kaosmaki hat gesagt.:


> IMHO _kann_ es durchaus sinnvoll sein: Wenn man Ressourcen laden möchte, ohne die Appllikation neu zu bauen oder zu deployen und man diese Ressourcen nicht in der DB ablegen möchte.


Das ist kein Grund. Ich kann auch die Ressourcen extra deployen und ohne Filezugriff darauf zugreifen.

In der Regel werden in Enterpriseapplkationen keine Filezugriffe benötigt. Ressourcen sollte man über den Classloader laden. Wenn Filezugriffe nötig sind (lediglich bei Fileschnittstellen ist das m.E. so), dann sollte das über JCA geregelt werden.
Die Antwort auf die "Designfrage": grobes Foul... don't do it...


----------

