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, th
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 acc
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 lo
Per Olesen wrote:
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 don
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 t
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 wa
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 :)