james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [mailets] Low hanging fruit
Date Mon, 05 May 2008 09:51:27 GMT
Robert Burrell Donkin ha scritto:
> On Sat, Feb 2, 2008 at 5:51 PM, Stefano Bagnara <apache@bago.org> 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


>>  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 :-),


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message