axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <>
Subject Re: DebugHeader
Date Fri, 11 May 2001 15:11:28 GMT
This thread brings up all sorts of interesting architectural issues.  I
spent some time debugging on the plane ride back home, just to determine
that the DebugHandler was to "blame".

What I trying to do is to support interoperability with implementations
which do not send xsi:type.  What I had done was to add some code which
defaulted the xsi:type based on introspection and reflection of the service
method.  There is no reason why this can't be done in one pass in the
overwhelming majority of cases - even when we support determining the
TargetService based on the method element in the SOAP body.

Unfortunately, the DebugHandler is listed in the global.input chain, and
the first thing it does is request a parse of the entire envelope on the
off chance that it might possibly need something.  And, of course, this is
done before the TargetService is determined.

If you also look at the intended purpose of the DebugHandler, you would
come to the conclusion that it would be beneficial for this header to be
processes as early as possible.

IMHO, the problem is that the architecture prior to the intoduction of SAX
provided no flexibility as to where handlers are attached - they all were
implicitly attached to the envelope.  I prefer that this were changed so
that handlers could be associated with any element.  Once attached, they
can choose to consume the element, replace it with something (a set of
recorded SAX events, PurchaseOrder, or a set of headers), or simply pass
the element on down the chain unmodified.

In other words, one behavior of such an attached handler would be to act as
a deserializer.

I would like to see the concepts of deserializers and handlers merged.

- Sam Ruby

View raw message