JBoss nutzt beim starten ständig das Root.war

[grischan]

Hallo zusammen,

ich nutze für mein J2EE-Projekt den JBoss 4.0.3 SP1 als ApplicationServer. Soweit funktioniert auch alles wie gewühnscht, zumindest lokal.
In meinem Deployment-Ordner befindet sich zum einem das ear mit der Applikation, aber auch ein Ordner jbossweb-tomcat55 in welchen sich ein ordner Root.war befindet.
Nun zu meinem Problem:
Beim Serverstart wird jedes mal erst die jboss-web.xml aus diesem Root.war ausgeführt und dann erst die web.xml meiner Applikation geladen, dies führt aber zu Problemen auf anderen Rechnern, da dort teilweise andere Dinge im Root.war stehen.

Gibt es eine Möglichkeit, dass JBoss diesen Root.war ignoriert und direkt mit meiner web.xml startet? Den Ordner einfach zu löschen fänd ich keine schöne Lösung, da er auf den späteren Servern auch vorhanden sein wird.

Danke.

 

[ms]

Was macht deine Applikation beim Serverstart?
Was für Probleme treten bei anderen Rechnern auf?

ms

 

[grischan]

Meine Applikation initialisiert seine Konfiguration (mit Hilfe von Spring) beim Serverstart und lädt diverse weitere firmeninterne Frameworks. Das klappt alles ohne Probleme. Das Problem besteht darin, dass je nach eingestellten Deployment-Optionen (MyEclipse 4.1.1 wird zum Deployen verwendet) in das Root.war diverse Jars eingestellt, oder nicht eingestellt werden. Ich möchte nun, um dieses Problem ganz zu umgehen, den JBoss dazubringen das Root.war zu ignorieren. Löschen geht aber nicht, da andere Applikationen möglicherweise diese jars benötigen.

 

[ms]

Root.war ist eine eigenständige Applikation. Was hat die mit eurer Applikation zu tun?
Ihr könnt doch den Springkontext und anderen Sachen auch in eurer Applikation initialisieren.
Geht es um den Zugriff über die Url?

ms

 

[grischan]

Root.war sollte das sein. Doch beim Serverstart werden erst die Konfigs aus diesem Ordner ausgelesen und dann die der gewählten Applikation.

 

[ms]

Wenn eure Applikation nichts mit Root.war zu tun hat, warum kopiert ihr dann Sachen dort hinein?

ms

 

[grischan]

Ein paar Jars habe ich vorübergehend reinkopiert, da JBoss immer zuerst die jboss-web.xml aus dem Root.war gelesen hat und dann abbrach, weil die Klassen nicht da waren.

Ich hab jetzt erstmal den Ordner lokal gelöscht, mal sehen ob es auf den Servern so laufen wird. Da ich aber die Seiteneffekte nicht absehen kann, suche ich nach einer Lösung, bei der, der JBoss halt die Datein aus dem Root.war nicht einliest.

 

[maki]

Hast du mal versucht, deine JARs nach jboss-4.x.x.x\server\default\lib zu kopieren und die root.war in Ruhe zu lassen?

 

[ms]

Welche Klassen waren nicht da?
Wenn du Jboss runterlädst, entpackst und startest dann fehlen sicher keine Klassen.

ms

 

[grischan]

Was soll das bringen?
Alle nötigen Jars liegen unter .../deploy/myServer/.../WEB-INF/lib. Jedoch greift der JBoss beim Start irgendwie nicht sofort auf dieses Verzeichnis zu, sondern erst wenn er seine jboss-web.xml abgearbeitet hat.

 

[ms]

Wir drehen uns im Kreis.
Was stört dich daran, dass die Root.war als erstes deployed wird?

ms

 

[grischan]

Was stört dich daran, dass die Root.war als erstes deployed wird?
ms

Zum einem steht da bei einigen Kollegen äußerst "komische" Sache drin (da wir mehrere, sehr verschiedene WebApplikationen betreuen), wodurch die Applikation nicht fehlerfrei läuft. Zum anderen störte es mich einfach, einige Jars in meiner Applikation und dann auch nochmal dort vorzuhalten.

 

[ms]

Was für komische Sachen? Bilder von halbnackten Frauen? Die haben dann wahrscheinlich deine Kollegen dort reinkopiert, warum auch immer! 😀

Spaß beiseite, wenn du uns keine konkreteren Hinweise gibst, kann man dir auch nicht helfen.
Und ich bin mir sicher, dass das was du möchtest (deployreihenfolge von Applikationen ändern) nicht das eigentliche Problem löst. Da ist woanders schon was schief gelaufen.

Übrigens, es sollte keine Abhängigkeiten von einzelnen Applikationen geben (Root.war zu deiner Applikation bzw. umgekehrt). Mehrfach vorkommende jar-Files sind auch ok. Ist sogar notwendig, wenn man den scope des Classloader ändert.

ms