Klient JAX-WS Dispatch działał poprawnie, dopóki nie dodano pliku wlfullclient.jar.

Question

Mam autonomiczny program wsadowy, który działa na jdk1.6.0_31. Ten samodzielny program ma klienta JAX-WS i klienta EJB. Klient JAX-WS działał poprawnie bez dodawania żadnych słoików, dopóki nie dodałem pliku wlfullclient.jar dla klienta EJB. Teraz z wlfullclient.jar w ścieżce klas otrzymuję poniżej wyjątek. Daj mi znać, jak rozwiązać ten problem. Doceniam Twoją pomoc.

Exception in thread "main" java.lang.NoClassDefFoundError: com/sun/xml/ws /spi/ProviderImpl 
at java.lang.ClassLoader.defineClass1(Native Method) 
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) 
at java.lang.ClassLoader.defineClass(ClassLoader.java:615) 
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) 
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) 
at java.net.URLClassLoader.access$000(URLClassLoader.java:58) 
at java.net.URLClassLoader$1.run(URLClassLoader.java:197) 
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 javax.xml.ws.spi.FactoryFinder.safeLoadClass(FactoryFinder.java:150) 
at javax.xml.ws.spi.FactoryFinder.newInstance(FactoryFinder.java:30) 
at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:90) 
at javax.xml.ws.spi.Provider.provider(Provider.java:83) 
at javax.xml.ws.Service.<init>(Service.java:56) 
at javax.xml.ws.Service.create(Service.java:691) 

Answer 1

Czy masz na to szczęście? Występuje dokładnie ten sam problem, który występuje na JetSpeed ​​2.2.2 (serwer portalu oparty na tomcat). Zanim dodaję plik wlfullclient.jar do folderu lib serwera, moja usługa sieciowa działa poprawnie. Po włączeniu wysypuje się na instancję dokładnie ze śledzeniem stosu, które umieściłeś powyżej.

Moje myślenie (teoretyczna na tym etapie) jest następujący:

wlfullclient.jar ma klasę, która ma taką samą nazwę i pakietu jako klasa już w Metro usług internetowych stosie. Ta klasa jest ładowana przed klasą Metro, a następnie kieruje ładowanie klasową ścieżką ładowania implementacji logiki sieciowej zamiast implementacji sieci. Implementacje logiki internetowej nie istnieją (nie jest tak, że podjęliśmy wysiłek, aby je uwzględnić, ponieważ chcemy używać standardowego java), a to tłumaczy NoClassDefFound.

Warto zauważyć, że nie znalazłem tej rzekomej klasy o tej samej nazwie i nazwie pakietu zarówno w Metro, jak i wlfullclient.jar. W tym sensie klasa jest w tym momencie podobna do bozonów Higgsa. Następnie zakładając, że istnieje, co z tym zrobić?

Chciałbym wiedzieć, czy znalazłeś rozwiązanie.

Również należy dodać:

muszę to wlfullclient.jar jak jest ona wykorzystywana przez innych portletów uruchomionych na tym samym serwerze. Nie mogę go usunąć, ale nie używam go sam.

Answer 2

Mieliśmy ten sam problem, po zbadaniu i znalezieniu tego pytania, poszedłem za przeczuciem i zajrzałem do dokumentacji serwera Weblogic.

Szukałem alternatywnych klientów.

Istnieją trzy słoiki klienta:

• wlclient.jar - dla IIOP klientów
• wlfullclient.jar - za wszystko w jednym słoiku (masywny rozmiar ~ 50MB)
• wlthint3client.jar - dla bardzo cienki klient t3

Ostatnią opcją jest odchudzona wersja klienta, która obsługuje oparty na Weblogics zastrzeżony protokół t3. Ma pewne wady pod względem funkcjonalności, ale jeśli wszystko, co musisz zrobić, to porozmawiać z ejb na serwerze: wszystko tam jest. Po zamianie formularza wlfullclient.jar na wlthint3client.jar, wszystkie NoClassDefFoundError zniknęły.

Tutaj link do Weblogic Documentation.