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.
Dropping a hefty RT right before I go on vacation... How dare you ;P Seriously, you are talking about things we want to tackle.
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.
I hear you. We agree. If you have some more concrete ideas (something we can start brainstorming and moving toward) for this, please let them be known.
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.
This is something we have been thinking about designing for in the next generation container Spearhead. It is easier to play around in a new work that noone is dependent on yet to get it right, then backport it.
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
Agreed, Agreed, and Agreed.
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
There are only a couple of standard context values (between Fortress and Phoenix). Merlin uses the more verbose URN notation.
We have started toward standardizing a base set of context values, but that got stalled somewhere.
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)
Merlin provides support to validate those context values, but having them set in a cross-platform manner is tricky.
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.
Something we started on and probably need to resume.
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.
It is another thing we need to explore. A good set of standards will help.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
