Hi, First lets use some common terminology. Phoenix uses terminology
* Stage - single interface like LogEnabled, Initializable * Phase - a set of Stages that are run in succession. ie "Startup" runs from LogEnabled --> Startable At various times during phoenixs evolution we have allowed both pluggable stages and pluggable phases. Pluggable stages lead to massive complexity, unmaintainable core and a big ball of mud. Avalon defines the "Startup" and "Shutdown" phases very explicitly so it is probably not a good idea to mess with them. We ended up coming to conclusion that pluggable phases were the only real option. Possible pluggable phases being Management (as per phoenix), Instrumentation (as per ECM/Cocoon), Persistence, Session management, Activation etc The problems is when you come to implement it you come up against some hairy problems. 1. For phases that require resources supplied by the container (almost all of them?), howdo you aquire said resources?. How do you know which MBeanServer to use, which PersistentStore etc. 2. How do you "call" phases from outside the container. For instance, an activation/passivation phase extension will need to be able to be called from outside the container, as may other phases. Theres a few more hairy bits but the above are worst. As soon as you start defining the above you are virtually defining the container. On Sat, 3 Aug 2002 03:30, Berin Loritsch wrote: > When we think if an extensible lifecycle mechanism, there are some > requirements that we need to satisfy. Before we can determine what > those requirements are, we also have to consider who would use them. > That said, I will list some basic requirements for this to be > included in Avalon, and then some more specific ones to help us come > to a version of the support that is useable. > > Generic Requirements: > > * Must have the same interface regardless of the container > * Must be included in containerkit so that new containers can easily > support it. > * Containers must be able to say "I support/don't support extensions". > Because the extensions would be a *standard* any container that claims > extension support will not require the end user to implement a new > version of the support. > > Those are the basic requirements for this type of support to really be > supported in Avalon. Use the Java mantra: "write once, use anywhere". > We do not want two or three incompatible versions of it laying around. > If we cannot fulfill these requirements we cannot have lifecycle > extensions--it would be more harmful than helpful. > > Now, let's get to know the extensions user. Someone who will use > Lifecycle extensions has a specific need that is not already supported > by the Avalon lifecycle. It is hard to imagine such a beast, but they > exist. Examples include web frameworks, persistence mechanisms, > experimentation with new services, etc. Because the extension is > aimed at a particular problem area, the developer of the system > knows which set of extra interfaces they want to support. > > What we do need to guard against is an unwitting developer who wants > to reuse a component that was designed for a certain set of extensions. > The component will fail to operate as expected if the extension is > not handled properly. > > At this point it is safe to add a couple more requirements: > > * New lifecycle interfaces must be marked as extensions so that we > can determine if we can use this component. > * The container *must* be able to verify if the extensions that a > component implements can be handled. If not, we need to throw > an exception. > * The ExtensionHandler must list the interfaces it supports to enable > the container to verify the system. > > Now, the question that is unclear at this point is whether we need > more than one extension handler in any system. As Peter D. has > pointed out, trying to maintain a separate handler for each interface > is a maintenance nightmare. I am inclined to agree with him. The > only time I can possibly think of where we would need more than one > extension handler is if we had more than one class of components. > Most systems have one class (Avalon pure, one set of extensions, > or just a different component lifcycle). Based on these observations > I would probably add these requirements (but they are negotiable): > > * The ExtensionHandler should be able to handle several extensions > at one time. > * A component should not demand the existence of a particular > ExtensionHandler, only that the interface is handled. > - If a component expects a certain order for the lifecycle, > we need to verify the order of lifecycle extensions. It > might be that we need to demand a certain handler. > - If two handlers satisfy a component's demands they should > be considered interchangeable. > > That last requirement (with the two contridicting viewpoints) > are the area where I believe we need to put the most work. > > > "They that give up essential liberty to obtain a little temporary safety > deserve neither liberty nor safety." > - Benjamin Franklin -- Cheers, Peter Donald -------------------------------- These aren't the droids you're looking for. Move along. -------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
