geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <>
Subject Re: javamail problems
Date Thu, 26 Oct 2006 09:26:58 GMT
Dain Sundstrom wrote:
> I have been hacking on JavaMail lately and have run into difficulty 
> overriding the JavaMail SMTP implementation.  In the great wisdom of 
> Sun Microsystems, the only way to add a new protocol provider to the 
> JavaMail implementation is have the implementation discover it via a 
> META-INF/javamail.providers or META-INF/javamail.default.providers in 
> the class loader.  Once your provider has been discovered, you can get 
> it instantiated by either making it the default provider defined by 
> the first META-INF/javamail.default.providers found in the class 
> loader, programatically selecting the provider with 
> session.getProviders() and session.setProvider(provider), or by 
> passing in the mail.smtp.class=your.SMTPClass to the 
> Session.getInstance(properties) method.  The third option seems really 
> cool but the class you specify must be mentioned in a META-INF 
> providers file otherwise the property is silently ignored.
If Sun had just made the constructor for the javax.mail.Provider class 
public, you'd be able add additional providers programatically too...sigh.

This appears to only be an issue if you're using the mail session GBeans 
to configure the mail sessions.  If the code is directly instantiating 
the mail session, then it picks up the context classloader for the 
application and can load additional providers.  The default is still a 
bit dependent on search order within the classloaders, however. 
> I'd like to propose a couple of changes for the next release after 1.2 
> which should make JavaMail (and some other lame specs) easier to use.
> 1) Add the ability to declare additional dependencies to the 
> configuration via the config.xml file.  We probably want a way to 
> exclude a dependency and maybe add to the front of the dependency list 
> (unless remove re-add works).  This is required to add a new provider 
> to the existing javamail configuration.  Without this, you must update 
> every application to point to a new configuration that contains your 
> provider jar.
> 2) Add a "className" attribute to 
> org.apache.geronimo.mail.ProtocolGBean and all subclasses.  If this is 
> set then, in addOverrides, we add a 
> mail.${protocol}.class=${className} to the properties object.  There 
> is no reason to add this until item 1 is complete, since you can't 
> extend the class path, and would be very confusing to users.
The combination of the 2 sounds reasonable.  2) could be useful without 
1), if you're hand constructing your own mail configuration, so it might 
be worth adding now.

> What do you think?
> -dain

View raw message