axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels" <>
Subject Re: writing handlers
Date Fri, 01 Jun 2001 20:50:24 GMT
Sam wrote:
> 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
> static
> > 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
> reduce
> > 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).

Yes, I guess I wasn't clear - what I meant by interoperable in this context is
about multiple Axis extensions playing well together.  I'd like to see lots of
publically available Axis "modules" that can plug into your server to give you
access to various SOAP extensions people come up with.  If they all use the
MessageContext in standard ways to share data, it's easy to write new
extensions that work with old ones that aren't under your control.  If everyone
uses a different context-sharing scheme, things get weird.

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

Sure.  But if you're using the MessageContext and/or the SOAPEnvelope, you're
already using Axis-specific code in your extension class anyway, so the benefit
of "not having to include anything from Axis" sort of goes away.  I'm not
denying that it's a handy model, but I'm not sure it'll be that much easier
than writing a Handler (at least, if Handlers are well-designed, it shouldn't
be :)).

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

Sure.  In both cases, I think that the idea is convenience, and the Jukebox
also gives you speed (in cases where you have a lot of potential extensions but
few actual uses thereof).


View raw message