Stefano Bagnara wrote:
Why don't we simply put the mailet in the Jar and import the package in
config.xml ?
A mailet already is a class that handle a mail and could be able to send
the message to remote service.
one has to write a new mailet for each remote service type.
if this mailet is integrated within the James code base you have to link
to the remote service interfaces at build time. this is fine but leads
to third-party-lib pollution.
otherwise one could make an 'external' jar linking the mailet API and
the remote service. this is probably what people already do.
but now the code is not integrated with James. even when you put it
somewhere in a sample repository, you'd have to build and test it on a
regular basis. AFAIK, this is not supported by the current build process.
(the dirty word 'maven' begins to sneak into my thoughts ;-) )
(what I thought about loudly in the first place was how to simplify the
integration. but I realize now that the Mailet API als already very lean
and no generic approach would really simplify things.)
Maybe we should support fully qualified class names in the class
attribute for our mailets in config.xml: it seems cleaner than importing
full packages at the start of the config.xml and would allow the use of
multiple mailets with the same name but in different packages.
this is already supported, isn't it? the MailetLoader adds the prefix ""
automatically, see Loader.getPackages()
I just wrote a Test for that.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
