Peter,
We do have a definition :- http://jakarta.apache.org/avalon/framework/reference-the-lifecycle.htmlBetter to concentrate on our core product -> Avalon Framework's
interfaces.
Embrace the multi-container world!!
The "interfaces define everything" mentality is something that some consumers of Avalon (myself included) find troubling. Avalon Framework needs to (and in quite a few cases does) include conceptual documentation that goes beyond the interfaces.Interfaces do not define anything save interfaces. It's the contracts behind those interfaces that matter. Without the contracts, the interfaces are meaningless. Consider an Avalon Framework with all the lifecycle interfaces, but no lifecycle definition. It would be useless - containers would be able to implement lifecycle methods in any order they desired. You couldn't write a container-independent application using such an Avalon Framework. It is the lifecycle contract that is fundamental.
I do accept that docs could be improved.
It may be that there are some similarities between Phoenix and Merlin. But when coarse grained containers #3 thru #8 arrive, we will look pretty daft having such a constraining single design for component lacing. People are going to surprise us with containers. We'll look short sighted if we fix abstractions for miriads of containers now.In addition, by focusing on the contract it is most easy to see inadequacies in the framework. For example, the Context interface is sufficient for the needs of consumer apps. While it might be nice to have some syntactic sugar as in the Phoenix Block Context, it isn't strictly necessary. However the contract is clearly incomplete - without some sort of definition of container-common context objects and their keys no one can use the Context in a container independent way.
For example, James, which is a pretty simple app from an Avalon
perspective, would not be able to run in any random Avalon container
that implemented the current Avalon Framework. That's because James
needs the application home directory to resolve some of the file URLs.
But since the key ("app.home") and the semantic meaning associated with
the value returned (the application home as a File object) are not
defined as part of the contract, a random container doesn't need to
provide this. As I understand it Phoenix and Merlin both provide this,
but it is not laid out explicitly in the Framework.
abstract class FooDaemon implements Startable, Runnable, Contextualizable {
Thread thread;
File rootDir;
// from A-F Startable
void start() {
thread = new Thread(this);
thread.start();
}
// from A-F Startable
void stop() {
thread.stop();
}
}
class PhoenixFooDaemon extends FooDaemon {
// from A-F Contextualizable
void contextualize(Context context) {
rootDir = ((BlockContext) context).getRootDir();
}
}
class EOBFooDaemon extends FooDaemon {
// from A-F Contextualizable
void contextualize(Context context) {
rootDir = ((BeanContext) context).getRootDir();
}
}
With the above design, you interoperability with Phoenix and EOB (a .Net Remoting inspired app server I work on). Replace the word 'EOB' with JAMES (one day?), or Merlin, or Catalina's internals (one day?). Containers are all different. They use differnet cop-lacing, config and context.
The point is that Context is deliberately vague. Either we define a massive hierarchy of Context interfaces in the A-F package (and curse ourselves at our liesure over the years), or we leave the context to the container in question. Phoenix and Merlin are just two containers. They are not going to be the last 'coarse grained application server' containers.
Apart from anything else, it was voted on before that Merlin include the tiny Phoenix-Client jar in it's client API classloader and honors BlockContext as is (if it wanted to be compatible with Phoenix).
I'd argue that a standard, minimal set of keys/object should be part ofYou can go for that if you like. Code something that is adaptive and used the primitive get() mechanism.
the Context contract. Otherwise the Context interface is fairly useless
as part of framework since every container would provide a purely custom
set of keys/values. Thus any code written that implemented
Contextualizable would be implicitly container dependent.
Maybe we should have a single additional context method called getContainer(). It returns "Phoenix 4.0.2" where that were true. Or maybe a method called isCompatibleWith("Phoenix 4.x")
The point is that deciding
The only way to get a truly multi-container world is precisely to be crystal clear about what the Avalon Framework does and does not guarantee. I very much support multiple containers - and the ability of Avalon Framework consumers to write functional, container-independent applications.
Sentence #1, I believe we are clear. We may not have commuicated it well :-) Sentence #2, agree. - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
