axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels" <>
Subject Re: New Handler design - what do you think??
Date Fri, 25 May 2001 02:01:08 GMT
> Overall: +1
> At 08:38 PM 5/24/2001 -0400, Glen Daniels wrote:
> >Handlers can do two sorts of things.  They can simply be invoke()d with a
> >MessageContext, just like we do now, OR they can act as SAX event sinks
> >(probably there are two different classes/interfaces).
> MessageHandler and MessageElementHandler, respectively?

Sure, that sounds good.

> >We imagine a
> >"Manager" class (a better name will be thought of) whose responsibility
> >is to pass the right things to each handler in the chain.
> MessageElementDispatcher?

Also sounds fine, though I'm not as jazzed about it for some reason.

> >But for each element, it now builds a list of which Handlers
> >are "interested" in that element.
> Conceptually, this is an optimization.  It sounds like a simplified
> (inefficient) version of this model would pass *all* SAX events to all
> handlers all the way down the chain, with most handlers ignoring most
> events.  True?

Absolutely right.

> >IMPORTANT : Handlers may PARSE events at will, caching them internally or
> >translating them into more compact forms.  However, they may ONLY "run"
> >(i.e. perform any substantive processing, affect the MessageContext or
> >external state) AFTER all "gated" Handlers before them on the chain have
> >allowed them to.
> It's not clear from this description exactly when they *do* run, though.
> think I understand ungating, but I don't understand exactly how or when
> run() (process()? invoke()? what?) method gets called on a given Handler.

Handlers at the head of the chain are free to run at will.  Imagine a
"canRun" flag which is set to true for all Handlers up through the first
gated one.  Those guys are free to do any processing they want as the SAX
events come through, and Handlers with canRun==false simply parse.  Then
when the first gated guy tells the dispatcher he's done, the dispatcher
allows all subsequent Handlers up to the next gated one to go, etc....

> >NOTE : the "jukebox" handler is special.  He contains a registry of ALL
> >elements that ANY of his "contained" handlers might be interested in.
> >the Manager asks if he's interested in a particular thing, he answers
> >if he has an internal Handler registered for that thing.
> Isn't that just exactly what *all* Handlers do in this model?  i.e.
> the Manager need that state for every Handler (every MessagePartHandler,
> anyhow) already?  What does the jukebox handler add?  It seems that it
> adds a single "ungate location" -- i.e. once it becomes ungated,
> inside it can run.  That doesn't seem to need a whole Handler; it's just a
> one-ungating-many arrangement.

A couple of things here.  First, the jukebox provides a convenient place to
sequence the running of a bunch of "random access" handlers.  You could even
have several jukeboxes interspersed with ordered handlers.  Second, there
may be a LOT of potential handlers registered with the jukebox, and no one
will need to bother specifying an order for them, and only the ones that get
activated will actually run.  I'm not 100% sure I got your point, though...

> >8. Manager sends events for Debug to LogHandler, then output of
> >   to DebugHandler
> >
> >9. DebugHandler sets debug level,
> Does it do this in its run() (or process()) method (since this affects
> external state)?  Can it call its own run() method since it is implicitly
> ungated (being at the front of the chain)?  How do MessagePartHandlers
> indicate whether they are gating / gateable?

See above.  Gating is a deployment-time configuration.  I.e. the same
Handler may be deployed as gating or non-gating.  I think.

> >   then tells Manager it's done (i.e. the
> >   gating condition is satisfied and other Handlers may run).
> Maybe this is implicit in it calling its own run() method (i.e. if you are
> ungated and you run(), you implicitly ungate everything after you)

correct.  But it's nicer to have the "done()", I think, since you may start
running, then stop, then start again after more events, all before you

> >10. Manager then tells Auth Handler it can run
> Why does it do this now?  Did AuthHandler express a desire to be run at
> some point?  (if so, I missed it)

Right, that wasn't explicit.  When AuthHandler got the end of the Auth
header, it stored some kind of state such that when the Dispatcher/Manager
pokes it and tells it "you can run if you want to", it just goes.


View raw message