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.
>
+1 I think this is a required task for pluggable transports on the
server side. I presume that a servier transport module will implement a
pipe that is to be used?
Oleksiy and I planned to look more at this area to understand how JAX-WS
could be modified and other transports can be plugged in and how
services can be configured/deployed to use such transports with
appropriate containers.
Sounds like when you are finished reorganizing you may answer a whole
bunch of questions i have been stacking up and done a fair bit of work
to achieve this! :-)
>
>> 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?
>
Maybe i am missing something, but I suppose if you still have to compile
the server code i am not sure what the advantages are in avoiding
compilation of client specific code.
Ideally it would be great if the client code can be used without
modification with a local transport by specifying some configuration
properties.
> 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.
>
Yes.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109