Hello All

I'm fairly well-versed in JAX-WS web services going back to the days of the
original JSR-224 spec and the "Sun Metro" JAX-WS RT and API stack. I have
not used JAX-WS services and tools since we moved to Spring Boot
around 2016.  I'm now finding myself working on a project that uses WildFly
(v27 specifically) and SOAP web services.

While doing a very simple POC exercise, I have a JAX-WS web service
packaged in a WAR (build w/ Maven) and deployed and running on WildFly - no
issues there. I can get back the WSDL document from the "running" service
on port 8080. (A default standard instance of WildFly running - *JDK 17
Corretto)*.  I've also discovered that the tools in WildFly (such as
*wsconsume* to generate java artifacts, *are using CXF* under the hood -
"wsdl2Java"?).


**** This class was generated by Apache CXF 3.5.2-jbossorg-4*

Hence I'm taking a longshot chance asking this question here as I've been
struggling to get a JAX-WS Client built that will run from a simple Java
standalone code block w/ a main().  Nothing more complex than that. I have
posted the issue to the Stackoverflow forum to see if anyone has seen
something similar.

1) the client code is extremely simple and is attempted to be run from
inside the IntelliJ IDE.
2) I have debugged the client code stepping into the code where it blows
apart w/ the message seen below.

java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)

    at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)

    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)

    at java.base/java.lang.Class.forName0(Native Method)

    at java.base/java.lang.Class.forName(Class.java:375)

    at jakarta.xml.ws.spi.FactoryFinder.isOsgi(FactoryFinder.java:214)

    at jakarta.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:124)

    at jakarta.xml.ws.spi.Provider.provider(Provider.java:64)

    at jakarta.xml.ws.Service.<init>(Service.java:82)

    at jakarta.xml.ws.Service.create(Service.java:735)

    at com.example.jaxws.ws.client.WSClient.main(WSClient.java:21)

jakarta.xml.ws.WebServiceException: Unable to createEndpointReference Provider

    at jakarta.xml.ws.spi.Provider.provider(Provider.java:68)

    at jakarta.xml.ws.Service.<init>(Service.java:82)

    at jakarta.xml.ws.Service.create(Service.java:735)

    at com.example.jaxws.ws.client.WSClient.main(WSClient.java:21)

Caused by: java.lang.ClassCastException: class
com.sun.xml.ws.spi.ProviderImpl cannot be cast to class
jakarta.xml.ws.spi.Provider (com.sun.xml.ws.spi.ProviderImpl and
jakarta.xml.ws.spi.Provider are in unnamed module of loader 'app')

    at jakarta.xml.ws.spi.Provider.provider(Provider.java:64)


*Everything is described on this
post 
https://stackoverflow.com/questions/77456843/jax-ws-web-service-client-jdk-17-simple-java-client-w-a-main-fails
<https://stackoverflow.com/questions/77456843/jax-ws-web-service-client-jdk-17-simple-java-client-w-a-main-fails>
 The post includes the relevant Java code blocks and the pom.xml content. *


3) The client code was built w/ Maven using a terminal window and typical
mvn clean install -U
4) A JAR file is created - when you right-click and run it from inside the
IDE, it finds main() and hits the breakpoints as expected...

It's clearly a runtime classpath problem or mistake that is causing the
issue and I have spent hours changing attributes in the pom.xml, adjusting
the "Run Configuration" within IntelliJ  --- all to simply land on the same
Exception when it tries to create the proxy object for the client side
call.

There have been many posts re: the repackaging of the JAX-WS components
from "javax" to "jakartaee" following the release of JDK 7 or 8 *and onward*.
It's not clear that this has anything to do with it since compile time
building is always successful.

While I don't suspect this is a "CXF Problem" directly, I am hoping someone
may be familiar w/ such an exception.


Thanks for any input

Mark

Reply via email to