axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <>
Subject Re: doLocal, jws, and http in general
Date Tue, 12 Jun 2001 01:38:18 GMT
Rob Jellinghaus wrote:
>>Oh, one other thing - I defined an init method on my
>>LocalDispatchHandler...when should it have been called?
>Where did you get the idea to define an init method?  There are no init
>methods on the HTTPDispatchHandler or TCPDispatchHandler.


Line 69 is:

public class LocalDispatchHandler extends BasicHandler {

And going to

Lines 77 through 83 read:

/** Stubbed-out methods.  Override in your child class to implement
 * any real behavior.

public void init()

What's the point of inserting "real behavior" in an init method if it never
gets called?  If this "init" belongs on AxisEngine, then lets simply remove
it from here.

- Sam Ruby

Rob Jellinghaus <> on 06/11/2001 07:31:28 PM

Please respond to

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

At 04:55 PM 6/11/2001 -0400, Sam Ruby wrote:
>The way do-local works now is that there is the trans-input handler
>(typically HTTPSender) is replaced with a LocalDispatchHandler.  Unlike
>previous doLocal design, the current design has both a AxisClient and an
>AxisServer, two sets of messageContexts, and two sets of chains - the
>"transport" is merely copying the messages from one context to the other.
>In fact, the messages are even forced to Strings so that serialization to
>XML and deserialization is exercised.

This is interesting to me, partly because one of the next things on my list
(after session & cookie support, coming Real Soon Now) is an example of an
Axis gateway, i.e. a message relay.  This will be basically the inverse of
your do-local example, in some sense.  Your do-local has basically a client
which routes directly into a server (no actual network involved).  The Axis
gateway sample will have a server which routes directly into a client,
which forwards the message onwards to some subsequent destination.

>The right way (IMHO) for JWS to work is for there to be a transport
>specific handler which has the responsibility to set the service.

The confusing thing to me, here, is that there are two senses of "service"
where JWS is concerned.  There is the actual service (say,
"urn:xmltoday-delayed-quotes"), and there is the JWS provider (the
JWSProcessor) which loads & runs the JWS class.  It's not clear to me how
both of these should be treated in the Axis architecture.  Is
"urn:xmltoday-delayed-quotes" the targetService?  Or is JWSProcessor?  And
what about SOAPAction?

In some sense, I think the most correct thing would be for JWSProcessor to
be a global handler, which reads the URL, detects that it is a .jws URL,
does the service-load-and-compile, and sets the service handler.  Then the
actual end-of-the-line provider would be the plain old RPCProvider just as
for all other Java service invocations.

Or perhaps I am off in left field, because what I'm talking about doesn't
seem to have anything to do with your discussion below:

>Unfortunately, the current "http" JWS handler is in reality a "servlet"
>handler - it requires a servlet so it doesn't work with the
>SimpleAxisServer which does process HTTP.  My thoughts are to modify this
>handler to have all the JWS specific dispatching decisions in it, and make
>it aware of servlets, the SimpleAxisServer, and the doLocal alternative.
>Alternatively, I could split it into three separate handlers.  What I
>particularly care for is the current situation where jws specific logic is
>in multiple places.

Basically, I agree that jws logic should be as centralized as possible :-)

>Oh, one other thing - I defined an init method on my
>LocalDispatchHandler...when should it have been called?

Where did you get the idea to define an init method?  There are no init
methods on the HTTPDispatchHandler or TCPDispatchHandler.  The only init
method I'm responsible for is Transport.init which is basically just for
the sake of client side setup.  (and I am amenable to changes there if
people come up with a better way to do what it is trying to do.)  But
Transport, and its subclasses, are not DispatchHandlers in any sense.

(I still want to rename DispatchHandler to Sender.  Any strong objections,
over and above the normal objections to renaming files in CVS?)


View raw message