Very well said.
We had already started defining these keys, but somehow it just stopped IIRC. It's time now that we soon restart that discussion and come to a definition.
And eventually define the metadata stuff, that really can be a good contract, and decide on the container testsuite for framework contract conformance check.
Peter M. Goldstein wrote:
All,I do not believe it is necessary to make the containers we havecompatibleat anything other than Avalon-Framework-Interface level. If we strive for compatibility on component-lacing (XML, properties, whatever) we will find some other team does not honor the chosen lacing team an delivers a container with a twist. This could be BEA, Pramati, JBoss, Catalina, OpenEJB, Lutris. It could be some University in Bangalore or Manila. We cannot containthecontainer landscape; we'd be foolish to try. There are thing people are imagining now that will impress the socks off us when released. Better 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. 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. I'd argue that a standard, minimal set of keys/object should be part of 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. There may be other ways to address this problem, and that's what I'd like to see discussed. This issue is obvious when one thinks about the contract, but is invisible when just considering the interface. This is only one Avalon Framework issue among a number that need to be discussed, clarified, and resolved. Clarification of these issues will make it easier, not harder, to develop new containers. 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.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
