Either we use groovy, use another container's XML construct to configure James, or invent our own XML structure. What do you suggest?
I would suggest that we use the relevant constructs for the container(s) we support. So we could prepare a Spring James distribution, a Phoenix James etc etc.
Ok, but not a groovy-as-container?
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
So, I kind of like removing the configuration part of our API (and lifecycle for that matter), and just let the containers provide it with IoC.
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.
Yeah, I think James becomes a bunch of POJO's is the main issue, and then we have to figure out a recommended container we'll be using for distribution. I cannot see us actually providing multiple container support out-of-the-box.
-- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
