james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hes Siemelink <hes-l...@izecom.com>
Subject Re: JavaMail API and SMTP transport for Geronimo
Date Wed, 26 Jan 2005 14:43:51 GMT
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


Mime
View raw message