JBoss Libs vs. JBoss Libary

[brauner1990]

Tag auch Community!

Ich hab ein ServerProjekt welches auf einem JBoss läuft. Dies funktioniert hervorragend.

Nun binde ich den Client an und er kann nicht kommunizieren mit dem JBoss. Klar Libs fehlen, also Server eingebunden als Libary (via Eclipse ProjectConfig) und es funktioniert. Also Libs aus dem JBoss nehmen und ins Projekt einbinden, JBoss Referenz entfernen und alles sollte ja funktionieren, da die Libs ja die selbigen sind ...

Weit gefehlt. Es funktioniert so nicht... Hat da jmd eine Idee?

P.S.: Die Exception die fliegt ist

exception is java.lang.ClassNotFoundException: org.jnp.interfaces.NamingContextFactory

 

[schlingel]

Dir fehlt offensichtlich eine nötige Referenz. Du musst nachschauen wo die Klasse drin ist.

Ich hab das immer mit dem TotalCommander gemacht weil man mit dem relativ bequem auch in Zip-Files danach suchen kann. Das machst du dann einfach über's komplette JBoss Verzeichnis. Dann sollte er sie finden.

 

[brauner1990]

Hier mal die anonymisierte Stacktrace ...

2012-11-14 17:17:03,562 ERROR [main] de.firma.abrechnungstool.serverGedoens.JndiHelper: javax.naming.NoInitialContextException: Cannot instantiate class: org.jnp.interfaces.NamingContextFactory [Root exception is java.lang.ClassNotFoundException: org.jnp.interfaces.NamingContextFactory]
javax.naming.NoInitialContextException: Cannot instantiate class: org.jnp.interfaces.NamingContextFactory [Root exception is java.lang.ClassNotFoundException: org.jnp.interfaces.NamingContextFactory]
	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:657)
	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
	at javax.naming.InitialContext.init(InitialContext.java:223)
	at javax.naming.InitialContext.<init>(InitialContext.java:197)
	at de.firma.abrechnungstool.serverGedoens.JndiHelper.init(JndiHelper.java:57)
	at de.firma.abrechnungstool.serverGedoens.JndiHelper.getInstance(JndiHelper.java:35)
	at de.firma.abrechnungstool.test.TestHibernate.main(TestHibernate.java:152)
Caused by: java.lang.ClassNotFoundException: org.jnp.interfaces.NamingContextFactory
	at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:247)
	at com.sun.naming.internal.VersionHelper12.loadClass(VersionHelper12.java:46)
	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:654)
	... 6 more
Exception in thread "main" java.lang.InstantiationException: Could not instantiate de.firma.abrechnungstool.serverGedoens.JndiHelper
	at de.firma.abrechnungstool.serverGedoens.JndiHelper.getInstance(JndiHelper.java:39)
	at de.firma.abrechnungstool.test.TestHibernate.main(TestHibernate.java:152)

----- NACHTRAG -----

Dir fehlt offensichtlich eine nötige Referenz. Du musst nachschauen wo die Klasse drin ist.

Ja, aber wie kann ich dem Projekt sagen hier bitte danke ...???

Ich hab das immer mit dem TotalCommander gemacht weil man mit dem relativ bequem auch in Zip-Files danach suchen kann. Das machst du dann einfach über's komplette JBoss Verzeichnis. Dann sollte er sie finden.

Ich suche nach einer JAR ... da finde ich 4644 jars ... mit der suche in den archiven komme ich auf 5408 jars ...

 

[JimPanse]

Bei älteren JBoss'en war eigentlich ausreichend die <jboss-home>/client/jbossall-client.jar einzubinden. Der NamingService für EJB sollte dort drin sein.

 

[brauner1990]

Eingesetzt wird noch leider der Jboss 5.1 ...

 

[schlingel]

Ja, aber wie kann ich dem Projekt sagen hier bitte danke ...???

Per Classpath? Keine Ahnung wie dein Client aussieht (Servlet? JSE Anwendung?)

Je nach dem musst du eben die nötigen JARs in's executable Jar deiner Anwendung schmeißen oder eben in's WAR.

 

[brauner1990]

Mein Client ist eine SWT - GUI (Kundenwunsch) welche aber Rechnungen erstellt (Rechnungsdatenerfassung dauert teilweise auch mal Stunden) weswegen ich hierfür eine MDB einsetze. Da sich die MDB Ansprache mit Hibernate in Konflikt gekommen ist, habe ich auch Hibernate auf die ServerSeite verfrachtet, was ja nicht schlimm ist ... aber jetzt kann ich ja nicht den JBboss veraussetzen, daher ... blöd

 

[schlingel]

Wenn ich das richtig verstanden habe kannst du beim Client nicht den JBoss voraussetzen, möchtest aber mit ihm komunizieren. Dann kannst du dir aber so was wie das jbossall-client.jar basteln.

Dazu lädst du dir am besten den Totalcommander runter, startest ihn und lässt ihn im Verzeichnis des JBoss nach einem File suchen, das den Namen "NamingContextFactory" enthält. Nicht vergessen, dass du ihn auch in komprimierten Files suchen lässt.

Nach dem Fund packst du das JAR-File in dem das Class-File steckt in dein eigenes myjboss-client.jar. Dann musst du natürlich noch das myjboss-client.jar zu deinem SWT-Projekt-Classpath hinzufügen und auch mit exportieren. Also entweder per Eclipse, oder im build.xml mit kopieren, keine Ahnung wie genau du das machst.

Dann probierst du ob alles läuft. Wenn dann wieder eine NotFoundException fliegt, wiederholst du das ganze mit dem neuen fehlenden Klassennamen.

Eine zermürbend langweilige Tätigkeit aber keine schwere. Musste ich mal machen nachdem wie von Jboss 4 auf Jboss 6 umgestiegen sind.

 

[JimPanse]

Eingesetzt wird noch leider der Jboss 5.1 ...

Ich habe ja auch geschrieben bei älteren JBoss'en dazu zähle ich alles > v.7

Ich denke mal das du versuchst über ein Lookup auf eine Remote Bean zuzugreifen d.h. in der jbossall-client.jar müsste eigentlich alle notwendigen Methoden enthalten sein. Jedenfalls brauchte man diese Lib damals wenn man über JUnit eine EJB Remote Bean per Lookup geholt hat und gegen den Lokalen JBoss getestet hat.

 

[schlingel]

[...]d.h. in der jbossall-client.jar müsste eigentlich alle notwendigen Methoden enthalten sein

Nope, seit JBoss 5 nicht mehr. Jetzt (oder ist das ab JBoss 7 wieder anders?) sind nur noch Verweise auf die anderen JARs drinnen, das heißt, man kann sich mit dem Jar auf einem anderen Server/PC brausen gehen da die Referenzen nicht aufgelöst werden können.

Das muss man so machen wie ich es beschrieben habe. Es geistern auch im Netz irgendwo die ganzen Auflistungen herum in welchem JBoss-Jar welche Class-Files enthalten sind. Ich war allerdings mit dem guten alten TotalCommander schneller als mir da alles zusammen zu suchen.

 

[JimPanse]

Nope, seit JBoss 5 nicht mehr. Jetzt (oder ist das ab JBoss 7 wieder anders?) sind nur noch Verweise auf die anderen JARs drinnen, das heißt, man kann sich mit dem Jar auf einem anderen Server/PC brausen gehen da die Referenzen nicht aufgelöst werden können.

Ich habe noch einen JBoss 5.1 bei mir auf der Platte gefunden - recht hast du... - jut dann halt mich mal lieber raus - doch schon zu lange her:bae:

 

[brauner1990]

Ja, jede Lib muss bei 5 selber eingebunden werden, leider wollte ich dies eigentlich vermeiden ... sch**** .... naja, dann wird das wohl doch müssen, gefällt mir zwar nicht, aber bleibt ja nix anderes übrig ...

falls jmd eine bessere Idee hat, her damit!!

 

[FArt]

Ja, jede Lib muss bei 5 selber eingebunden werden, leider wollte ich dies eigentlich vermeiden ... sch**** .... naja, dann wird das wohl doch müssen, gefällt mir zwar nicht, aber bleibt ja nix anderes übrig ...

falls jmd eine bessere Idee hat, her damit!!

Das ist nur eine Hand voll. Alle in Frage kommenden JARs liegen unter jboss/client . Ich persönlich finde diese Variante wesentlich besser als das dicke "all-client" Archiv.

In der Zeit der Modularisierung ist es wichtig seine Abhängigkeiten zu kennen und zu pflegen. Wer das auf die leichte Schulter nimmt sollte zur Wartung seiner Software auf mindestens 10 Jahre verurteilt werden, inklusive mindestens dreier JBoss Migrationen.