Kohsuke Kawaguchi wrote:
> Paul Sandoz wrote:
>
>> That would be useful and defintely makes sense to easily reduce the
>> size for Mustang.
>
>
> A related (but separate) proposal along the line is to move the
> servlet related code and Light-weight HTTP server related to code into
> their own modules.
>
> The reason for doing those is to show that those transports are really
> pluggable --- I've been reorganizing the server side code so that we
> can have 'servlet' and 'j2se-http' (or some such) modules completely
> outside of the core runtime. And they are each relatively small.
>
> So when we tell people that they can plug this into their own system
> (be it their e-mail server, or JBI container, ...), we can just point
> them to those modules that that's how they'd be doing it.
>
> Also, When you have separate modules, it makes you think where to put
> your code, and that's a good thing. I think that's a good thing.
>
Not a bad idea.
>
>> In the future this may also be useful for customers that need to
>> provide some information on a bug e.g. we are planning to provide
>> plubable transports, and such a plugable transport could be the local
>> transport. Using the local transport without any client code
>> modifications could be any easy to not only debug client/server in
>> one address space but also to get access to SOAP messages.
>
>
> Yes. I agree that we need to have a better debugging story. What
> JAX-WS RI itself is doing today is something like...
>
> (From Java SEI...)
> 1) write the server program
> 2) write the client program
> 3) pack the server side in a WAR layout
> 4) run a tool to generate WSDL
> (just so that clients can run)
> 5) run
>
> If you think about the build script that's written to hook things up
> together, I think this is just too much work for one test.
>
> I don't know yet how to do it properly, but how about something like:
>
> 1) write server and client program
> 2) run it like
>
> // this sets up a local transport.
> Service srv = new LocalService(new ServerImpl());
> SEI sei = srv.getPort(SEI.class);
>
> Or what if we use JavaScript for client? To get rid of th compilation
> of the client altogether?
>
This maybe fine for some tests, but for many if not most tests we are
also testing that the generated client side and
server side artifacts are correct.
> And in any case I think it's crucial for the entire process to run in
> a single VM, partly because of a performance reason, partly because of
> ease-of-debugging, partly so that we can get rid of the Ant script.
>
If you can figure out how to do it in one VM while maintaining client
and server side code generation, I am all for it.
--
- Doug