Robert Burrell Donkin ha scritto:
On Sat, Feb 2, 2008 at 5:51 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Then we have some mailets with dependencies on utility classes that could
be separated from James:
mailets/ReplaceContent
- import org.apache.james.util.mailet.StringUtils;
mailets/ReplaceContent
- depends on org.apache.james.util.mailet.MailetUtil
mailets/UnwrapText
mailets/WrapText
- depend on org.apache.james.util.mailet.FlowedMessageUtils
<snip>
we should move org.james.util.mailet.* into mailet-base
+1
mailets/ClamAVScan
- import org.apache.james.util.io.IOUtil;
i'd be happen to clone any methods used
or maybe moving them to mailet-base: JAMES-Server will anyway depends on
mailet-base, if I understood it correctly, right?
mailets/SpamAssassin
- import org.apache.james.util.SpamAssassinInvoker;
hmmm... where else is this used?
I guess SMTP fast fail (didn't check the code).
The fact is that with SMTP fastfail/in-protocol handlers we have to use
most of the features we have in mailets but we can't use the mailets
api, so the solution was to create small utility classes (e.g:
SpamAssassinInvoker) or JAMES Services (e.g: VirtualUserTable service in
trunk) to be used both from mailets and smtp handlers.
An alternative solution would have been to identify the additional
interfaces needed to use mailets in-protocol, but we already tried this
many times, I'm not ready to reiterate this issue.
mailets/LogMessage
- import org.apache.james.core.MailImpl but I think this might be a mistake
and we could replace MailImpl with Mail.
done
Thank you :-),
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]