axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <...@us.ibm.com>
Subject Re: doLocal, jws, and http in general
Date Tue, 12 Jun 2001 09:29:19 GMT
The 'init' method or I should say the 'init' discussion was
never really completed.  A lot of it all depends on how the
lifecycle of handlers are eventually going to be done.
'init' is there to allow handler to, obviously, init them-
selves.  The question is when should it be called: when
it's first new'd or at first execution for each new service.
Glen had started some work on lifecycle of handlers a long
time ago but I believe at one of the f2f's lifecycle was
either dropped or chosen to just be ignored for the time.
So, perhaps this is a good time to reopen the discussion
and settle it once and for all.
-Dug


Sam Ruby/Raleigh/IBM@IBMUS on 06/11/2001 09:38:18 PM

Please respond to axis-dev@xml.apache.org

To:   axis-dev@xml.apache.org
cc:
Subject:  Re: doLocal, jws, and http in general



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.

From:

http://xml.apache.org/websrc/cvsweb.cgi/xml-axis/java/src/org/apache/axis/transport/local/LocalDispatchHandler.java?annotate=1.1



Line 69 is:

public class LocalDispatchHandler extends BasicHandler {

And going to

http://xml.apache.org/websrc/cvsweb.cgi/xml-axis/java/src/org/apache/axis/handlers/BasicHandler.java?annotate=1.6


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 <robj@unrealities.com> on 06/11/2001 07:31:28 PM

Please respond to axis-dev@xml.apache.org

To:   axis-dev@xml.apache.org, axis-dev@xml.apache.org
cc:
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
the
>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"
JWS
>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
don't
>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?)

Cheers,
Rob







Mime
View raw message