[EMAIL PROTECTED] wrote:
Hi all,
Your discussion remind me something that seems very important to me about lifecycle extension.
As i see the two lifecycle extension interfaces, there is no mean to impose a specific order while applying the extensions. This means that a lifecycle extension provider has no mean to tell the lifecycle extension manager when it must be applied relatively (in time) to other extensions during a specified stage.
(Example : Serviceable.service() before Initializable.initialize() even if they are at the same stage.)
I think the combination of lifecycle extensions is a use case we must think about. For example in an attempt to implement core avalon lifecycle with the lifecycle extension mechanism you will need this kind of ordering specification.
I would think the resolution of the order as a kind of incremental ordering while extensions are discovered (at the container *boot* time). This may be compared to the serialization of the order of some modules' compilation based on their respective dependencies.
To conclude, i personally think the lifecycle extension mechanism needs to be
more thought, even if i find it usefull and the portability it can provide for
containers very attractive.
Hi Didier:
The concerns your raising related to phase ordering and aspects of how a container manages multiple handlers. These issue are not exposed under the current package - because they are container specific today. I don't kown what the Fortress approach is off-hand, but the Merlin appoach when dealing with multiple phases in a single component is to apply stages in the same order as specificed in the component meta-info.
For example, the Assembly package includes some demonstrations of a component type that declares multiple handler depedencies:
<type>
<stages>
<stage type="org.apache.avalon.playground.Exploitable" />
<stage type="org.apache.avalon.playground.Demonstratable"/>
</stages>
</type>In the above example, the Exploitable stage handler will be applied first, followed by the Demonstratable handler.
Cheers, Steve.
Cheers, A+. Didier.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
