Java – why can’t Tomcat find smtptransport (session, urlname)?

We have a web application that sends mail For some reason, its installation has decided that it cannot find the constructor of smtptransport with (session, urlname) parameter

Related bits of stack trace:

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 checked that smtptransport does exist in the classpath (this is not surprising because we did not get classnotfoundexception), and it is the only copy of the class in the classpath It is in Tomcat / lib Our webapp does not contain copies$ JAVA_ There are no duplicates in home / JRE / lib

I've even decompiled the class in reverse to verify that it actually has a problematic constructor

I did some Google searches and found that others had seen the same error, but it didn't solve the problem

Solution

My colleagues and I figured out why we saw this I posted it here:

in summary:

Although I was looking for a duplicate smtptransport class, I couldn't find it The real culprit is a duplicate javax mail. Session class, which has been added to my webapp This causes problems with Tomcat's hierarchical class loader

When the in webapp session class tries to pass itself to a Tomcat level smtptransport, that person does not recognize the session type (loaded by different class loaders) as the type required by its constructor

Remove duplicate javax. XML files from webapp Mail class can solve the problem