Why can't Tomcat find SMTPTransport (Session, URLName)?

Question

We have a web application that sends mail. For some reason, its installation decided that he could not find a constructor for SMTPTransport that accepts arguments (Session, URLName).

The corresponding stack trace bits are:

javax.mail.NoSuchProviderException: Provider class does not have a constructor(Session, URLName): protocol=smtp; type=javax.mail.Provider$Type@1dedf78 ; class=com.sun.mail.smtp.SMTPTransport; vendor=Sun Microsystems, Inc at javax.mail.Session.getService(Session.java:499) at javax.mail.Session.getTransport(Session.java:387) at javax.mail.Session.getTransport(Session.java:347) at javax.mail.Session.getTransport(Session.java:376) at javax.mail.Transport.send(Transport.java:67) at javax.mail.Transport.send(Transport.java:48) ... Caused by: java.lang.NoSuchMethodException: com.sun.mail.smtp.SMTPTransport.<init>(javax.mail.Session, javax.mail.URLName) at java.lang.Class.getConstructor0(Class.java:2706) at java.lang.Class.getConstructor(Class.java:1657) at javax.mail.Session.getService(Session.java:496) ... 8 more 

We have already verified that SMTPTransport exists in the classpath (which is not surprising since we are not getting a ClassNotFoundException) and that this is the only copy of this class in the classpath. This is in tomcat / lib. Our webapp does not include duplicate. There is no duplicate in $ JAVA_HOME / jre / lib.

I even went so far as to decompile the class, to make sure that it actually has a constructor.

I did a bit of searching and found other people who saw the same error , but there were no fixes for this problem.

Answer 1

My colleague and I understood why we are seeing this. I wrote about it here: https://plus.google.com/105513684958738872125/posts/LBnjehZoss6

In short:

While I was looking for a duplicate SMTPTransport class, it was not there. The real culprit was the duplicate class javax.mail.Session, which was added to my webapp. This caused problems with Tomcat hierarchical class loaders.

When the in-webapp session class tried to pass itself on to SMTPTransport at the Tomcat level, it did not recognize the type of session (which was loaded by another class loader) as the type that it needed for its constructor.

Removing duplicate javax.mail classes from webapp fixes the problem.