NoClassDefFoundError für com/sun/istack/logging/Logger in Glassfish v3

Ich habe eine Anwendung client ruft einen SOAP-Dienst. Ich habe wsimport aus der glassfish-distribution zu generieren, die die ws-Klassen, und alles funktioniert in Glassfish v2. Wenn ich es starten (webstart) aus v3, die app läuft einwandfrei, aber wenn ich initiieren einen SOAP Aufruf, bekomme ich

Exception in thread "Thread-146" java.lang.NoClassDefFoundError: com/sun/istack/logging/Logger
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
    at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
    at com.sun.jnlp.JNLPClassLoader.findClass(JNLPClassLoader.java:257)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
    at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
    at com.sun.xml.ws.policy.jaxws.WsitPolicyResolver.<clinit>(WsitPolicyResolver.java:62)
    at com.sun.xml.ws.policy.jaxws.WsitPolicyResolverFactory.doCreate(WsitPolicyResolverFactory.java:48)
    at com.sun.xml.ws.api.policy.PolicyResolverFactory.create(PolicyResolverFactory.java:58)
    at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:131)
    at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:267)
    at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:230)
    at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:178)
    at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:106)
    at javax.xml.ws.Service.<init>(Service.java:56)
    at (class generated from wsdl)
    at (SOAP call)

Kann ich noch nicht einmal den Namen der Klasse überall, und es scheint fast keine Bezugnahme auf es auf dem Netz.

BEARBEITEN Es in jaxb-osgi.jar

Nicht dieses soll zur Verfügung gestellt werden, die von glassfish? Sicherlich, wenn ich es mit meiner app stellt es führt zu einem Konflikt?

Hallo, möchte diese Frage wieder hoch. Leider sind die wiki-Seiten nicht mehr funktionieren, jetzt, dass Oracle und Java.net geändert haben, so drastisch, und ich konnte nicht herausfinden, die details (übergeben Sie den einfügen-das war sehr hilfreich). Also die situation ist diese, ich habe eine Java-Web-Start-Anwendung, aufrufen von web services aus dem glassfish v3 server. Es scheint zu 100% reproduzierbar. Das problem ist, dass die javaws (client jdk) ist 2.1 aber glassfish ist 2.2. Glassfish entscheidet, welche Gläser zu sagen, die web start-Anwendung zu laden. Die Ressourcen der web start-app verwenden, gehören: jaxb-api-os
Ich stieß auf das gleiche problem. Haben Sie jemals zu verwalten, um es zu lösen?

InformationsquelleAutor Draemon | 2010-03-03

3

Der Beschreibung Ihres Problems und die Schritte zum reproduzieren sind nicht klar, sondern an allen GlassFish-v3-bundles Metro 2.0 und Metro 2.0 enthält JAX-WS 2.2, die Auseinandersetzungen mit der JAX-WS 2.1 kommt mit Java SE 6:

Für eine detaillierte Analyse, Wann genau dies geschieht, finden Sie in diesem Wiki-Seite. Der Grund für diese Ausfälle ist, dass Metro 2.0 enthält JAX-WS 2.2, die Auseinandersetzungen mit JAX-WS 2.1 1 gebaut ist, dass in Java SE 6. Sehen Sie nur, diese Fehler, wenn Sie nicht installieren Metro 2.0 mit unserem Installations-Skripts metro-on-glassfish.xml/metro-on-tomcat.xml. Das ist der Fall, wenn Sie z.B. installiert Metro 2.0 für GlassFish V3 über das update-center oder, wenn Sie eine version von GlassFish V3 gebaut in NetBeans.

Die einfachste Lösung ist, laden Sie die Metro 2.0 nightly-build und führen Sie das Installations-Skript. Das Skript kopiert die Datei webservices-api.jar enthält die JAX-WS 2.2 API, in <java-home>/lib/endorsed. Alternativ können Sie natürlich auch manuell kopieren webservices-api.jar in eine geeignete endorsed-Verzeichnis.

Und weil com/sun/istack/logging/Logger ist eine Abhängigkeit von JAX-WS 2.2, sind Sie sehr wahrscheinlich in der beschriebenen situation in den genannten Wiki-Seite:

Metro 2.0 bundles JAX-WS 2.2. Java SE 6 enthält JAX-WS 2.1 (SE 6 Update 3 und eine ältere version enthalten, die JAX-WS 2.0). Das bedeutet, dass Java standardmäßig abholen der JAX-WS 2.1-APIs und-Implementierung-und code, der nutzt JAX-WS 2.2 Funktionen wird nicht funktionieren.
- Das klingt wie es könnte damit zusammenhängen, aber es klingt wie glassfish v3 ist gebrochen in diesem Fall. Verwendet habe ich das wsimport von glassfish v3 und bereitgestellt, die gleichen server. Ich lief dann den app-client über webstart (Java 6) und "boom". Das bedeutet, dass diese app-client kann nicht ausgeführt werden von jedem standard-j2se-installation - die irgendwie verfehlt das point-of-webstart. Es kann dazu führen, mich um eine Lösung jedoch.
- Das problem ist nicht, GlassFish v3, das problem ist in Java 6 und JAX-WS 2.2. So, da Sie Zeugen Jehovas sind, würde ich vorschlagen, zu verwenden, die wsimport gebündelt mit Java 6 für die client-Seite, in Ihrem Fall.
InformationsquelleAutor Pascal Thivent

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.