Search the FirstSpirit Knowledge Base
Hallo,
ich versuche in einem Executable, welches in einem FS Modul hinterlegt ist, einen Apache CXF Soap Client zu verwenden. Lokal kann ich den Client ohne Probleme ausführen, wenn ich allerdings das Executable im FS Client starte bekomme ich eine ClassCastException weil anscheinend com.sun.xml.ws.client.sei.SEIStub (rt.jar) vor den CXF dependencies im ClassPath liegt und daher der CXF Client die falsche Implementierung verwendet.
Ich hab bereits versucht, den Soap Client als eigenständiges Projekt zu implementieren und die daraus resultierende Jar Datei im Verzeichnis /shared/lib zu platzieren, damit das Jar u.U. früher im ClassPath landet, leider scheint die Jar aber nicht im Module Class Loader sichtbar zu sein, sodass eine ClassNotFoundException auftritt.
Kann mir jemand bei diesem Problem weiterhelfen? Wie schaffe ich es, dass mein Soap Client die CXF Implementierung "ClientProxy" anstatt den "SEIStub" verwenden kann?
Danke für die Antwort. Hab ich alles schon probiert, die von Ihnen geposteten Links sind mir also nicht unbekannt.
Ich hab das Problem soeben gelöst indem ich eine korrekte Sprint-Konfiguration für CXF geschrieben habe und mir meinen client über den sprint context per "getBean" hole.
Zusätzlich biege ich mir dass ClassLoading per
Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());
zurecht.
Auf diese weise scheint es keine Probleme mit dem Class-Path zu geben.
wie sieht denn der komplette stack aus? wie wird das jar definiert im modul?
evtl. hilft:
http://stackoverflow.com/questions/5670343/cxf-classcastexception-seistub-clientproxy
Lösung vermutl. JaxWsProxyFactoryBean nutzen
http://stackoverflow.com/questions/2064068/how-to-pick-cxf-over-metro-on-glassfish
Danke für die Antwort. Hab ich alles schon probiert, die von Ihnen geposteten Links sind mir also nicht unbekannt.
Ich hab das Problem soeben gelöst indem ich eine korrekte Sprint-Konfiguration für CXF geschrieben habe und mir meinen client über den sprint context per "getBean" hole.
Zusätzlich biege ich mir dass ClassLoading per
Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());
zurecht.
Auf diese weise scheint es keine Probleme mit dem Class-Path zu geben.