Dlaczego Tomcat nie może znaleźć SMTPTransport (Session, URLName)?

Question

Mamy aplikację internetową, która wysyła pocztę. Z jakiegoś powodu jego instalacja zdecydowała, że ​​nie może znaleźć konstruktora SMTPTransport, który pobiera argumenty (Session, URLName).

Istotne bity ślad stosu:

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 

Mamy już sprawdzone, że SMTPTransport istnieje w ścieżce klasy (co nie jest zaskakujące, ponieważ nie jesteśmy coraz ClassNotFoundException), i że jest jedyna kopia tej klasy w ścieżce klas. Jest w tomcat/lib. Nasza aplikacja internetowa nie zawiera duplikatu. W $ JAVA_HOME/jre/lib nie ma duplikatu.

mam nawet poszedł tak daleko, aby Dekompilacji klasy w celu sprawdzenia, że ​​robi w rzeczywistości mieć konstruktora w pytaniu.

Zrobiłem trochę wyszukiwania google i znalazłem innych ludzi, którzy mają seen the same error, ale nie ma poprawek dla problemu.

Answer 1

Mój współpracownik i ja zorientowaliśmy się, dlaczego to widzimy. Napisałem o tym tutaj: https://plus.google.com/105513684958738872125/posts/LBnjehZoss6

Podsumowując:

Podczas gdy szukałem duplikatu klasy SMTPTransport, nie było żadnego znaleźć. Prawdziwym winowajcą była zduplikowana klasa javax.mail.Session, która została dodana do mojej aplikacji internetowej. Powodowało to problemy z hierarchicznymi programami ładującymi klasy Tomcat.

Gdy klasa sesji In-Webapp spróbowała przenieść się do poziomu SMTPTransport na poziomie Tomcat, ten nie rozpoznał tego typu sesji (który został załadowany przez inny program ładujący klasy) jako typ potrzebny do jego konstruktor.

Usunięcie zduplikowanych klas javax.mail z aplikacji webowej rozwiązuje problem.