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.
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.
What do you think?
-dain
- javamail problems Dain Sundstrom
-
