Leo Sutic wrote:
>>From: Leo Simons [mailto:[EMAIL PROTECTED]]
>>
>>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.
>
>
Correct.
(if the extension handler actually needs any context information)
>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?
>
>
The container could do this using approach taken in Merlin.
Merlin provides complete suppoort for component profiles in which as
assemble can include context directives. This is the key to Merlin's
resolution to issues with Phoeix such as the prolific use of container
specific interfaces suchb as BlockContext. Merlin enables the assemble
or the develper to declare the context values. In addition, extesnions
are componets and can aquire services that need via classic dependecies.
>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?
>
>
1. via a context directive provided by a profile
2. via a service depedency
>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.
>
>
Incorrect.
Please to a checklut of Merlin and run the demonstrations. You will
find exampes of components that are suppllied with context valiues
beased on profile based directives. You will also find a coupe of
examples of extensions (yes - real components that are handled as fist
class componets my Merlin - don't be misslead by the lack of
component-oriented suport in other Avalon container - Merlin has sorted
this out).
>If I am missing something, and there are solutions to the problems I
>outlined above, please fill me in.
>
Merlin 2.0
Check it out.
Problems solved.
Solutions are working, demonstration available.
Tested and validated across several projects.
A collaborative project.
>
>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.
>
>
Ouch - !!
Take a look at Merlin - the code to implement this is rather small.
Yes - in the Phoenix linear model its a PITA - but Phoex isn't the
reference.The big kicker is that Merlin handles extensions as real
compoents - that changes everything - you end up with massive reuse -
the extension elememnts become minor in the overall scheme.
>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?
>
>
In Merlin an extension is a componet. It declares it depedencies just
as any othr componet declares dependecies.
I.e. No problem.
> + If the handler requires another component, has a context and surely
> will need a configuration, what is the difference between it and
> a component?
>
None.
That's one of the fundimentatal difference between Merlin and Phoenix.
Merlin is built using component oriented priocipals - Phoenix is a
componet management system built using object oriented principals. The
difference is really significant.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
