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.)
For LifeCycleExtensions, the idea so far is to have them be the last thing before Initializable.initialize() is called.
In Fortress, you handle the order explicitly by adding your Creators and Accessors in the order you want them to be run. Merlin has its own mechanism for ensuring order--and it is a little more automated.
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.
You can group all your extensions into one Creator or one Accessor, as appropriate.
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.
I think we did address all those issues before, and there was some great synergy and good understanding between the developers who developed it: Marcus Crafter, Stephen McConnell, and myself.
If there are any questions, please ask.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
