JavaMail non invia Subject o From under jetty: run-war

Question

Qualcuno ha visto JavaMail non inviare correttamente MimeMessages a un server SMTP, a seconda di come è stata avviata la JVM? Alla fine della giornata, non riesco a inviare messaggi SMTP JavaMail con i campi Subject: o From: e sembra che manchino altre intestazioni, solo quando si esegue l'app come guerra.

Il progetto Web è realizzato con Maven e sto testando l'invio di JavaMail utilizzando un browser e un semplice mail.jsp per eseguire il debug e vedere comportamenti diversi all'avvio dell'app con:

  

1) mvn jetty: run (la posta viene inviata correttamente, con i campi Subject e From appropriati)

     

2) mvn jetty: run-war (la posta invia correttamente, ma mancano Oggetto, Da e altri campi)

Ho eseguito meticolosamente diff sull'output (dettagliato) di debug di Maven (-X) e ci sono differenze zero nelle dipendenze di runtime tra i due. Ho anche confrontato le proprietà del sistema e sono identiche. Sta succedendo qualcos'altro il molo: caso run-war che cambia il modo in cui JavaMail si comporta. Quali altre pietre devono essere girate?

Curiosamente, ho provato un debugger in entrambe le situazioni e ho scoperto che l'istanza javax.mail.internet.MimeMessage viene creata in modo diverso. La webapp utilizza Spring per inviare e-mail prelevate da una coda Apache ActiveMQ. Quando si esegue l'app come mvn jetty: run , la variabile MimeMessage.contentStream viene utilizzata per il contenuto del messaggio. Quando si esegue come mvn jetty: run-war , la variabile MimeMessage.content viene utilizzata per il contenuto del messaggio e il     content = ASCIIUtility.getBytes (is); call rimuove tutti i dati dell'intestazione dal contenuto analizzato. Dato che questo sembrava molto strano, e il debug di Spring / ActiveMQ è un tuffo profondo, ho creato un test semplificato senza nessuna di quella infrastruttura: solo un JSP che utilizza mail-1.4.2.jar, ma mancano le stesse intestazioni.

Inoltre, queste intestazioni mancano quando si esegue il file WAR in Tomcat 5.5.27. Tomcat si comporta proprio come Jetty durante l'esecuzione di WAR, con le stesse intestazioni mancanti.

Con il debug JavaMail attivato, vedo chiaramente output diversi.

BUON CASO: nel molo: run (non WAR) l'output del registro è:

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

BAD CASE: l'output del registro durante l'esecuzione come WAR, con intestazioni mancanti, è piuttosto diverso:

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

Ecco l'attuale mail.jsp con cui sto testando la guerra / non-guerra.

<%@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

SOLUZIONE:

Sì, il problema erano le dipendenze transitive di Apache CXF 2. Ho dovuto escludere geronimo-javamail_1.4_spec dalla build e basarmi solo sulla mail-1.4.jar di javax.

<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>

Grazie per tutte le risposte.

Answer 1

È possibile che quando lo costruisci come una GUERRA vengano trascinate altre dipendenze? Sembra che altri abbiano riscontrato questo problema e la causa era un bug in geronimo (per ulteriori informazioni, vedere http://mail-archives.apache.org/mod_mbox/geronimo-user/200902.mbox/%3C21943498.post@talk.nabble.com % 3E ).

Abbiamo anche incluso geronimo-javamail_1.4_spec-1.2 nel nostro prodotto e quel pacchetto ha un bug con le intestazioni. L'abbiamo escluso (insieme a geronimo-attivazione_1.1_spec) dalle nostre dipendenze e il problema è stato corretto.

Answer 2

È la dipendenza che crea questo problema, assicurati di caricare mail.jar prima di altri jar che contengono la classe javax.mail.Transport. Nel mio caso il colpevole era javaee-api-5.0-1.jar

Answer 3

Anche io ho questo stesso problema. Vedo l'e-mail non funzionante quando eseguo TestNG con Spring e un sacco di barattoli di applicazioni. Quando corro con un semplice metodo java principale, funziona benissimo. Ecco le differenze di classe tra quando eseguo questo codice all'interno di TestNG vs PSVM

Queste sono le classi di posta che sono assenti quando corro 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

Questa classe di posta è presente in TestNG ma non in PSVM

 +javax.mail.internet.CachedDataHandler

Answer 4

Nel mio caso, il vero colpevole era una libreria di Amazon che stava sostituendo il meccanismo di trasporto standard:

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

Ho dovuto forzare la Sessione a utilizzare quella standard durante la creazione della sessione:

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

Devo dire che ho anche implementato le correzioni fornite da Jason e Vijay al fine di escludere le librerie geronimo.

Forse il Transport of AMazon SDK utilizza internamente il codice geronimo? ...

Grazie!