JBoss4 Deployment Multiple class loaders found.

[SnooP]

Moin - vielleicht hat hier ja jemand sowas schonmal gemacht... - ich bin mit meinem Latein so langsam am Ende.

Ich versuche auf dem JBoss (4.0.5) jar-Dateien zu deployen sowohl mit ejbs als auch mit spring-services, die dann via http-invoker angesprochen werden... das funktioniert so weit auch - nur das hot-deployment funktioniert nicht.
Das Problem ist, immer wenn ich eine vorhandene Jar-Datei (xyz.jar) im deploy-Verzeichnis überschreiben will kommt folgende Fehlermeldung im logging:
Adding org.jboss.mx.loading.UnifiedClassLoader3@7e9bed{ url=file:/lison/ew/jboss-4.0.5.GA/server/xxx/tmp/deploy/tmp8131xyz.jar ,addedOrder=0}
08:38:16 DEBUG [ScannerThread] org.jboss.mx.loading.ClassLoaderUtils (ClassLoaderUtils.java:424) - Multiple class loaders found for pkg: de.xyz.business
08:38:16 DEBUG [ScannerThread] org.jboss.mx.loading.ClassLoaderUtils (ClassLoaderUtils.java:424) - Multiple class loaders found for pkg: de.xyz.job
[...]
sprich für jedes package im jar wird erkannt, dass der classloader diese packages bereits geladen hat (bzw. auch die darin enthaltenen klassen). Demnach funktioniert das undeployment wohl nicht korrekt.
Gibt es irgendeine Möglichkeit über jmx-console oder wie auch immer auf einfache Art und Weise die gesamten durch den Classloader geladenenen Klassen wieder loszuwerden und das deploy-Verzeichnis danach neu scannen zu lassen?

Weil der einzige hier mögliche Weg ist aktuell den Jboss runterzufahren und danach wieder hochzufahren, was so ca. 3 Minuten Zeit kostet... und beim Starten legt sich ab und zu der Jboss auch noch auf die Fresse beim Connect zur DB... aber das ist noch nen anderes Lied

any ideas?

 

[maki]

Weil der einzige hier mögliche Weg ist aktuell den Jboss runterzufahren und danach wieder hochzufahren, was so ca. 3 Minuten Zeit kostet... und beim Starten legt sich ab und zu der Jboss auch noch auf die Fresse beim Connect zur DB...

Nutzen auch JBoss 4.0.5 GA, haben ähnliche Problem mit dem DB Zugriff beim hochfahren, aber 3 MInuten sind lange, dauert hier nur die hälfte der Zeit (runter&rauffahren), vielleicht ist die Maschine schlicht zu langsam
Hot Deploy war uns zu unsicher.

 

[SnooP]

Das ganze Ding ist ja noch ne Entwicklungsumgebung... beim Hochfahren werden schon einige Sachen konfiguriert - aber langsam ists schon - läuft als eine von drei VMs auf einem Server.

Beim richtigen Rechner wird glaub ich auch nicht hot deployt - des weiß ich aber nicht... wär mir aber auch egal - aber grundsätzlich ist das imho nen echter Vorteil der Maschinen.

Dummerweise scheint er für jedes jar seinen eigenen Classloader starten zu wollen... wie kann ich ihm das abgewöhnen - könnte es an der manifest-datei liegen? Hab irgendwas davon gelesen, dort nen cp anzugeben und dann nutzt er den vorhandenen classloader...
ich will ja gar nicht verschiedene Versionen eines Jars nutzen - sondern das aktuelle schlicht ersetzen... blöder Mist

 

[maki]

aber grundsätzlich ist das imho nen echter Vorteil der Maschinen.

Was meinst du?

Performance? Nur eine Frage der richtigen Hardware imho.

 

[SnooP]

ne... - du musst eine laufende Maschine nicht runterfahren - die Nutzer merken im günstigsten Fall nichts davon - bzw. zumindest nicht die Nutzer anderer Module die gleichzeitig deployt sind...

watt weiß ich - wenn z.B. gleichzeitig eine Kundendatenbank installiert ist und nur das Bestellmodul aktualisiert werden soll... dann müssen nur den Leuten vom Bestellmodul bescheid gesagt werden, dass sie mal kurz pause machen sollen

 

[maki]

Nicht sicher ob ich dich richtig verstehe, aber da ist es doch egal ob virtuell oder echte HW.

Die Vorteile von einem funktionierendem Hotdeploy sind mir schon bewusst

 

[SnooP]

"die Maschinen" war falsch von mir verwendet... ich meinte damit grundsätzlich das hot-deployment bei application-servern. Die VMs meinte ich nich ... war mit dem tippen schneller als mit dem denken...

die vms haben natürlich gegenüber den echten rechnern - außer das bei uns platz gespart wird - keinen vorteil

 

[FArt]

Das HotDeployment funktioniert prinzipiell.

Es liegt lediglich an der Implementierung (falsches Design z.B. die (falsche) Verwendung von static) und/oder an der Konfiguration des Server bzw. der Deploymentunit (WAR, EAR) bzgl. LoaderRepositories oder ClassLoader Delegation.

 

[SnooP]

Das HotDeployment prinzipiell funktioniert, ist mir klar...

WAR-Files werden auch richtig deployt... nur bei den jar-files hakts. Ich bekomme zumindest die obigen Fehlermeldungen und kann mir keinen Reim darauf machen.... wo kann ich also nach falscher Konfiguration gucken, was heißt falsches Design und falsche Verwendung von static - in welchem Kontext?