Farr, Aaron wrote:
Greetings.
Hi!
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.
At the pub the other night we were talking about JMX enablement using the appliance implementation. Later I was thinking that an open mechanisms is needed to plug this sort of functionality into an appliance - i.e. eliminate the need for new appliance types.
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
+1
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.
I agree.
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
All of the above are *required* services if we want portability.
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)
You may want to take a look at the DefaultContextualizationService. This was originally created to enable the declaration of replacable strategies - however, overall context managent is not a trivial thing - as it turns out it is more interesting to look at how the kernel and containment environments can be enhanced with context providers installed under container scope.
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.
Given a complete meta-info description of the context criteria - this problem becomes manageble.
Cheers, Steve.
(who has a lot of emails to catchup on)
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]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
