axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <>
Subject Re: [Architecture Improvement] Handler lifecycle events and undo()
Date Sun, 16 Dec 2001 03:14:02 GMT
Berin Loritsch writes:
> Here is what the Avalon team has learned in respect to Lifecycle:
> 1) Not every component will need every lifecycle interface
> 2) A collection of components will more than likely need all lifecycle
>     interfaces.  While it is rare for one component to use all of them,
>     when you have a number of Components with different needs, each will
>     use a different set--and eventually all lifecycle methods are needed.
> 3) Event based systems scale better than monolithic ones (i.e. SAX vs.
>     DOM, non-blocking vs. blocking IO, event based architecture vs.
>     thread per client architecture).
> In order to address this, the Avalon team developed a set of interfaces
> that handle different aspects of the lifecycle.  The lifecycle follows
> a well defined path so as not to confuse people unnecessarily.

While this framework certainly could be used to indicate the
nature of the chosen lifecycle, it doesn't address real issue we
were discussing: what is the lifecycle of the handlers? Once that's
decided I have no objection with using Avalon to actually indicate
the lifecycle.

> Getting back to the init()/destroy()/delete() functionality issues, it
> is incorrect to force _all_ Handlers to define them.  A Handler's
> should only support the methods required to *Handle* a request.  All other
> methods that are sometimes required should be placed in other interfaces.

The real question is what things the Axis engine should check for
in the handler: init-able, destroyable, undo-able or ..? All
you've done is separated these into separate interfaces. That's good
because its proper separation of concerns (as you noted), but it
doesn't help decide the question of whether something should be
init-able at all.


View raw message