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.
> 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?
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.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com