Jim Ma
Many THANKS for pointing this out. Indeed, when I removed the original
entry that was entangled in Metro JAX-WS and replaced w/ the CXF
dependency.... *it processed MUCH farther*. Instead of failing where it
was originally trying to find a "Provider", it now passes much further to
the point of NOW making the call attempt but I am still seeing it error
in a different place in the code...
Nov 19, 2023 10:42:16 PM
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service {
http://localhost:8080/employee-service/EmployeeService}EmployeeService from
class com.example.jaxws.ws.EmployeeService
Nov 19, 2023 10:42:16 PM
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service {
http://localhost:8080/employee-service/EmployeeService}EmployeeService from
class com.example.jaxws.ws.EmployeeService
Nov 19, 2023 10:42:16 PM org.apache.cxf.phase.PhaseInterceptorChain
doDefaultLogging
WARNING: Interceptor for {
http://localhost:8080/employee-service/EmployeeService}EmployeeService#{http://ws.jaxws.example.com/}getEmployee
has
thrown exception, unwinding now
java.lang.NullPointerException: Cannot invoke
"org.apache.cxf.transport.http.Address.getURI()" because "address" is null
at
org.apache.cxf.transport.http.HttpClientHTTPConduit.setupConnection(HttpClientHTTPConduit.java:161)
at
org.apache.cxf.transport.http.HTTPConduit.prepare(HTTPConduit.java:551)
I have resumed a Google hunt for the error message shown above, but have
yet to find anything concrete beyond the fact that this error has been seen
by others ...
This is the furthest I have been able to get the test client to go so *thank
you* immensely for the valuable tip regarding the dependency change... I
was fighting with the original Provider issue for over a week making
countless changes with no success...
Mark
On Sun, Nov 12, 2023 at 8:10 PM Jim Ma <[email protected]> wrote:
> 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
> >
>
