Serge Knystautas wrote:
But for the mailet config we should go with the XML we're used to.
I've been going back and forth on this. The name/value pair is nice and simple, but we have some long-standing issues we could wipe away by moving to container driven configuration and away from our name/value XML stuff:
- mailets and matchers could get dependent objects (instead of JNDI or Avalon lookups or any of that)
- richer configuration (nested hierarchy for mailets and more than 1 parameter for matchers)
- mailet could be tied to a matcher's
There is also an option of redefining the XML. The curent XML schema is quite awkward, but it could be redesigned to allow for more matcher parameters for example.
Isn't the current XML configuration also a relic of the Avalon-way?
James could provide configuration POJOs to make it easier to configure it in various ways.my 2c is that we should be delivering a set of service API's and implementations which can be assembled into a mail server in any of several containers, let the people who want to use the container configure it using the container's own configuration mechanisms.
I would like to configure (or even reconfigure!) using Java.
Other configurations could be derived from that.
I'm not too fond of using Groovy scripts, because for most people it will be a new technology (unlike XML), and since it is a programming language there is more room for errors.
IMHO the best way to go is to model configuration using Java POJOs in the James core so it is easier to make up a new configuration technique. The current XML format could be imrpoved, but is tried and tested, so it is worthwile to stick with it for the time being.
Cheers,
Hes.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
