When does this error happen? Still in code generation with cxf tools ?
It seems this is generated from the java classes instead of from the wsdl
file . Did you pass the correct wsdl url to the cxf tool ?
On Mon, Nov 20, 2023 at 11:57 AM Mark Streit <mcs...@gmail.com> wrote:
> 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 <mail2ji...@gmail.com> 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 <mcs...@gmail.com> 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
>> >
>>
>
