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
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
