axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <ru...@us.ibm.com>
Subject doLocal, jws, and http in general
Date Mon, 11 Jun 2001 20:55:05 GMT
I got do-local working again with deploy and non-JWS stock quote.  I'll add
an echo functional test shortly to ensure that this continues to work.

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.

The HTTP and TCP transports are still being passed the value of doLocal -
even though it no longer makes any sense.  I'd like to remove it, but I
noticed some code tucked away in the HTTPTransport class that attempts to
make JWS work.

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.
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.

Thoughts?

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

- Sam Ruby




Mime
View raw message