I disagree that this is the right list. Not to be a stickler but I
think that
the discussion here should be container agnostic. I don't really care about
JAMES or how JAMES chooses to implement mailets. I care about a portable
API that provides a "marketplace" of extensions that work in the
mailserver of
my choice. How this should be done in JAMES specifically is a great
conversation
for the regular JAMES development mailing list.
Joachim Draeger wrote:
Hi!
Although I'm referring to James server I think it is the right list.
James server is somehow our reference costumer. :-)
The details of an implementation should of course be discussed on
server-dev.
I just noticed that we already have designated factories for Mailets and
Matchers!
JamesMatcherLoader and JamesMatcherLoader
I guess it is not too difficult to lookup a xml document for each Mailet
and inject dependencies via setters.
Maybe we could even use a framework which could introduce even more
flexibility.
This way we wouldn't have to declare the deps redundant in config.xml
when a Mailet is used more than once. (config.xml is also big enough :-)
Default dependencies from xml document could be overridden by directives
in config.xml to have full control.
Joachim
