geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: JavaMail service providers
Date Sun, 21 Aug 2005 16:28:59 GMT
Dave Colasurdo wrote:
> Is the Javamail provider implementation an optional portion of the J2EE 
>  specification? J2EE 1.4 states
> 
> "The JavaMail API specification does not require any specific protocol 
> providers, but the JavaMail reference implementation includes an
> IMAP message store provider and an SMTP message transport provider."
> 

The only provider that J2EE requires is the SMTP transport and we have 
one of those (somewhere, when Geir finds it :-) ). The others contained 
in the JavaMail RI are for accessing stores.

> Nonetheless, is it still useful to have default providers available in 
> geronimo?  Seems like both applications and the new javamail portlet 
> could take advantage of them..
> 

The portlet is for configuring an SMTP transport so that should work (at 
least with minimal effort if it doesn't now). It probably needs beefing 
up to deal with odd mailservers and to add support for more complex 
features (e.g. TLS) but it can send basic emails.

The SMTP transport usecase is fairly obvious - it allows an application 
to send emails. Inbound SMTP would also be useful but unfortunately 
JavaMail does not support that, about the best you can do would be an 
inbound J2CA adaptor that delivered Messages to an MDB or other destination.

The other providers (e.g. IMAP or POP) would allow components to access 
stores but that is a polling event that would need to be triggered by 
something. This means there is a bit more application code needed to 
handle accessing the store (like detecting what is a new mail) so adding 
in the overhead of having to grab a provider from elsewhere is probably 
not too problematic.

Finally, we did this JavaMail stuff because there was no option 
available. Now the RI is available under CDDL we might want to consider 
restributing that. If we decide not to then we should also consider 
whether these providers would be better off as part of Apache James.

--
Jeremy

Mime
View raw message