axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels" <>
Subject Re: Compromise on streaming
Date Tue, 29 May 2001 12:11:57 GMT
> >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.

When does that happen?  As far as I can see, the situation you describe is
impossible with the current code.  Isn't that why we call it the "global"

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

We have exactly the analagous situation in the streaming model, which is
dealt with by queuing up all the SAX events until the service is determined,
then letting them all pass through the service chain.  In this model, we'd
simply record the headers we didn't understand, and when the service chain
got to run, it would likely end up doing the deserialization in the process
of asking for the headers.  Not really much difference there.  In each case
we need to record the events and then deserialize them afterwards.

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

It's precisely the same thing in both models with respect to this situation.
You still are supposed to put only parse-related logic in the parse methods,
and do all your "real work" in invoke().  Yes, you can certainly write a
Handler which does whatever it wants during the parse, but that's a
dangerous optimization which you take full responsibility for.

And from your next msg:
>oh yeah - special case logic - that'll clear it up  8-)

There is, I believe, way more special case logic in the full streaming
model.  We'd still want the exact same "master SAX recording" in that model
too, otherwise we'd likely end up with several copies of pieces of the event
stream, taking up more memory than a full single copy.

I think the suggested compromise actually takes a long step in the streaming
direction, but it's easier to write and easier to understand (imho) than the
full-on model with streaming processing that I suggested earlier.


View raw message