After generating JAX-WS client using the wsimport
wsimport -keep WebService.wsdl
What reason does JAX-WS have to look for the wsdl location at run time?
Is this a bug?
I found this great post: JAX-WS client : what's the correct path to access the local WSDL?
but it doesn't say why do we need the wsdl at runtime
A service endpoint interface or service endpoint implementation (SEI) is a Java interface or class, respectively, that declares the methods that a client can invoke on the service. An interface is not required when building a JAX-WS endpoint. The web service implementation class implicitly defines an SEI.
The files referenced by the <wsdl-file> element in the webservices. xml might import other WSDL or XML Schema Definition (XSD) files. Typically, all WSDL or XSD files are initially placed into the META-INF/wsdl directory when using Enterprise JavaBeans (EJB) or the WEB-INF/wsdl directory when using Java™.
Is this a bug?
No, this is not a bug, but reasonable from a conceptual point of view.
What reason does JAX-WS have to look for the wsdl location at run time?
At build-time, you generate classes from the WSDL which means you need to know what kind of operations the service supports and what structure the messages have (aka portTypes
, types
, messages
).
At run-time a whole lot of different information comes into play. For instance, the actual address the service runs on might have changed. The bindings
become relevant: Should messages be sent in SOAP 1.1 or 1.2 or are both formats ok? Futhermore, all sorts of policies (security, reliable messaging, etc.) might be attached to the service. All these things are dynamic and mostly irrelevant at build time. Ideally, you should be able to point your client at a different service that uses the same structure and it should work out of the box.
I'd like to answer another question I think you might have:
Isn't this a total overhead in cases where there is just one service that never changes?
Yes, it is. In cases where there is single service with a particular WSDL that never ever changes from its build-time state, reloading the WSDL at run-time is unnecessary and a waste of ressources. But JAX-WS would do a terrible job if it wouldn't allow for more complicated scenarios where information such as bindings or policies do change or where there is more than a single endpoint for the service.
Nonetheless, most JAX-WS implementations do allow for some mechanism to store the WSDL locally and not load it for invocations at runtime. In the RI, simply pointing the wsdlLocation
in your @WebServiceClient
to the file on the classpath should do the trick.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With