Hi Kathy,
A few more rookie questions regarding provider & dispatch:
>> 1. server side is still running wsimport, even though it's a provider
>> endpoint - can be automatically detected and skipped.
>
> With a Dispatch client, it is not necessary to have a provider
> endpoint. Tests for Dispatch will need the flexibility to run against
> WSDL Endpoints as well.
Oh, I meant for Provider services... WebServiceProvider could be
detected and wsimport step skipped... But after thinking about that, is
Provider similar situation to the Dispatch client side? Namely that a
Provider-based service will still require use of wsimport or xjc?
Does whether or not the Provider code includes a WSDL make a difference
in whether wsimport/xjc will need to be run?
>> 2. client side is still running wsimport even thought it's a
>> dispatch... thinking of adding an boolean 'dispatch' attribute to
>> the <client> element in the descriptor. Since if client talking to a
>> WSDL-less provider, wsimport would obviously fail. Thoughts?
>
> That's ok, however, it brings up another issue regarding Dispatch
> clients using JAXB data binded Objects. The Dispatch test does need a
> way to use xjc to generate these objects before the tests. In some of
> the Dispatch unit tests with JAXB Objects, xjc is used while in other
> unit tests wsimport is the tool used. Developers might use either
> tool so it would be good if the test harness flexibility provided for
> use of either.
So will a dispatch always need to call one of those tools? Or are there
currently three tooling scenarios for a dispatch client: wsimport, xjc,
none?
thanks,
Ken