> > - not container modification, but container toolkit to ease creation of > > custom container > > - keep lifecycle processing for avalon framework lifecycle stages > > separate, and as simple as it is now > > Ok. When I first looked into doing this I found out that the > container level is not deep enough to support custom instantiation > level lifecycle stages *and* access level lifecycle stages (perhaps > my use of the word container isn't right - I mean the CM inside of > Fortress's AbstractContainer, and ECM).
common problem. ECM mixes a few concerns. Now I understand where you're coming from. > When I get a component from a CM or the handler inside the CM, I don't > know if that component was created just then, or if it was simply > pooled and retrieved. with ECM, you don't. If you have a custom handler inside the CM, you could. > This makes a difference if you want to add a new lifecycle stage > to the instantiation phase of a component where it should be done > only once during startup, perhaps after the standard avalon stages > - or if you want one done at the access level, in which case it > needs to be done on every lookup. > > If it was possible to find this out it would be easy enough to > have a custom container (or CM inside of the container) to run the > appropriate methods. > > Or, are you saying we should make the startup phase immutable and > not extendable, but allow for access level extensions ? nope. I'd say you should have a singleton-like handler/factory/whatever you call it, that you put into your CM, which acts as a full-fledged container, to which you can add all the extensions you like. That way, you *can* figure out in what stage your component is. But I believe fortress also has provisions for container hierarchies; don't know how that works though. - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
