The format you suggest certainly allows for multiple matchers and better matcher configuration. However, it still leaves us with unstructured name/value pairs. There have been a number of requests for structured mailet configuration.
Having just re-read the last configuration thread, I am not sure that a consensus was reached. Here is the address of the last mailing list post from our previous discussion on this subject:
http://www.mail-archive.com/[email protected]/msg05485.html
Before I proceed with writing any code, I would like to agree on
A - some requirements
B - an implementation approach
A - Requirements
I would expect that any effort in the configuration area would need to achieve the following four things:
1) Structured Mailet config.
2) A storage agnostic Mailet config API. The Mailet API should have no knowledge of the underlying implementation mechanics. It should work just the same for configuration pulled from a database, an XML file, or a JNDI tree.
3) Dynamic reconfiguration of processors.
4) I believe rule 1 of API design is to make things as simple and easy as possible for the client programmer.
I also consider the following requirements to be secondary, but desirable:
* Validation of XML config files against an XSD.
* Dynamic reconfiguration of other components.
B - Implementation
Initially, I would expect to implement these requirements using XML configuration files. The API should, however, be designed to allow other config sources to be plugged in. Further, other config sources should be able to be plugged a granular level. Initially, I suggest that the granularity be at the level of (a) overall server config, and (b) individual mailets. So the James server would be configured from a particular config source, but individual mailets could be configured to pull their config from differents sources to the James server.
This last item opens the question of what should be the expected behaviour if a particular mailet's config source is not available when the server starts?
Both you and Kenny expressed reservations regarding use of namespaces. I would agree with these reservations if the namespace complexity were to be exposed in the Mailet API. (That would not only be complex - it would break abstraction by exposing XML-specific features where the Mailet config should be source-agnostic.) The advantage I see in using namespaces internally to james is that it allows us to validate the XML structure with an XSD, rather than laboriously doing it in code. Further - if a particular mailet author does not want to use a XSD, they would not be forced to. They ought to be able to put arbitrary XML in there and just have that part unvalidated.
Based on the above implementation approach, I think that there needs to be two APIs defined for configuration:
1) The API used by a Mailet to access its configuration.
2) The API used by plugin config sources to provide configuration to components that want need it.
These APIs need to be defined.
The trouble is, the Avalon configuration API is rather XML-centric. One would think that this would make things easier, but it doesn't allow the flexibility to plug in (e.g.) a RDBMS-based config. It also breaks abstraction by exposing namespaces to the actual component, (in the Configuration interface,) when the parser should be the only thing to care about this kind of detail. I would prefer not to have to implement the Configuration interface in the new config objects.
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.
This could be implemented by plugging a custom configuration parser into the Avalon config subsystem. The custom parser would read config.xml far enough to find that component X's config should be obtained from the Configuration Block and would then switch to using that.
I would want to implement this using a staged approach. First, individual Mailets could use the Configuration Block by modifying the MailetLoader to be aware of the block and look for an attribute in the mailet tag. (No need for the custom avalon config parser, just yet.) This would let us try out the Configuration Block approach and see if it is good.
Assuming that the Configuration Block idea turns out to be useful, other James components could then start using it if it looks like a good idea. We could then make it a more generic Avalon component thing.
This approach has the advantage that it can be completely backward compatible. If a mailet tag does not have the necessary flag set, then the current behaviour applies.
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?
Either way, I would like to use the lastest version of Avalon, to avoid being obsolete before I start.
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.
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]>
