Bobby Bissett - Javasoft wrote:
> Wsimport uses mex to build the client artifacts, but only when
> retrieving the wsdl remotely. If the wsdl exists as a local file,
> there's no point in using mex. So mex tests can only be run when http is
> being used. Otherwise, the mex tests can be skipped (as long as they're
> run some times).
>
> As part of the mex tests, I have a servlet that contains hard coded
> messages that acts like a web service for mex to send requests to. I
> need to be able to deploy that servlet (2 java files and a web.xml) as
> part of the mex tests.
>
> Later, when we have a tcp mode or smtp mode or whatever
> (http://archive.salon.com/tech/feature/2001/05/10/pigeons/) then there
> will be something similar for those transports. But "local transport"
> isn't really a transport, so mex can't use it.
I think what needs to happen is for the client MEX implementation in
wsimport to use the same transport pipe implementations to talk to the
service.
I could be wrong, but I thought MEX communications are entirely based on
SOAP, so it should be possible to do so. In fact it's desirable to do
so, because that's the only way to make the transport truly pluggable.
If this is implemented, then MEX test could be made to work regardless
of the transport. That servlet needed to emulate various error scenarios
(and so on) could be rewritten as a server pipe, then the harness could
deploy the service by using that pipeline.
Then the harness can continue to "own" the communication channels
between the client and the service.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com