Hi Daniel,
Thanks! You led me in the right direction, even though I was unable to use
your code directly as shown. You wrote:
Service service = new Service(serviceQName);
But that constructor is protected. And the no-args one uses a default
place for the wsdl (where it was at stub-generation
Per Olesen wrote:
Hi Daniel,
Thanks! You led me in the right direction, even though I was unable to use
your code directly as shown. You wrote:
Service service = new Service(serviceQName);
But that constructor is protected. And the no-args one uses a default
place for the wsdl (where it
Hi Andrew,
You can use
Service.create(serviceQName)
to avoid having to subclass Service.
Thanks for the input. I am using that now, as it seems just a little bit
cleaner :)
Hi,
I use the cxf-codegen-plugin maven plugin to generate java classes for a
wsdl of mine. I then use the generated service like this:
new FooService(wdlUrl, serviceQname).getFoo().bar(bleech)
But why does the FooService actually need the wsdlUrl again? I can see it
resolves it. I thought,
So, to try and answer my own question (and you might very well correct me
here, if I am wrong :-))
But why does the FooService actually need the wsdlUrl again? I can see it
resolves it. I thought, that when i chose the path of generating classes
from WSDL to java, I had done all the wsdl
Per,
Technically, JAX-WS doesn't need the WSDL again at runtime if you don't
want it. However, it does require a bit of extra configuration. The
main use of grabbing the wsdl at runtime is to grab the live
soap:address location. Basically, you could publish a static wsdl at a
known
