Perché Tomcat non riesce a trovare SMTPTransport (Session, URLName)?

Question

Abbiamo un'applicazione web che invia posta. Per qualche ragione, una sua installazione ha deciso che non può trovare il costruttore per SMTPTransport che accetta argomenti (Session, URLName).

bit rilevanti della traccia dello stack:

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 

abbiamo già verificato che SMTPTransport esiste nel percorso di classe (che non è sorprendente, visto che non stiamo ottenendo un ClassNotFoundException), e che è l'unica copia di quella classe nel classpath. È in tomcat/lib. La nostra webapp non include un duplicato. Non c'è un duplicato in $ JAVA_HOME/jre/lib.

Ho anche andato così lontano da decompilare classe per verificare che in effetti hanno il costruttore in questione.

Ho fatto un po 'di google e ho trovato altre persone che hanno seen the same error, ma non ci sono soluzioni per il problema.

Answer 1

Il mio collega ed io abbiamo capito perché stavamo vedendo questo. Ho postato su qui: https://plus.google.com/105513684958738872125/posts/LBnjehZoss6

In sintesi:

Mentre ero alla ricerca di una classe SMTPTransport duplicato, non c'era nessuno per essere trovato. Il vero colpevole era una doppia classe javax.mail.Session che era stata aggiunta alla mia webapp. Ciò ha causato problemi con i classloader gerarchici di Tomcat.

Quando la classe Session in-webapp ha tentato di passare a SMTPTransport a livello Tomcat, quella non ha riconosciuto quel tipo di sessione (che era stata caricata da un altro classloader) come il tipo necessario per il suo costruttore.

La rimozione delle classi javax.mail duplicate dalla webapp risolve il problema.