avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: a view of the Avalon Container
Date Mon, 19 Aug 2002 18:14:22 GMT
> From: Leo Simons [mailto:leosimons@apache.org] 
>
> Could someone please fill me in where this little analysis goes awry?

Nowhere, really, if you can pull it off.

But I agree with Peter Donald's arguments against lifecycle extensions. 
Nice in theory and all, but how are you actually going to *do* it?

I have taken a look at Merlin (these classes:
http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-excalibur/assembly/src/
java/org/apache/excalibur/container/lifecycle/ )
and as far as I can see, the pluggable pipeline stages (or phases, or 
whatever), are limited to act on (1) the component/object and (2) the 
Context.

So... not only will the component have a type specifier that explains 
what context entries it requires and what special lifecycle handlers 
it requires - those handlers will also have a context requirement.

So if you have a SpiffyLifeCycleStage that makes components all spiffy 
as they come through it, how is that SpiffyLifeCycleStage going to do 
it without support from the container to put a Spifficator (the means 
to make a component spiffy) in the context?

If you have a PersistentLifeCycleStage, how are you going to obtain 
the persistence mechanism if the container doesn't give it to you via
the context?

The problem with populating the context with any non-constant entries 
(such as a Spifficator) has already been discussed and found to have 
no solution short of mind-reading the programmer and sprouting new code 
on startup/linking.

If I am missing something, and there are solutions to the problems I 
outlined above, please fill me in.

At the moment, the lifecycle extensions appear to be shiny new features
that while nice in theory are useless in practice. I'm afraid that any
container trying to implement them in a useful way will (1) never be
completed and (2) implode under its own weight. It's just too much "do 
everything", too much genericism, in it.

Miscellaneous issues:

  + Will the lifecycle handler need a component/service manager?
    How will a DB-persistence handler work? Will it use the Excalibur 
    Datasource component? How will it access it?

  + If the handler requires another component, has a context and surely
    will need a configuration, what is the difference between it and
    a component?

  + Go back to the final proposal for A5. Doesn't it solve everything
    by allowing/requiring you to specify handlers/factories for
components?

/LS


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message