Greetings. After a couple weeks of wrestling with all three Avalon containers I've found a couple of issues that I can't seem to get around easily.
1. Container Extensions Sure I can extends Fortress's DefaultContainer or hack away at Merlin and Phoenix internals, but if I want to add something like JNDI, JMX, or whatever, I'd rather not have to do that. In particular, I'd like a way to write a single extension/component which works in all three containers. Currently we have lifecycle extensions, but these are not yet supported by Phoenix. Lifecycle extensions are wonderful, but only go so far. You do not have, for example, access to assembly level meta-data. No access to configuration, dependencies, or whatnot. Only access to the object itself and the context. What I'm looking for is a way to extend the basic services of a container without having to extend the base container class. If this were possible, then adding JNDI, JMX, SOAP, and whatnot would be much easier. Moreover, it could be possible to do it once and then have it work for all three containers. As it stands, Phoenix has JMX support. To get JMX support in Fortress, you'd have to pull it out of Phoenix and integrate it directly into Fortress. I want a way to dynamically add new base services like a JNDI, SOAP, JMX, etc. These services are more than just lifecycle extensions -- they're container extensions. They need access to assembly level data. As I see it, to accomplish this we would need to: - Standardize assembly process and meta-data - Define Container Extension API (possibly based on Lifecycle Extensions) - Provide support in the main Avalon containers Not simple, but not impossible either. This is probably something more along the lines of Spearhead, but I suppose support for it could end up in Merlin without too much trouble. 2. Managing a Context I may be mistaken, but from what I can see, between the three containers there is: - no standard set of context values - no standard context naming convention - no standard way to add things to the context without extending the base container We've all seen the problem of relying on something like BlockContext, but BlockContext exists because it's, well, very useful. There's a need for it. But no other container supports it or has a viable alternative. Perhaps we could: - Provide a way to include parameters/properties in the context - Provide a way to manipulate context values before general contextualization begins (this could be one of those container extensions I mentioned) The context is great idea, but I find myself avoiding it because it seems like using Context ties me to a particular container more than I would like. Perhaps I just don't know how to use it properly, in which case, more documentation or examples, would be nice. I was also going to add something about handling resources and deployable files (think sars, jars, ears, wars, eobs, ...), but the Source Resolver package handles that fairly well. I suppose my uneasiness comes from the lack of conformity in resource structure even within the Avalon containers. Since a common server feature is loading and deploying resources like wars and sars, it seems like there would be a more complete framework (and more conformity) within Avalon for that. I'll have to ponder this one a bit more. Thanks! J. Aaron Farr � SONY ELECTRONICS � DDP-CIM � (724) 696-7653 � --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
