james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrique Rodriguez <erodrig...@apache.org>
Subject Re: JavaMail API and SMTP transport for Geronimo
Date Wed, 26 Jan 2005 14:47:44 GMT
I have no experience with it but thought I'd throw it out there:

"Tiger JMail is a direct replacement for Sun's javamail, but with an 
LGPL license and fewer bugs."

Tiger JMail
http://tjmail.sourceforge.net/

Almost a year since the last release of a 1.0 rc3.

Hope that helps,

-enrique


Hes Siemelink wrote:
> There is also GNU JavaMail. See 
> http://www.gnu.org/software/classpathx/javamail/javamail.html
> 
> That is supposed to be 'free'...
> 
> Can you use that or doesn't the GPL mix with the Apache license?
> 
> Cheers,
> 
>    Hes.
> 
> Danny Angus wrote:
> 
>> Jeremy,
>>
>>  
>>
>>> One problem I have is that the spec and API doc are not always clear
>>> about what should be done - e.g. from the JavaDoc for
>>> InternetAddress.validate():
>>>
>>> "The current implementation checks many, but not all, syntax rules."
>>>   
>>
>>
>>  
>>
>>> It would be nice to know what was supposed to be checked and what 
>>> wasn't.
>>>   
>>
>>
>> This would initially depend upon what specific version of the RFC is
>> supported,  but also they may not support all of the rules, for
>> example there are a load of paragraphs in some RFC's which specifiy
>> special rules for military things (time format is one). Sun may have
>> taken the view that things like this are not necessary.
>>
>> In this case you need to decide what it is you want, 100% RFC
>> compliance, a do-or-die TCK pass, or a pragmatic set of useful
>> validations.
>>
>> James already have some address validation which is stronger than
>> Sun's, the problem would come if the TCK has specific test cases which
>> are ambiguous, for instance they may be expected to pass Suns
>> pragmatic validation yet fail more rigorous validation and v.v.
>>
>> For an example the RFC's say that the domain part of an address is not
>> case sensitive but the username part is. Almost no one enforces this
>> (in James its optional). The question is does the TCK enforce it?
>>
>>  
>>
>>> I am hoping the JavaMail TCK can clear some of these things up, but
>>> empirical knowledge (which I don't have, I'm no mail expert) would help.
>>>   
>>
>>
>> Agreed, I'm sure that we (James greybeards ;-) could look at the TCK
>> and arrive at a some understanding of what Sun expect to be mandatory
>> and what is optional.
>>
>>  
>>
>>> Any chance you could point me in the general direction?
>>>   
>>
>>
>> Well James uses (for the time being) Avalon to assemble itself at
>> runtime, most of the services are declared in config files as
>> implementations for interfaces and can therfore be swapped for highly
>> specialised alternatives with little problem.
>>
>> For example the (incoming) SMTP handler might be replaced with an
>> alternative which rather than listening simply introduces predefined
>> test cases into the processing pipeline.
>>
>> The heart of James are the Mailet processors which are used to route
>> and transform the messages. Mailets are processing components which
>> are specified by the Mailet API, and could quite easily be used to
>> apply the incoming test messages to various JavaMail functions, such
>> as constructing and deconstructing multipart messages, parsing
>> content, validating addresses, invoking transports etc.
>>
>>
>>  
>>
>>> For Geronimo we can cut back on this a little - the J2EE specification
>>> only requires that we provide a transport that supports addresses of
>>> type InternetAddress and messages of type MimeMessage; we do not need to
>>> support any store protocols.
>>>   
>>
>>
>> If you only have to provide implementations, in effect implement the
>> same functions as Suns reference implementation and not duplicate the
>> API then I'm think this is achievable. If you have to recreate the API
>> as well I think you have a significant obstacle, in fact it may well
>> be easier to sort out the legal issue.
>> An SMTP transport is one thing we'd love to have, Suns RI doesn't fire
>> any events and James could make good use of events raised by
>> Transport.
>>
>>  
>>
>>> However, for this to be of general use I agree that we should provide
>>> good implementations of as many of these as we can.
>>>   
>>
>>
>> I fear that implementing any of the javax.mail stuff will suck us down
>> a pit we can only get out of by recreating the whole thing. And sadly
>> as Sun, in their wisdom, have made their API out of classes not
>> interfaces this is not trivial.
>>
>> To implement the bits the API expects us to implement is more reasonable.
>>
>>  
>>
>>> Knowledge and expertise alone will help a lot.
>>>   
>>
>>
>> We'll I can't offer a lot of effort but what knowledge I have is yours.
>>
>> One question I have is this, do you envisage this as being geronimo
>> code, or would you consider collaborating on an effort in James?
>>
>> d.
>>
>> P.S. Should we take this to the geronimo lists or keep it here?
>>
>>  
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org

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


Mime
View raw message