On Oct 27, 2009, at 7:52 AM, [email protected] wrote:
To clarify our situation a bit, the activation bundle finds its own
META-INF/mailcap.defaults but is unable to see META-INF/mailcap in
the javamail bundle because of the separation of classloaders.
Given this needed relationship, I believe we've run out of options
except to put activation and javamail in the same bundle.
I ran into the exact same problem with mail and activation. The only
way I was able to work around it was to swap classloaders inside the
method that makes the javamail calls. Here are the relevant parts of
the code:
/*
* this is the interface exported by the bundle
*/
public interface MyMailSender {
public void sendMail(String text);
}
/**
* @scr.component metatype="true" enabled="true" immediate="true"
* @scr.service interface="MyMailSender"
*/
public class MyMailSenderImpl {
private ClassLoader localClassLoader;
private Session mailSession;
protected void activate(ComponentContext context) {
Properties properties = new Properties();
// set javamail properties
session = Session.getInstance(properties);
localClassLoader = session.getClass().getClassLoader()
}
public void sendMail(String text) {
ClassLoader previousClassLoader = Thread.currentThread
().getContextClassLoader();
try {
/*
* Switch to the classloader that loaded up the JavaMail
Session
* object. This classloader will have access to the
resources
* required to dynamically load the provider and transport.
*/
Thread.currentThread().setContextClassLoader
(localClassLoader);
// now you can send your mail message
MimeMessage msg = new MimeMessage(session);
msg.setText(text);
Transport transport = session.getTransport("smtp");
transport.connect();
transport.sendMessage(msg, new InternetAddress[] { new
InternetAddress("[email protected]") });
transport.close();
}
// catch all the various javamail exceptions here
finally {
Thread.currentThread().setContextClassLoader
(prevClassloader);
}
}
}
Hope this helps!
p.
