axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James M Snell" <>
Subject Re: Compromise on streaming
Date Tue, 29 May 2001 04:01:13 GMT

Looks good to me. 

- James Snell
     Software Engineer, Emerging Technologies, IBM
     James M Snell/Fresno/IBM -
    "God placed me on the earth to do a certain number of things. Right 
now, I am so far behind, I will never die." - Anon.

Please respond to 
To:     <>
Subject:        Compromise on streaming

OK, after thinking a bunch about the proposed new design for
Handlers/Deserializers, I came up with what I think is a reasonable
compromise which gets us in the region without going all the way into a
full-streaming architecture.  I would like to propose the following:

1) Introduce a new Handler method:

   public void registerDeserializers(DeserializationContext ctx);

   The purpose of this is to allow Handlers/Chains to register themselves 
SAX handlers for particular elements (esp. headers), and also any specific
type mappings they want to enable for deserialization.

2) AxisServer.invoke() will, before invoke()ing any Handlers, create a
DeserializationContext and allow all Handlers we know about (i.e. 
Input, Global Input) to register deserializers as described in (1).

3) Whenever the service is determined (i.e. as a result of calling
MessageContext.setTargetService()), we will ask the service Handler to
register its deserializers and any type mappings into the
DeserializationContext.  This will often happen before the parse starts 
a transport-specific dispatch handler like the URLMapper or

4) If the service has NOT been determined by the time the SOAPSAXHandler
arrives at the first <Body> element, it will attempt to set the service in
the MessageContext based on the QName of that element.  This will result 
calling the logic in (3) and therefore registering any service-specific 

So basically, we have what we've got now.  Handlers are invoke()d down the
chain until someone triggers the parse by asking for a Header/Body 
The difference is that at that point, some of the Handlers on the 
chain MAY have registered themselves as the "ElementHandlers" for 
headers - this lets developers choose to write a single class that both
deserializes and processes headers.  And also, service specific type
mappings will be engaged as soon as we figure out what the service is -
which MAY now happen during the parse when we get to the 1st body element.
This solves the problem Sam had with not registering all the type mappers
before doing the parse.

This model will parse the entire message as soon as someone asks for a
Header/Body element.  It does NOT provide for "streaming processing" (we
still rely on the AxisServer to walk the chain of invoke()s), but I 
it solves some of the problems that streaming solves, and it will be 
simple to add to the current code, and won't necessarily change the way
Handlers are written now.

Once I get commit access again, I can probably implement this in a day or



View raw message