Aaron Knauf wrote:
I have an idea for addressing this that needs some work, but basically it goes like this:Hi Aaron:
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.
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.
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. 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.
Either way, I would like to use the lastest version of Avalon, to avoid being obsolete before I start.
Let me know if you need a hand navigating through all of the Avalon stuff. You may be interested in checking out the Merlin demos - it has examples of (a) custom lifecycle strategies, and (b) configuration separation - i.e. configuration fragments containing sensitive data are separate from the main configuration. Merlin handles the merging of these configurations during deployment. The main benefits are two fold: firstly it enables a very significant simplification of the configuration overhead for the user, and secondly, allows separation of sensitive information.
Having just successfully implemented a configuration subsystem (with pluggable config sources and dynamic reconfiguration) for our SMS server at work, I know that this will not be a trivial undertaking. I also have a ton of ideas for how to improve over the last attempt. While I am willing to write the code, I do need some indication that I am headed in the right direction. Some helpful advice would also be handy (as would any other contributions). The code would be written for my own interest, but I would like to have the satisfaction of seeing it as part of James when it is done. This means getting some buyin from the James community along the way, so let me know what you think.
Aside from the IOC issue - a pluggable configuration provider is definitely something I would be interested in seeing and using.
Cheers, Steve.
Cheers ADK Danny Angus wrote:Aaron,
You wrote:
This subject has come up a few times. I suggested an approach to handling mailet and matcher config better, as did a few others. I even offered to write it. However, due to the distinct lack of enthusiasm for my (or any other) solution, I lost interest. I could be convinced to revisit this if some of the committers indicated that they were interested.
Without checking I think that the perceived lack of interest was due to a deferal of these issues to v3.
Now that v3 is proceding go ahead with it, I'm indicating that I'm interested and will support your contribution.
Check the wiki for others' opinions on this (and other) v3 topics, and post your ideas, or code, here for discussion & inclusion.
AFAICR we reached some concensus on the following style.. which would allow us to produce a processor DTD (example attached) and standardise every mailet config.
I can't remember what other suggestions/arguments were raised, but you could check the mail archive.
<mailet .............>
<matcher class="...">
<condition>...</condition>
<parameters> <parameter name="..."></parameter>
<parameter name="..."></parameter>
</parameters>
</matcher>
<matcher class="...">
<condition>...</condition>
<parameters>
<parameter name="..."></parameter>
<parameter name="..."></parameter>
</parameters>
</matcher>
<parameters>
<parameter name="..."></parameter>
<parameter name="..."></parameter>
</parameters>
</mailet>
d.
------------------------------------------------------------------------
<!ELEMENT processor (mailet)+>
<!ATTLIST processor
class CDATA #REQUIRED
name CDATA #REQUIRED
<!ELEMENT mailet (matcher,parameters)*>
<!ATTLIST mailet
class CDATA #REQUIRED
<!ELEMENT matcher (condition,parameters)*>
<!ATTLIST matcher
class CDATA #REQUIRED
<!ELEMENT condition (#PCDATA)>
<!ELEMENT parameters (parameter)+>
<!ELEMENT parameter (#PCDATA)>
<!ATTLIST parameter
name CDATA #REQUIRED
------------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
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]>
