¿Por qué Tomcat no puede encontrar SMTPTransport (Session, URLName)?

Question

Tenemos una aplicación web que envía correos. Por algún motivo, una instalación de este ha decidido que no puede encontrar el constructor para SMTPTransport que toma argumentos (Session, URLName).

Bits relevantes del seguimiento de la pila:

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 

Ya hemos comprobado que SMTPTransport existe en la ruta de clase (lo cual no es sorprendente, ya que no estamos obteniendo un ClassNotFoundException), y que es la única copia de esa clase en el classpath. Está en tomcat/lib. Nuestra aplicación web no incluye un duplicado. No hay un duplicado en $ JAVA_HOME/jre/lib.

Incluso he ido tan lejos como para descompilar la clase para verificar que de hecho tienen el Constructor de que se trate.

He hecho un poco de búsqueda en Google y he encontrado otras personas que tienen seen the same error, pero no hay soluciones para el problema.

Answer 1

Mi compañero de trabajo y yo descubrimos por qué estábamos viendo esto. He publicado sobre ello aquí: https://plus.google.com/105513684958738872125/posts/LBnjehZoss6

En resumen:

Mientras yo estaba buscando una clase SMTPTransport duplicado, no había ninguno que se encuentran. El verdadero culpable era una clase javax.mail.Session duplicada que se había agregado a mi aplicación web. Esto causó problemas con los cargadores de clase jerárquicos de Tomcat.

Cuando la clase de sesión en-webapp intentó pasar al transporte SMTP de nivel Tomcat, ese no reconoció ese tipo de sesión (que había sido cargado por un cargador de clases diferente) como el tipo que necesitaba para su constructor.

Eliminar las clases duplicadas de javax.mail de la aplicación web soluciona el problema.