axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <>
Subject Re: doLocal, jws, and http in general
Date Tue, 12 Jun 2001 13:37:48 GMT
This jws stuff all depends on which piece of logic you're talking
about.  Like Glen said there are two pieces, the piece that maps
the URL to a file on the file system, and then there's a piece that
actually processes the file.  If certain transports (or the doLocal
option) are configured so that they by-pass the handlers that
do the URL->file mapping then yes additional lines of code will
be needed for those transports (the lines you pointed to).
I do agree with you that the Servlet logic should be kept in the
'servlet logic place' - the question is: is that in the servlet
or in a transport specific handler.  Either is valid.

In your doLocal transport that you just created it needs to either
have the jws XXX(url?)->file mapping inside of it, or you
need to define a doLocalTransport specific handler and make sure
that that handler is on your transport specific chain (on the
server) so it can get executed and do the mapping for you.


Sam Ruby/Raleigh/IBM@IBMUS on 06/12/2001 09:26:11 AM

Please respond to

Subject:  Re: doLocal, jws, and http in general

Glen Daniels wrote:
> I think the way it works now is exactly right.  A (usually
> transport-specific) Handler notices the fact that the desired thing is a
> file, and sets the JWSFileName property appropriately.  Then it sets the
> target service to the JWSProcessor.

Does this "I think the way it works now is exactly right" apply to lines
141-144 of


If not, where should this logic be?  In particular, where should the logic
be for a local transport?  This is the original question that spawned this
thread, and as far as I can tell has gone unanswered as of yet.  I do
believe that JWS should be supported by a local transport...

> And on the larger "servlet vs. 'generic' HTTP" question, I pretty firmly
> believe we should just go with the servlet APIs for HTTP.  Servlets are
> standard Java way to do HTTP server stuff, and if someone really wants to
> build another HTTP server (like the SimpleAxisServer), I think the way to
> is build very lightweight implementations of
> and use those, so that everyone has a single paradigm/API for dealing
> HTTP-specific things.  The other option I see is defining our own set of
> APIs for getting at the HTTP context/headers, and mapping all the servlet
> classes into that.  Using the "optimize the common case" logic, I think
> easily 90% of our users (or more) are going to have a servlet engine if
> want to use HTTP, and requiring servlet.jar (35K) and a little shim code
> the other cases doesn't seem like that big a deal.

Having dones this several times (for PHP, and Cocoon, and others), I can
tell you that this is not as easy as it sounds.  The hardest thing is the
creation of a stub servlet context, then there is dealling with deprecated
APIs, and to compile across the various levels of the servlet specification
requires the use of reflection...

I do agree that all production deployments should be done with a servlet
engine.  I even put comments to that affect in SimpleAxisServer.

Where I find a lighter weight implementation handy is debug, functional
test, and performance profiling.

If you look at the way that communication across Handlers currently occurs,
it is primarly through the one handler placing data that might be useful
downstream into the "bag".

What I find confusing/inconsistent is that AxisServer puts the SoapAction
separately into bag, but requires the JWSHandler to get the URL from the
config, context, and servletPath in order to determine the real path.

My personal feeling is that - from a maintenance perspective - the dealings
with the servletAPI should be encapsulated into AxisServlet.  This way, as
the servlet API evolves (or somebody wants to support a backlevel but
popular implementation like jserv), the changes are in one place (or at
worst, there is a Servlet API 2.0 equivalent version of

- Sam Ruby

P.S.  I'm much more morally opposed to the creation of a new PROTOCOL,
a.k.a. the TCP Transport.  If this could have been done without headers, I
would have been OK with it, but since headers are required...

View raw message