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
