Your pom has the metro and this is problematic to work with CXF's tool.
Please replace this dependency with CXF's.
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>rt</artifactId>
<version>2.3.2</version>
<scope>runtime</scope>
</dependency>
On Sat, Nov 11, 2023 at 9:35 AM Mark Streit <[email protected]> wrote:
> 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
>
