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: 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.
Transport
>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
(in
>a transport-specific dispatch handler like the URLMapper or
>HTTPActionHandler).
>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
in
>calling the logic in (3) and therefore registering any service-specific
type
>mappings.

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
element.
>The difference is that at that point, some of the Handlers on the
processing
>chain MAY have registered themselves as the "ElementHandlers" for
particular
>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
believe
>it solves some of the problems that streaming solves, and it will be
pretty
>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
>two.
>Thoughts?
>--Glen

Doesn't seem as clean to me - what happens if someone writes an
deserializer/
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.

-Dug



Mime
View raw message