Bobby Bissett - Javasoft wrote:
> One approach to writing the mex client code would have been to use
> Dispatch (I think this is what you're suggesting) to send the mex
> request.
Yes, or even proxy, if MEX has a WSDL that describes the wire-format.
> but that seems like overkill to me. The request message is
> always known, so I can just stream it into the http connection. I also
> need to be able to send with soap 1.1 and soap 1.2 requests, which would
> mean having two sets of jax-ws objects to call instead of just creating
> two strings.
Sending a stock request is a fairly common thing to do, so if it's too
hard, then that's a problem we should fix in JAXB/WS. About SOAP version
difference, I thought JAX-WS would shield you from that.
>> If I remember correctly, Bobby had another requirement that he needed to
>> deploy a servlet that he uses to emulate a bogus response.
>
> Yep, that's the way the tests were written. If we start using the
> runtime transports at tool time, then your suggestion of just having a
> pipe the sends the responses would work. Or a jax-ws handler could
> probably do it, but there are two pesky details. One is the
> http-dependent part of the mex spec, and the other is that I need to be
> able to deploy a service that will not answer ?wsdl requests in order to
> make sure wsimport isn't succeeding to get the metadata when mex is broken.
OK. This is still a requirement, right? Letting you deploy a servlet is
a bit more work.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com