JavaMail n'envoyant pas de sujet ou de sous jetée: run-war

StackOverflow https://stackoverflow.com/questions/1010296

  •  06-07-2019
  •  | 
  •  

Question

Quelqu'un a-t-il déjà vu JavaMail n'envoyant pas de MimeMessages corrects à un serveur SMTP, en fonction du démarrage de la JVM? À la fin de la journée, je ne peux pas envoyer de messages JavaMail SMTP avec les champs Objet: ou De: et il apparaît que d'autres en-têtes sont manquants, uniquement lorsque l'application est exécutée en tant que guerre.

Le projet Web est construit avec Maven et je teste l'envoi de JavaMail à l'aide d'un navigateur et d'un simple mail.jsp pour déboguer et voir un comportement différent lors du lancement de l'application avec:

  

1) mvn jetty: run (le courrier envoie très bien, avec les champs Subject et From appropriés)

     

2) mvn jetty: run-war (le courrier est envoyé correctement, mais les champs Subject, From et autres sont manquants)

J'ai exécuté méticuleusement diff sur la sortie de débogage Maven (-x) (commentée), et les différences de dépendance d'exécution entre les deux sont nulles. J'ai également comparé les propriétés du système et elles sont identiques. Quelque chose d'autre se passe sur la jetée: un cas de guerre qui change le comportement de JavaMail. Quelles autres pierres ont besoin de tourner?

Curieusement, j’ai essayé un débogueur dans les deux situations et constaté que l’instance javax.mail.internet.MimeMessage est créée différemment. La webapp utilise Spring pour envoyer des emails provenant d'une file d'attente Apache ActiveMQ. Lors de l'exécution de l'application en tant que mvn jetty: run , la variable MimeMessage.contentStream est utilisée pour le contenu du message. Lors de l'exécution en tant que mvn jetty: run-war , la variable MimeMessage.content est utilisée pour le contenu du message et     content = ASCIIUtility.getBytes (est); call supprime toutes les données d'en-tête du contenu analysé. Comme cela semblait très étrange et que le débogage de Spring / ActiveMQ est une plongée en profondeur, j'ai créé un test simplifié sans cette infrastructure: juste un JSP utilisant mail-1.4.2.jar, mais les mêmes en-têtes sont manquants.

Il convient également de noter que ces en-têtes sont manquants lors de l’exécution du fichier WAR sous Tomcat 5.5.27. Tomcat se comporte comme Jetty lors de l’exécution du WAR, avec les mêmes en-têtes manquants.

Lorsque le débogage JavaMail est activé, les résultats sont clairement différents.

GOOD CASE: Dans la jetée: run (non-WAR), la sortie du journal est: 

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: la sortie du journal lors de l'exécution en tant que WAR, avec les en-têtes manquants, est très différente: 

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

Voici le mail.jsp avec lequel je teste guerre / non guerre. 

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

SOLUTION:

Oui, le problème était lié aux dépendances transitives d'Apache CXF 2. Je devais exclure geronimo-javamail_1.4_spec de la construction et me fier simplement à mail-1.4.jar de 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>

Merci pour toutes les réponses.

Était-ce utile?

La solution

Est-il possible que lorsque vous le construisez en tant que fichier WAR, d'autres dépendances soient intégrées? Il semble que d’autres aient rencontré ce problème, ce qui est probablement à cause d’un bogue dans geronimo (pour plus d’informations, voir http://mail-archives.apache.org/mod_mbox/geronimo-user/200902.mbox/%3C21943498.post@talk.nabble.com % 3E ).

Nous avions également geronimo-javamail_1.4_spec-1.2 inclus dans notre produit et ce package contient un bogue avec les en-têtes. Nous avons exclu cela (ainsi que geronimo-activation_1.1_spec) de nos dépendances et le problème a été corrigé.

Autres conseils

C'est la dépendance qui crée ce problème, assurez-vous de charger le fichier mail.jar avant les autres fichiers jar contenant la classe javax.mail.Transport. Dans mon cas, le coupable était javaee-api-5.0-1.jar

J'ai le même problème aussi. Je vois le courrier électronique endommagé lorsque je lance TestNG avec Spring et tout un ensemble de fichiers jar. Lorsque je cours dans une méthode principale simple java, cela fonctionne bien. Voici les différences de classes entre le moment où je lance ce code dans TestNG et PSVM

Il s’agit des classes de courrier absentes lors de l’exécution de 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

Cette classe de courrier est présente dans TestNG mais pas dans PSVM 

 +javax.mail.internet.CachedDataHandler

Dans mon cas, le coupable était une bibliothèque amazonienne qui remplaçait le mécanisme de transport standard: 

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

J'ai dû forcer la session à utiliser la version standard lors de la création de la session: 

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

Je dois mentionner que j'ai également implémenté les correctifs fournis par Jason et Vijay afin d'exclure les bibliothèques geronimo.

Peut-être que le transport de AMazon SDK utilise le code geronimo en interne? ...

Merci!

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top