JBOSS_HOME beim start mitgeben?

[Verjigorm]

Hallo,

in unserer Applikation wird ganz oft

String baseDir = System.getenv("JBOSS_HOME");

abgefragt. Diese Umgebungsvariable wird von uns in Windows gesertzt. Nun haben wir das Problem, wir wollen 2 JBoss parallel betreiben und dann funktioniert das natürlich nichtmehr so wirklich.
Ich hatte gehofft, ich könnte dem JBoss als Startparameter ein JBOSS_HOME mitgeben, sowas in der Art:

-DJBOSS_HOME=C:\Development\Java\jboss-4.2.2.GA

Leider bringt mich das nicht weiter, die Ausgabe von oben zeigt weiterhin den alten Pfad der gesetzten JBOSS_HOME-Variable von Windows an.
Jemand eine Idee wie man das machen kann? Ohne dass ich System.getenv rauswerfe?

mfg Verjigorm

 

[FArt]

Hallo,

in unserer Applikation wird ganz oft

String baseDir = System.getenv("JBOSS_HOME");

abgefragt. Diese Umgebungsvariable wird von uns in Windows gesertzt. Nun haben wir das Problem, wir wollen 2 JBoss parallel betreiben und dann funktioniert das natürlich nichtmehr so wirklich.
Ich hatte gehofft, ich könnte dem JBoss als Startparameter ein JBOSS_HOME mitgeben, sowas in der Art:

-DJBOSS_HOME=C:\Development\Java\jboss-4.2.2.GA

Leider bringt mich das nicht weiter, die Ausgabe von oben zeigt weiterhin den alten Pfad der gesetzten JBOSS_HOME-Variable von Windows an.
Jemand eine Idee wie man das machen kann? Ohne dass ich System.getenv rauswerfe?

mfg Verjigorm

Falsche Antwort:
Ihr könnt immer noch die Umgebungsvariable setzen, aber im Startskript. Dann gilt sie nur für diesen Prozess.

Richtige Antwort:
Wenn ihr in einer Enterpriseapplikation oft den Ort der JBoss Installation benötigt, heißt das in der Regel, dass ihr hier grundsätzlich ein extrem suboptimale "Lösung" für ein Problem gefunden habt. Mit grpßer Wahrscheinlichkeit deutet das darauf hin, dass sich eure Enterpriseapplikation an manchen Stellen über die Spec hinwegsetzt. Ihr solltet dringend die Architektur und Implementierung euerer Applikation überdenken und ändern. Wenn man nicht den Applicationserver an sich durch Services erweitert, wird man diese Information nicht benötigen. Und selbst solche Erweiterungen sind in der Regel deployfähig und von dem Ort der Installation unabhängig.

Wofür braucht ihr das also?

 

[Verjigorm]

Hallo,

ich habe das ganze nur übernommen und der Entwickler existiert nicht mehr 🙂

Es liegen im bin-Verzeichnis des JBoss verschiedene "config-files" die jeweils für bestimmte Teile der Anwendung ausgelesen werden. Es wird also z.B. die Datei <JBOSS_HOME>/bin/client-config.xml ausgelesen und diese Werte weitergereicht.
Da ich a) nicht besser weiss, wie man den "richtigen Pfad" zu einer config/properties-Files angeben müsste und b) garnicht weiss ob man das überhaupt machen sollte, bzw. wie man es besser macht, stehe ich nun da und denk mir meinen Teil 😉

gruß Verjigorm

 

[FArt]

Hallo,

ich habe das ganze nur übernommen und der Entwickler existiert nicht mehr 🙂

Es liegen im bin-Verzeichnis des JBoss verschiedene "config-files" die jeweils für bestimmte Teile der Anwendung ausgelesen werden. Es wird also z.B. die Datei <JBOSS_HOME>/bin/client-config.xml ausgelesen und diese Werte weitergereicht.
Da ich a) nicht besser weiss, wie man den "richtigen Pfad" zu einer config/properties-Files angeben müsste und b) garnicht weiss ob man das überhaupt machen sollte, bzw. wie man es besser macht, stehe ich nun da und denk mir meinen Teil 😉

gruß Verjigorm

Das ist weder eine gute Ausrede noch eine gute Einstellung.
Dein Anspruch sollte es sein, aufgedeckte Fehler zu beheben. Sie werden mit Sicherheit irgendwann wieder Probleme machen (so wie jetzt), d.h. man hat eine sinnvolle Lösung nur aufgeschoben. Blöd ist es dann, wenn das Problem nicht im Zuge einer geplanten Umstellung auftritt, sondern als Bug im Produktivbetrieb.

Die Anforderung:
Konfigurationsdateien (für Clients?) sollen zur Laufzeit gelesen werden.

Lösung:
Die Dateien werden mit der Applikation (z.B. im EAR oder WAR) deployt und über den Kontextclass-Loader eingelesen. Dadurch ist kein Filezugriff mehr nötig, der (wenn er aus einem EJB heraus passiert) per Spec verboten ist.

Vorteile:
Keine Probleme mit Berechtigungen (Filesystem).
Keine Anpassungen der JBoss-Instanz (also Abhängigkeiten der Applikation in die Installation).
Spec konform.
Konfigurationen sind (unabhängig von der Applikation) einfach (auch zur Laufzeit) austauschbar.
...

 

[Verjigorm]

Das ist weder eine gute Ausrede noch eine gute Einstellung.
Dein Anspruch sollte es sein, aufgedeckte Fehler zu beheben. Sie werden mit Sicherheit irgendwann wieder Probleme machen (so wie jetzt), d.h. man hat eine sinnvolle Lösung nur aufgeschoben. Blöd ist es dann, wenn das Problem nicht im Zuge einer geplanten Umstellung auftritt, sondern als Bug im Produktivbetrieb.

Die Anforderung:
Konfigurationsdateien (für Clients?) sollen zur Laufzeit gelesen werden.

Lösung:
Die Dateien werden mit der Applikation (z.B. im EAR oder WAR) deployt und über den Kontextclass-Loader eingelesen. Dadurch ist kein Filezugriff mehr nötig, der (wenn er aus einem EJB heraus passiert) per Spec verboten ist.

Vorteile:
Keine Probleme mit Berechtigungen (Filesystem).
Keine Anpassungen der JBoss-Instanz (also Abhängigkeiten der Applikation in die Installation).
Spec konform.
Konfigurationen sind (unabhängig von der Applikation) einfach (auch zur Laufzeit) austauschbar.
...

Ich beschäftige mich ja mit dem Thema, deswegen frage ich ja hier 😉

Zum Thema Classloader und Konfigurationen:
Wie sind die denn zur Laufzeit austauschbar wenn sie mit ins WAR/EAR deployt wurden?

mfg

 

[FArt]

Ich beschäftige mich ja mit dem Thema, deswegen frage ich ja hier 😉

Zum Thema Classloader und Konfigurationen:
Wie sind die denn zur Laufzeit austauschbar wenn sie mit ins WAR/EAR deployt wurden?

mfg

Mann kann sie auch außerhalb der Applikation deployen, wenn man die Austauschbarkeit benötigen würde. Verschiedene Deployments können mit Abhängigkeiten zueinander ausgestattet werden, damit alles in der richtigen Reihenfolge deploy wird und somit nötigen Ressourcen rechtzeitig bereits sind.