JavaMail senden nicht Unterliegen, oder unter jetty:run-Krieg

Question

Hat jemand gesehen JavaMail senden nicht die richtige MimeMessages zu einem SMTP-server, je nachdem, wie die JVM-in gestartet?Am Ende des Tages, ich kann nicht senden JavaMail-SMTP-Nachrichten mit dem Betreff:oder Aus:Felder, und es scheint, andere Header fehlen, nur, wenn Sie die app wie einen Krieg.

Das web-Projekt mit Maven gebaut und ich Teste das senden JavaMail mit einem browser und einer einfachen mail.jsp-Code zum Debuggen und sehen Sie das unterschiedliche Verhalten beim Start der app mit:

1) mvn jetty:run (mail sendet feine, mit der richtigen Thema und Felder)

2) mvn jetty:run-Krieg (mail sendet in Ordnung, aber fehlt Betreff, Von, und anderen Bereichen)

Ich habe akribisch diff " auf die (ausführliche) Maven debug output (-X), und es sind keine Unterschiede in der Laufzeit-Abhängigkeiten zwischen den beiden.Ich habe auch im Vergleich der Systemeigenschaften, und Sie sind identisch.Etwas anderes ist passiert jetty:run-Krieg Fall, dass die Art und Weise ändert JavaMail verhält.Welche anderen Steine müssen drehen?

Neugierig, ich habe versucht, einen debugger in beiden Situationen, und festgestellt, dass die javax.E-mail.internet.MimeMessage Instanz immer erstellt unterschiedlich.Die webapp ist mit Spring zum senden von E-Mail-abgepflückt werden von einem Apache ActiveMQ-Warteschlange.Beim ausführen der app mvn jetty:run die MimeMessage.contentStream variable verwendet wird, für den Inhalt der Nachricht.Bei Ausführung als mvn jetty:run-war, die MimeMessage.Inhalt variable verwendet wird, für die der Inhalt der Nachricht, und die content = ASCIIUtility.getBytes(ist);Aufruf entfernt alle Kopfdaten aus den analysierten Inhalten.Da das erschien mir sehr sonderbar, und Debuggen Frühjahr/ActiveMQ ist ein deep dive, habe ich eine vereinfachte testen, ohne dass Infrastruktur:nur einer JSP verwenden mail-1.4.2.jar, noch das gleiche-Header fehlen.

Auch ist zu beachten, dass dieser Header fehlt, wenn laufen die war-Datei unter Tomcat 5.5.27.Tomcat verhält sich genauso wie Jetty beim ausführen des KRIEGES, mit den gleichen fehlenden Header.

Mit JavaMail-debugging eingeschaltet, ich sehe deutlich verschiedene Leistung.

GUTES BEISPIEL:In der jetty:run (non-KRIEG) die log-Ausgabe:

DEBUG: JavaMail version 1.4.2
DEBUG: successfully loaded resource: /META-INF/javamail.default.providers
DEBUG: Tables of loaded providers
DEBUG: Providers Listed By Class Name: {com.sun.mail.smtp.SMTPSSLTransport=javax.mail.Provider[TRANSPORT,smtps,com.sun.mail.smtp.SMTPSSLTransport,Sun Microsystems, Inc], com.sun.mail.smtp.SMTPTransport=javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc], com.sun.mail.imap.IMAPSSLStore=javax.mail.Provider[STORE,imaps,com.sun.mail.imap.IMAPSSLStore,Sun Microsystems, Inc], com.sun.mail.pop3.POP3SSLStore=javax.mail.Provider[STORE,pop3s,com.sun.mail.pop3.POP3SSLStore,Sun Microsystems, Inc], com.sun.mail.imap.IMAPStore=javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Sun Microsystems, Inc], com.sun.mail.pop3.POP3Store=javax.mail.Provider[STORE,pop3,com.sun.mail.pop3.POP3Store,Sun Microsystems, Inc]}
DEBUG: Providers Listed By Protocol: {imaps=javax.mail.Provider[STORE,imaps,com.sun.mail.imap.IMAPSSLStore,Sun Microsystems, Inc], imap=javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Sun Microsystems, Inc], smtps=javax.mail.Provider[TRANSPORT,smtps,com.sun.mail.smtp.SMTPSSLTransport,Sun Microsystems, Inc], pop3=javax.mail.Provider[STORE,pop3,com.sun.mail.pop3.POP3Store,Sun Microsystems, Inc], pop3s=javax.mail.Provider[STORE,pop3s,com.sun.mail.pop3.POP3SSLStore,Sun Microsystems, Inc], smtp=javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc]}
DEBUG: successfully loaded resource: /META-INF/javamail.default.address.map
DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc]
DEBUG SMTP: useEhlo true, useAuth true
DEBUG SMTP: trying to connect to host "mail.authsmtp.com", port 465, isSSL false
220 mail.authsmtp.com ESMTP Sendmail 8.14.2/8.14.2/Kp; Thu, 18 Jun 2009 01:35:24 +0100 (BST)
DEBUG SMTP: connected to host "mail.authsmtp.com", port: 465

EHLO jmac.local
250-mail.authsmtp.com Hello sul-pubs-3a.Stanford.EDU [171.66.201.2], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE 52428800
250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN
250-DELIVERBY
250 HELP
DEBUG SMTP: Found extension "ENHANCEDSTATUSCODES", arg ""
DEBUG SMTP: Found extension "PIPELINING", arg ""
DEBUG SMTP: Found extension "8BITMIME", arg ""
DEBUG SMTP: Found extension "SIZE", arg "52428800"
DEBUG SMTP: Found extension "AUTH", arg "CRAM-MD5 DIGEST-MD5 LOGIN PLAIN"
DEBUG SMTP: Found extension "DELIVERBY", arg ""
DEBUG SMTP: Found extension "HELP", arg ""
DEBUG SMTP: Attempt to authenticate
DEBUG SMTP: check mechanisms: LOGIN PLAIN DIGEST-MD5 
AUTH LOGIN
334 VXNlcm5hjbt7
YWM0MDkwhi==
334 UGFzc3dvjbt7
YXV0aHNtdHAydog3
235 2.0.0 OK Authenticated
DEBUG SMTP: use8bit false
MAIL FROM:<webmaster@mydomain.org>
250 2.1.0 <webmaster@mydomain.org>... Sender ok
RCPT TO:<jason@mydomain.org>
250 2.1.5 <jason@mydomain.org>... Recipient ok
DEBUG SMTP: Verified Addresses
DEBUG SMTP:   Jason Thrasher <jason@mydomain.org>
DATA
354 Enter mail, end with "." on a line by itself
From: Webmaster <webmaster@mydomain.org>
To: Jason Thrasher <jason@mydomain.org>
Message-ID: <5158456.0.1245285323633.JavaMail.jason@mail.authsmtp.com>
Subject: non-Spring: Hello World
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: 7bit

Hello World: message body here
.
250 2.0.0 n5I0ZOkD085654 Message accepted for delivery
QUIT
221 2.0.0 mail.authsmtp.com closing connection

BÖSE FALLE:Die log-Ausgabe beim laufen als einen KRIEG, mit fehlenden Header, ist eine ganz andere:

Loading javamail.default.providers from jar:file:/Users/jason/.m2/repository/javax/mail/mail/1.4.2/mail-1.4.2.jar!/META-INF/javamail.default.providers
DEBUG: loading new provider protocol=imap, className=com.sun.mail.imap.IMAPStore, vendor=Sun Microsystems, Inc, version=null
DEBUG: loading new provider protocol=imaps, className=com.sun.mail.imap.IMAPSSLStore, vendor=Sun Microsystems, Inc, version=null
DEBUG: loading new provider protocol=smtp, className=com.sun.mail.smtp.SMTPTransport, vendor=Sun Microsystems, Inc, version=null
DEBUG: loading new provider protocol=smtps, className=com.sun.mail.smtp.SMTPSSLTransport, vendor=Sun Microsystems, Inc, version=null
DEBUG: loading new provider protocol=pop3, className=com.sun.mail.pop3.POP3Store, vendor=Sun Microsystems, Inc, version=null
DEBUG: loading new provider protocol=pop3s, className=com.sun.mail.pop3.POP3SSLStore, vendor=Sun Microsystems, Inc, version=null
Loading javamail.default.providers from jar:file:/Users/jason/Documents/dev/subscribeatron/software/trunk/web/struts/target/work/webapp/WEB-INF/lib/mail-1.4.2.jar!/META-INF/javamail.default.providers
DEBUG: loading new provider protocol=imap, className=com.sun.mail.imap.IMAPStore, vendor=Sun Microsystems, Inc, version=null
DEBUG: loading new provider protocol=imaps, className=com.sun.mail.imap.IMAPSSLStore, vendor=Sun Microsystems, Inc, version=null
DEBUG: loading new provider protocol=smtp, className=com.sun.mail.smtp.SMTPTransport, vendor=Sun Microsystems, Inc, version=null
DEBUG: loading new provider protocol=smtps, className=com.sun.mail.smtp.SMTPSSLTransport, vendor=Sun Microsystems, Inc, version=null
DEBUG: loading new provider protocol=pop3, className=com.sun.mail.pop3.POP3Store, vendor=Sun Microsystems, Inc, version=null
DEBUG: loading new provider protocol=pop3s, className=com.sun.mail.pop3.POP3SSLStore, vendor=Sun Microsystems, Inc, version=null
DEBUG: getProvider() returning provider protocol=smtp; type=javax.mail.Provider$Type@98203f; class=com.sun.mail.smtp.SMTPTransport; vendor=Sun Microsystems, Inc
DEBUG SMTP: useEhlo true, useAuth false
DEBUG SMTP: trying to connect to host "mail.authsmtp.com", port 465, isSSL false
220 mail.authsmtp.com ESMTP Sendmail 8.14.2/8.14.2/Kp; Thu, 18 Jun 2009 01:51:46 +0100 (BST)
DEBUG SMTP: connected to host "mail.authsmtp.com", port: 465

EHLO jmac.local
250-mail.authsmtp.com Hello sul-pubs-3a.Stanford.EDU [171.66.201.2], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE 52428800
250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN
250-DELIVERBY
250 HELP
DEBUG SMTP: Found extension "ENHANCEDSTATUSCODES", arg ""
DEBUG SMTP: Found extension "PIPELINING", arg ""
DEBUG SMTP: Found extension "8BITMIME", arg ""
DEBUG SMTP: Found extension "SIZE", arg "52428800"
DEBUG SMTP: Found extension "AUTH", arg "CRAM-MD5 DIGEST-MD5 LOGIN PLAIN"
DEBUG SMTP: Found extension "DELIVERBY", arg ""
DEBUG SMTP: Found extension "HELP", arg ""
DEBUG SMTP: Attempt to authenticate
DEBUG SMTP: check mechanisms: LOGIN PLAIN DIGEST-MD5 
AUTH LOGIN
334 VXNlcm5hjbt7
YWM0MDkwhi==
334 UGFzc3dvjbt7
YXV0aHNtdHAydog3
235 2.0.0 OK Authenticated
DEBUG SMTP: use8bit false
MAIL FROM:<webmaster@mydomain.org>
250 2.1.0 <webmaster@mydomain.org>... Sender ok
RCPT TO:<jason@mydomain.org>
250 2.1.5 <jason@mydomain.org>... Recipient ok
DEBUG SMTP: Verified Addresses
DEBUG SMTP:   Jason Thrasher <jason@mydomain.org>
DATA
354 Enter mail, end with "." on a line by itself

Hello World: message body here
.
250 2.0.0 n5I0pkSc090137 Message accepted for delivery
QUIT
221 2.0.0 mail.authsmtp.com closing connection

Hier ist die eigentliche E-mail.jsp, dass ich testen, Krieg oder nicht-Krieg mit.

<%@page import="java.util.*"%>
<%@page import="javax.mail.internet.*"%>
<%@page import="javax.mail.*"%>

<%
    InternetAddress from = new InternetAddress("webmaster@mydomain.org", "Webmaster");
    InternetAddress to = new InternetAddress("jason@mydomain.org", "Jason Thrasher");
    String subject = "non-Spring: Hello World";
    String content = "Hello World: message body here";

    final Properties props = new Properties();
    props.setProperty("mail.transport.protocol", "smtp");
    props.setProperty("mail.host", "mail.authsmtp.com");
    props.setProperty("mail.port", "465");
    props.setProperty("mail.username", "myusername");
    props.setProperty("mail.password", "secret");
    props.setProperty("mail.debug", "true");
    props.setProperty("mail.smtp.auth", "true");
    props.setProperty("mail.smtp.socketFactory.class", "javax.net.ssl.SSLSocketFactory");
    props.setProperty("mail.smtp.socketFactory.fallback", "false");

    Session mailSession = Session.getDefaultInstance(props);

    Message message = new MimeMessage(mailSession);
    message.setFrom(from);
    message.setRecipient(Message.RecipientType.TO, to);
    message.setSubject(subject);
    message.setContent(content, "text/plain;charset=UTF-8");

    Transport trans = mailSession.getTransport();
    trans.connect(props.getProperty("mail.host"), Integer
            .parseInt(props.getProperty("mail.port")), props
            .getProperty("mail.username"), props
            .getProperty("mail.password"));
    trans.sendMessage(message, message
            .getRecipients(Message.RecipientType.TO));
    trans.close();
%>

email was sent

LÖSUNG:

Ja, das problem war transitiven Abhängigkeiten von Apache CXF 2.Ich musste ausschließen, geronimo-javamail_1.4_spec aus zu bauen, und Verlass dich einfach auf javax s mail-1.4.jar.

<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-rt-frontend-jaxws</artifactId>
    <version>2.2.6</version>
    <exclusions>
        <exclusion>
            <groupId>org.apache.geronimo.specs</groupId>
            <artifactId>geronimo-javamail_1.4_spec</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Vielen Dank für alle Antworten.

Answer 1

Ist es möglich, dass, wenn Sie bauen es wie ein KRIEG, der andere Abhängigkeiten gezogen, in?Es scheint, andere haben auf dieses problem, und die Ursache war ein Fehler in geronimo (weitere Informationen finden Sie unter http://mail-archives.apache.org/mod_mbox/geronimo-user/200902.mbox/%3C21943498.post@talk.nabble.com%3E ).

Wir hatten auch geronimo-javamail_1.4_spec-1.2 enthalten in unsere Produkt und Paket hat einen Fehler mit Header.Wir ausgeschlossen, dies (zusammen mit geronimo-activation_1.1_spec) von unseren Abhängigkeiten und das problem behoben.

Answer 2

Es ' SS die Abhängigkeit schafft dieses problem, machen Sie sicher laden mail.jar bevor andere jar, die enthält javax.E-mail.Transport Klasse.In meinem Fall der Täter war javaee-api-5.0-1.jar

Answer 3

Ich habe das gleiche problem auch.Ich sehe den gebrochenen E-Mail, sobald ich laufen in TestNG mit Feder und eine ganze Reihe von Anwendung Gläser.Wenn ich in einer reinen java-main-Methode, funktioniert es einwandfrei.Hier sind die Klassenunterschiede zwischen, wenn ich diesen code ausführen innen TestNG vs PSVM

Diese E-mail-Klassen sind nicht vorhanden, wenn ich Lauf in TestNG:

-com.sun.mail.smtp.SMTPTransport$Authenticator
-com.sun.mail.smtp.SMTPTransport$DigestMD5Authenticator
-com.sun.mail.smtp.SMTPTransport$LoginAuthenticator
-com.sun.mail.smtp.SMTPTransport$PlainAuthenticator
-com.sun.mail.util.FolderClosedIOException
-com.sun.mail.util.MessageRemovedIOException
-com.sun.mail.util.PropUtil
-javax.mail.FolderClosedException
-javax.mail.MessageRemovedException
-javax.mail.Multipart
-javax.mail.internet.ParameterList$MultiValue
-javax.net.SocketFactory
-javax.net.ssl.SSLException
-javax.net.ssl.SSLPeerUnverifiedException
-javax.net.ssl.SSLSocket

Diese E-mail-Klasse gibt es in TestNG, aber nicht PSVM

 +javax.mail.internet.CachedDataHandler

Answer 4

In meinem Fall, wird der eigentliche Täter war einige amazon-Bibliothek wurde ersetzt die standard-transport-Mechanismus:

<dependency>
       <groupId>com.amazonaws</groupId>
       <artifactId>aws-java-sdk</artifactId>
       <version>1.3.9</version>
</dependency>

Ich musste mich zwingen, die Sitzung für die Verwendung der standard zurück, der beim erstellen der Sitzung:

properties.setProperty("mail.smtp.class", "com.sun.mail.smtp.SMTPTransport"); // Fix to prevent Amazon AWS from giving their transport

Ich muss erwähnen, dass ich auch umgesetzt, die Updates gegeben, die von Jason und Vijay um auszuschließen, geronimo Bibliotheken.

Vielleicht ist der Transport von AMazon SDK ist mit geronimo code intern?...

Vielen Dank!