axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <>
Subject Re: Compromise on streaming
Date Tue, 29 May 2001 11:00:25 GMT
Glen wrote:
>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 as
>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).

Keep in mind we might not know the global chain until *after* the
transport chain has been run.

>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

What about the case where the service specific deserializers were needed
for the headers too?  Remember, headers and the body are basically the
same thing.

>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

Doesn't seem as clean to me - what happens if someone writes an
Sax handler and an invoke method do they both get executed? Will the work
be done twice?  Your original approach seemed much easier to follow.  But
that's just me.


View raw message