For LifeCycleExtensions, the idea so far is to have them be the last
thing before Initializable.initialize() is called.
Okay for this.
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.
Well, this is like i thought it was. (Sorry i did not verify before you tell :) )
You can group all your extensions into one Creator or one Accessor, as
appropriate.
This is pretty cool for dependently implemented extensions. For example, this might well fit an EJB container implementation as all the needed extensions are functionnaly closely related.
But what for extensions developped independently ? Example i could have a component that is (let us say) Securable and Persistable. Let's say it uses its security supplied knowledge to decide if its state should be retrieved during the Persistable.loadData(). (I do not want to discuss if this design is good or not because i won't do that like this but...) So what happens if Persistable.loadData() is called before Securable.secure() ?
I would assume (as a component developper) that some informations exist about this. But what if don't have any waranty about the application order. There should be a contract explicitely stated about this in the lifecycle extension specification.
Else i am confident that everybody will reprogram its own extensions if it does not have control over the container of the assembly meta-data. Another drift may be that component implementors describe what they do expect about the ordering of extensions. But what next if two components require different ordering ???
Maybe this could be fixed by saying like "no order of extensions application can be assumed, and recommendation is to do critical processing in the (last called) initialize() method". But this sounds to me like a hack.
Leo. speaks about container pluggable implementations of extensions. But those do not remain pluggable if the container needs to have extra-knowledge about what is their ordering. And this is worst even if that is the application assembler that needs to know. Am i wrong ?
I would propose a mechanism to express this ordering from the extension provider.
Together with an extension specification, the provider describes what ordering policy it follows. And in its implementation, he uses a mechanism to ensure this ordering.
This mechanism could be implemented in two ways :
* Preordering at boot time based on declarative informations (meta-data xml files are not required this can be done with an extension MetaClass)
* Delaying if not all required extensions have been applied (this can be done by some programmatic assertions at the beginning of the Creator/Accessor execution but this is dangerous as this can introduce dead-locks)
Extensions will be defined as layers, each one augmenting the contracts that tie the component and the container.
MetaClass example:
class PersistableExtension implements ExtensionMetaClass
{
public Class[] loadsAfter()
{
return new Class[] { SecurableExtension.class };
}
}And then classical dependency graph resolution... But i am not yet convinved by this solution. Maybe another solution would be to cut the four phases in more phases. But this would mean actually creating the extensions... Damned, can't find better than ordering declarations.
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.
Sorry, i did look to the archive but did not succeed (dislikes this search) to find relevant informations. I hope to not come over things that were previously stated and that there is no offense.
If there are any questions, please ask.
Thanks! I followed your advice. :)
A+. Didier.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
