I'm developping an Eclipse RCP application that uses Hibernate for persistence. The application is meant to be deployed with Java Web Start.

Hibernate version: 3.2

When I run the application with JWS I get the following (shortened) Exception message.

Full stack trace of any exception that occurs:


Then I searched on different forums and found these posts:

1. http://forum.java.sun.com/thread.jspa?threadID=619879&messageID=3869957
the results in the thread were:
- The problem was that the libraries had already been signed. Open jar and remove meta-inf + manifest information. Then sign all jars with your keystore.
- unzipping all jars and including the directory instead of the jars helped

2.
http://forum.hibernate.org/viewtopic.php?t=946925&highlight=signer+information+match+signer+information
http://forum.hibernate.org/viewtopic.ph ... nformation
the result in the thread was:
- sign cglib.jar and hibernate.jar to fix the problem

3. http://forum.hibernate.org/viewtopic.php?t=947745&highlight=signer+information+match+signer+information
the result in the thread was:
- unziping the jars helped

I went through all this propositions and tried to find the problem. This is what I did:

1. I checked if there is a jar in the different Eclipse plugins that was signed with a different keystore. I checked them all and didn't find one. (There aren't so many because I only use a Hibernate Plug-In with the Hibernate jars and the Eclipse RCP Plug-In).
- nothing changed

2. I signed the hibernate3.jar and the cglib-2.1.3.jar
- nothing changed

3. I imported the hibernate jars unzipped in my Eclipse Plug-IN. Exported everything and started it via JWS

Now I get this error message:



So obviously a classloading problem. The Configurator is loaded by the osgi framework and the DOMConfigurator is loaded by Web Start.

Has anybody an idea what I could try to get my application running?
Any suggestions would be very appreciated. I ran out of ideas what I could try more.

Peter

Hello I'm developing a RCP Client based on Eclipse and I also use Hibernate and deploy my Application via Webstart. I don't know exactly what you are trying to do there but I just include the jar Files needed by my Plugin, I don't unpack any jar or even sign a jar that is used by the plugin they are just defined inside the plugin.xml and everything really works fine. Your Manifest.mf should look similar like this one :

Manifest-Version: 1.0
Bundle-Name: Ticketsystem Client
Bundle-SymbolicName: de.xcom.ticket; singleton:=true
Bundle-Version: 1.6.6
Bundle-ClassPath: ticket.jar,
lib/jbossall-client.jar,
lib/ticketClient.jar,
lib/proxyclient.jar,
lib/apix-core.jar,
lib/XCOMWorkflow.jar,
lib/raptor.jar,
lib/cglib-2.1.jar,
lib/commons-collections-2.1.1.jar,
lib/commons-logging-1.0.4.jar,
lib/asm.jar,
lib/commons-lang-1.0.1.jar,
lib/log4j-1.2.9.jar,
lib/commons-beanutils-1.7.jar,
lib/hibernate3.jar
Bundle-Activator: de.xcom.ticket.TicketPlugin
Bundle-Vendor: XCOM AG
Bundle-Localization: plugin
Require-Bundle: org.eclipse.ui,
org.eclipse.core.runtime,
org.eclipse.osgi,
org.eclipse.swt,
org.eclipse.jface,
org.eclipse.ui,
org.eclipse.ui.ide,
org.eclipse.ui.forms,
org.eclipse.ui.workbench,
org.eclipse.ui.workbench.texteditor,
org.eclipse.update.core,
org.eclipse.core.resources,
org.eclipse.jface.text,
org.eclipse.ui.views
Bundle-ManifestVersion: 2
Eclipse-AutoStart: true
Export-Package: com.jproxy.proxy,
com.jproxy.proxy.callback,
com.jproxy.proxy.servlet,
com.jproxy.proxy.util,
de.xcom.ticket,
de.xcom.ticket.actions,
de.xcom.ticket.composites,
de.xcom.ticket.core,
de.xcom.ticket.dialogs,
de.xcom.ticket.editors,
de.xcom.ticket.editors.sections,
de.xcom.ticket.editors.sections.manager,
de.xcom.ticket.filter,
de.xcom.ticket.internal,
de.xcom.ticket.internal.dataaccess,
de.xcom.ticket.jface.dialog,
de.xcom.ticket.jobs,
de.xcom.ticket.listener,
de.xcom.ticket.models,
de.xcom.ticket.perspective,
de.xcom.ticket.preferences,
de.xcom.ticket.provider.content,
de.xcom.ticket.provider.label,
de.xcom.ticket.service,
de.xcom.ticket.settings,
de.xcom.ticket.sorter,
de.xcom.ticket.views,
de.xcom.ticket.widgets,
de.xcom.ticket.wizards,
de.xcom.ticketsystem.dto,
de.xcom.ticketsystem.exception,
de.xcom.ticketsystem.interfaces,
de.xcom.ticketsystem.parameters,
de.xcom.ticketsystem.pojo,
de.xcom.ticketsystem.utils,
net.sf.raptor.jface.viewers,
net.sf.raptor.swt.part,
net.sf.raptor.swt.widget,
net.sf.raptor.ui,
net.sf.raptor.ui.swt,
net.sf.raptor.ui.swt.components,
net.sf.raptor.ui.swt.components.listener,
net.sf.raptor.ui.swt.dialog,
net.sf.raptor.validation,
org.apache.commons.beanutils,
org.jnp.interfaces

That's it.

Hi Kaneda,

let's continue in German. Erstmal danke für deine Antwort.

Ich hab mir deine Manifest-Datei mal angesehen und wenn ich das richtig sehe, dann hast du Hibernate direkt in dein Anwendungs-Plug-In integriert. In meinem Fall sind die Hibernate-Archive sowie mein Modell in separaten Plug-Ins. So hatte ich das bisher auch in der Literatur im Netz gesehen, z.B. im Beispielkapitel des Buchs Rich-Client-Entwicklung mit Eclipse 3.2.
Du ersparst dir mit deinem Setup natürlich einiges, wie z.B. Buddy-Classloading. das bei dir nicht aktiviert werden muss und wahrscheinlich auch die Classloader- und Sicherheitsprobleme mit denen ich gerade zu kämpfen habe.
Der Vorteil, Hibernate und das Modell in einem eigenen Plug-In zu haben, liegt nach meinem Verständnis darin, dass man bei Aktualisierungen nur das Anwendungs-Plug-In aktualisieren muss (das ändert sich ja meist am häufigsten). Dadurch müsste Web Start auch nur die eine jar-Datei herunterladen die sich geändert hat. Das wäre für uns schon interessant, da damit gerechnet wird, dass die Software relativ häufig neue Updates bekommt.
Falls ich keine Lösung für mein Problem finden kann, werde ich wohl aber trotzdem mal deine Version versuchen. Besser bisschen mehr runterladen und dafür funktioniert die Anwendung, als wenig und dafür geht nichts.

Danke schon mal für die prompte Antwort.
Peter

Hi Peter,

das was Du anführst ist richtig, daher werden bei uns die Eclipse.jars separat gelagert und nicht ins Feature mit eingebunden, da sich dort am meisten ändert. Die anderen Jars binde ich ins Plugin mit ein, da ich nicht so oft Updates der Libaries mitmache, Update erfolgt nur dann, wenn wirklich ein Bug der meine Implementierung betrifft, gelöst wurde, zum Anderen kam es leider die letzte Zeit immer wieder vor, daß durch Hibernate Updates sich andere Features ;) gezeigt haben, die in vorherigen Versionen nicht enthalten waren und mein Leben ziemlich erschwert haben. Ich mache auch ziemlich viele Updates ca. alle 1,5 Wochen (Release often ;) ) und das Einbinden der Modelle und der Jars innerhalb des Plugins hat bisher nie wirklich weh getan, vorallem da Bandbreite und Downloadgrösse heutzutage nicht mehr ganz so relevant ist. Ich hatte das Problem auch schon gehabt, als ich versucht hatte die Plugins zu separieren, allerdings habe ich nach 3 Tagen erfolglosen Lösungsversuchen aufgegeben, falls Du es schaffen solltest, dann wäre ich an der Lösung interessiert.

Zusatz:
Jetzt wo die das mit dem BuddyClassloader gesehen habe. Könntest Du vielleicht mal versuchen, den Classloader an den relvanten Stellen umzubiegen. so in etwa

Hi Kaneda,

ich hab jetzt mal deine Version ausprobiert und ein kleines HelloWorld geschrieben. Alles ist in einem Plug-In, außer den Plug-ins, die im org.eclipse.rcp-Feature enthalten sind.

Also die benötigten Hibernate jars liegen in einem lib-Ordner und sind im Plug-In-Editor unter Classpath angegeben. In der IDE startet alles wunderbar. Exportiere ich das Ganze und starte es über Web Start, geht es nicht mehr. Wieder die Security Exception von Cglib.

Welche Hibernate Version benutzt du genau? Ich hab gesehen, dass deine cglib Version 2.1 ist. Meine ist cglib-2.1.3. Ich hab mal zum Spaß die Version cglib-2.2.beta runtergeladen. Da ging dann überhaupt nichts mehr. Den Fehler habe ich bekommen:

java.lang.NoClassDefFoundError: org/objectweb/asm/MethodVisitor

Vielleicht könntest du mir mal deine cglib.jar zuschicken. Ich finde kein cglib-2.1.jar auf der SourceForge-Seite von cglib. peter (at) trash-mail.de

Grüße
Peter

Mit CGLIB 2.2 brauchst Du wohl auch das ASM.jar im Classpath.

CGLIB 2.1 ist im Hibernate Deployer Verzeichnis von JBoss 4.0.2 ;)

Hi Kaneda,

danke für den Hinweis. Hab ich gefunden.

Ein kleiner Erfolg:

Nachdem ich schon fast aufgeben wollte, habe ich es irgendwie geschaft ein kleines HelloWebStartWorld mit Hibernate und Eclipse RCP hinzubekommen. Ich hab dazu alles in ein Plug-In gepackt. Ich weiß schon nicht mehr woran es jetzt eigentlich gelegen hat, dass es so lange nicht geklappt hat. Ich hab jetzt ein paar Tage wie blöd alles ausprobiert, was mir irgendwie eingefallen ist. Ich denke aber nicht, dass es an cglib-2.1 lag, oder zumindest nicht nur, denn meine eigentliche Anwendung wirft immernoch SecurityExceptions.

Was sehr, sehr seltsam ist, ist, dass mir der SAX-Parser in meiner Web Start-Anwendung erzählt, dass meine Mappings nicht in Ordnung seien, z.B. Comment-Blöcke dürfen nicht ohne Inhalt sein und Column-Tags müssen als Empty-Tag geschrieben werden. Hallo? Ich mein, ich mach jetzt schon die ganze Zeit mit den Mapping-Dateien rum, zum Teil sind die sogar mit den Hibernate-Tools erstellt worden und zwar mit leeren Comment-Blöcken und mit einem öffnenden und schließenden Column-Tag. Also was will der Parser denn auf einmal? Warum muss mit Web Start alles anders sein?

Ich bin gerade dabei meine HelloWorld-Anwendung in separate Plug-Ins für Anwendung, Modell und Hibernate aufzusplitten. Nach dem Lösen einiger Probleme bin ich jetzt an dem Punkt, dass meine externen Plug-In-Klassen nicht gefunden werden. Ich versteh nicht ganz warum. Das Modell-Plug-In ist als benötigtes Plug-In in meinem Anwendungs-Plug-In angegeben. Das Plug-In wird auch über Web-Start heruntergeladen und in der Manifest-Datei des jars sind die entsprechenden Klassen eingetragen. In der IDE funktioniert natürlich alles. Ist hier wahrscheinlich das falsche Forum für solche Fragen.

Danke auf jeden Fall für die Ideen und die Unterstützung. Ich hoffe ich finde noch eine Lösung.

Was hat denn bei dir nicht funktioniert, als du versucht hast die Plug-Ins zu trennen?

Zum Deinem Problem mit den nicht gefunden Klassen kann ich Dir nur den Tipp geben, daß Dein Modelplugin seine Packages an aussen freigeben muss, ansonsten ist alles schön gekapselt. Exported Packages ist das Stichwort, das findest Du in der Plugin.xml unter den Runtimetab.
Und genau das war mein Problem mit der Aufsplittung in Unterschiedliche Plugins, das es nicht ausreicht nur eine Pluginabhängigkeit zu erzeugen, sondern auch die zu benutzenden Packages zu exposen ;). Zum anderen hatte ich erhebliche Problem einen Verbindung zu meinem JBoss Server aufzubauen, warum dann das meiste der Jars auch in einem Plugin gelandet ist.
Ich hoffe das hilft Dir auch schon mal weiter.

OK, es ist unglaublich!

Ich habe es jetzt geschaft, die Anwendung zum laufen zu bekommen in dem alles in einem Plug-In ist. Achtung jetzt kommt der Hammer:

Ich musste in der Application Klasse in der run Methode diese Zeile eingeben:

Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());

Diese Abfolge:

System.out.println(Thread.currentThread().getContextClassLoader());
Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());
System.out.println(Thread.currentThread().getContextClassLoader());

gibt diese Ausgabe:

org.eclipse.core.runtime.internal.adaptor.ContextFinder@1a8d460
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@40ece0

Ich denke und werde das auch probieren, dass es mit dieser Zeile auch möglich ist die Plug-Ins aufzusplitten. Ergebnis gibt's dann hier. -Stay tuned-

Danke noch mal! Ohne deinen kreativen Classloader-Einfall wäre das nie rausgekommen. Oder WER bitte denkt daran, dass die SecurityException mit einem falschen Classloader zusammenhängt? Ich ab jetzt auf jeden Fall. :D

Die Frage ist, ob man dieses Classloader Problem nicht an einer anderen Stelle lösen kann? Irgendwie kommt mir diese Lösung ein bischen wie ein Hack vor.

Grüße
Peter

Kurze Meldung über den Stand der Dinge.

Ich hab es jetzt geschaft die Plug-Ins zu separieren! Olé!
Hat mir viel Nerven gekosten. Im Endeffekt hat dann nur noch gefehlt, dass ich in der Manifest Datei des Anwendungs-Plug-Ins im Classpath ein "." eingefügt habe.

Gefunden hab ich das nur durch Zufall, weil ich in kleinen Hello-Worlds rumprobiert habe und es auf einmal ging. Verstehen kann ich aber nicht ganz, warum das eigene Directory mit im Classpath stehen muss, damit externe Plug-Ins gefunden werden - eigene Klassen hätte ich ja noch nachvollziehen können, die werden aber auch ohne dem Zusatz gefunden.

Ich möchte dir auch nochmal wegen dem Classloader Tip danken. Ohne den würde ich jetzt immernoch SecurityExceptions bekommen. Finde es aber trotzdem seltsam, dass man das nicht anders lösen kann.

Falls du planst noch einmal den Versuch zu starten dein Plug-In auch aufzuteilen, melde dich gerne hier im Thread falls Probleme auftauchen. Ich glaub ich hab so langsam alle Exceptions durch, die Java Web Start verursachen kann. Na ja, sagen wir fast alle.

Grüße
Peter