Aaron Knauf wrote:
Stephen McConnell wrote:Aaron Knauf wrote:I have an idea for addressing this that needs some work, but basically it goes like this:
Implement the configuration as an Avalon block. (I think this is the right term, but I am not too familiar with Avalon, so bear with me.) This block would basically manage the loading and parsing of configurations from any datasource that you want to write a plugin for. Components will obtain their configuration from this block.
Hi Aaron:
I read you email with interest. Concerning the above paragraph - I think it would be preferable for the James system to be acting a mailet container and following IOC principals. This means that the container figures out what the mailet needs, pulls it together, and supplies it to the mailet. I.e. the mailet does not need to be concerned with "obtaining" the things it needs - instead - it gets supplied everything it needs.
Oh, I agree completely. I guess I wasn't clear on this point. I expect that the MailetLoader would be the thing parsing the config the Mailet configs and handing them to the mailets. Also, the plugin parsers would be called by the configuration manager and handed just the part of the config that they are responsible for.
As a matter of fact, I had to learn the hard way the benefits of IOC while implementing the config subsystem for my recent project. I was unable to use IOC because I was stuck with an existing server implementation that had static getConfig().getThis() and getConfig().getThat() calls all over the place. Making the thing re-initialise certain components when the config changed was a nightmare.
A question: should we hook heavily in to Avalon with this thing, or should we make it something more portable, that can be used outside of Avalon?
I think there are separate concerns relating to the Mailet API versus the container implementation approach. From everything I've seen here the principal is to keep the mailet API as free of dependencies as possible.
This question was never intended to suggest that Avalon APIs might make an appearance in the Mailet API. There needs to be a clear delineation between the portable container API and the non-portable container implementation.
What I really meant was do we make this whole configuration manager thing another james component, so that the James container implementation could hook into it without going through Avalon, or do we hook in to all of the Avalon APIs that I am sure I will find enticing along the way? This is all behind that Mailet abstraction layer.
The other side of that coin is that you end up falling back to the lowest common denominator. The approach I'm working on is to enable components (e.g. mailets) to declare a strategy to the container (e.g. James) ... i.e. the mailet declares that it is using interface Xxxxx for configuration and the container simply takes care of this by selecting and applying an appropriate handler. This means I can write a mailet that uses a Servelt configuration model, or the Avalon Configurable interface, or a Mailet special, or whatever. The mailet API remains independent - but I (as a mailet author) can leverage the technologies I want.
Hmmmm. I am not sure that I fully follow what you are saying here, but I believe I have the gist of it. When I initially looked into the Avalon configuration subsystem, I was disappointed to find that we are forced into a quite sizeable Configuration interface for configurating our Configurables. Further, this interface exposed XML-specific namespace stuff to the Configurable, when (IMHO) that ought to be an implementation detail used by the parser when reading the config.xml and creating the Configuration impl.
I'm not familiar with the XML-specific namespace stuff - but I do know the there is broad support for the Configuration interface. It is simply really really nice to work with. If the Mailet API comes up with something new - I really hope it looks and smells like the Avalon Configuration interface.
If you are suggesting that Configurables might be able to get fed an arbitrary configuration object in future, (possibly implementing a smaller interface to allow the framework to handle it,) then that is great news.I'm suggesting that a component (using information declared in meta data) declares what its configuration contract is. The container simply resolves that depedency. Keep in mind that this direction is much more a Merlin specific thing - but on the other hand the Avalon peeps are actively discussing such radical stuff over on avalon-dev.
Perhaps you might consider my proposed configuration manager as an implementation for driving this?
Consider it as considered. If you make this a component (Phoenix Block) it will automatically work in Merlin.
If so, I would suggest that -
a) The configuration manager have a clear interface whose implementation could be substituted for another
b) Perhaps my configuration manager proposal is something that belongs in Avalon, rather than being specific to James?
Maybe - its just happens to be something I was thinking about in relation to Merlin acoule of weeks ago.
Aside from the IOC issue - a pluggable configuration provider is definitely something I would be interested in seeing and using.
Then keep an eye on this list. I will post some UML before I begin coding. I would appreciate any feedback you might be able to give.
I will (just make sure the message title is descriptive or I could miss it). Cheers, Steve.
Cheers
ADK
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
