axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <>
Subject Re: writing handlers
Date Fri, 01 Jun 2001 19:58:35 GMT
Glen Daniels wrote:
> OK, now you have the question of where you store whatever context data
you got
> from the header.  If it's a separate class like this, you need either a
> place to put context (like the Debug class), or you need some model of
how you
> share information between the header handler classes and a) other header
> handlers, and b) service classes.  This can get complicated pretty fast,
and it
> allows a lot of non-standard models for information sharing, which might
> interoperability.

The comment on interoperability sounds suspiciuosly like a strawman
argument to me.  The handlers as envisioned today are definately Axis
specific (i.e., not portable across implementations).

I do see the RPCDispatchHandler proposal as considerably simplifying
things, though we can certainly debate about whether it focuses on the 20%
case or the 80%.

The RPCDispatchHandler approach is simpler in much the same sense as the
Jukebox proposal is.  Sure, some handlers have requirements that can't be
satisfied this way, but for those that do, life is simplified.

As to your specific question: for those cases where there is a one to one
mapping between headers and method calls, then I see the RPCDispatch
handler putting the header information into the same place as every other
header handler does (most here seem to be presuming that it is in the
message context, but I would have thought it would be in the SOAPEnvelope,
whatever).  And then dispatching one method call per header received - if
there are two debug headers, there would be two method dispatches.  If you
want a different model, write your own handler.

Net: I'm +1 to both RPCDispatchHandler for Headers and Jukebox.  Basically
because they are non-core.  For Rob's benefit: I define this to mean that
if you don't use it, you don't need to pay for it.  Nothing specific to
this support is present in any methods that you need to process other
requests.  In fact, these handlers should be able to be removed from the
jar entirely with no other affect than things which directly depend on them
stop working.

- Sam Ruby

View raw message