mail / Session Resource Factory ne fonctionne pas dans l'application Struts
https://stackoverflow.com/questions/494985
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je souhaite utiliser la fabrique de ressources standard fournie par Tomcat 6.0, qui crée pour moi une instance javax.mail.Sessions. Comme décrit dans le didacticiel sur les ressources JNDI . .
Mon META-INF / context.xml ressemble à:
<?xml version="1.0" encoding="UTF-8"?>
<Context reloadable="true">
<Resource name="mail/Session"
auth="Container"
type="javax.mail.Session"
mail.smtp.host="smtp.gmail.com"
mail.smtp.port="587"
mail.smtp.auth="true"
mail.smtp.user="someone@gmail.com"
mail.smtp.password="secretpassword"
mail.smtp.starttls.enable="true"/>
</Context>
J'ai la référence de ressource suivante dans mon fichier WEB-INF / web.xml, juste avant < / webapps > ;. Web.xml valide. J'ai validé en utilisant À la manière de McDowell .
<resource-ref>
<description>Resource reference to a factory for javax.mail.Session instances that may be used for sending electronic mail messages, preconfigured
to connect to the appropiate SMTP server.
</description>
<res-ref-name>mail/Session</res-ref-name>
<res-type>javax.mail.Session</res-type>
<res-auth>Container</res-auth>
</resource-ref>
J'utilise le code suivant pour accéder à mon objet javax.mail.Session.
Context initCtx = new InitialContext();
Context envCtx = (Context) initCtx.lookup("java:comp/env");
Session session = (Session)envCtx.lookup("mail/Session");
System.out.println("HERE smtp.user: " + session.getProperty("mail.smtp.user"));
Je l'ai testé dans un exemple d'application et cela a fonctionné. Malheureusement, lorsque j'ai déplacé le même code dans une application struts, j'obtiens NULL dans l'instruction print ci-dessus. Je fais le contexte dans singleton Class appelé mailer (ce qui est défini dans mon dossier WEB-INF / classes), mais je rencontre le même problème si je recherche le contexte dans la classe d’action Struts.
J'ai réfléchi à ce qui est différent pour trouver le problème. Mon application web.xml est plus compliquée que le fichier web.xml. Il comporte des contraintes de sécurité, des filtres et la configuration du servlet Struts. Je positionne ressource-ref juste avant les définitions de servlet. Il semble que la ressource-ref est ignorée.
J'ai un autre problème. Si j'ai le mailapi.jar, nécessaire au javax.mail.Session, dans le dossier myapp / WEB-INF / lib, je reçois:
java.lang.NoClassDefFoundError: javax / mail / Authenticator
Si je le mets dans $ CATALINA_HOME / lib est trouvé.
Des idées? J'utilise des jambes de force et hiberne. Cela a peut-être quelque chose à voir avec cela.
Déboguer
J'ai essayé de le déboguer en mettant l'attribut de débogage dans son contexte
<Context reloadable="true" debug="99" ...
Mais je ne vois rien d'intéressant.
01-feb-2009 17:39:09 org.apache.catalina.core.ApplicationContext log
INFO: ContextListener: contextInitialized()
01-feb-2009 17:39:09 org.apache.catalina.core.ApplicationContext log
INFO: SessionListener: contextInitialized()
01-feb-2009 17:39:09 org.apache.catalina.core.ApplicationContext log
INFO: ContextListener: contextInitialized()
01-feb-2009 17:39:09 org.apache.catalina.core.ApplicationContext log
INFO: SessionListener: contextInitialized()
01-feb-2009 17:39:09 org.apache.catalina.core.ApplicationContext log
INFO: ContextListener: contextInitialized()
01-feb-2009 17:39:09 org.apache.catalina.core.ApplicationContext log
j'ai essayé:
Session session = (Session) initCtx.lookup("java:comp/env/mail/Session");
au lieu de:
Context envCtx = (Context) initCtx.lookup("java:comp/env");
Session session = (Session)envCtx.lookup("mail/Session");
Mais je reçois toujours un objet de session NULL.
Solution partielle
Lorsque je place l'élément Resource dans le fichier $ CATALINA_HOME / conf / context.xml, cela fonctionne.
La solution
Caractères bizarres du code de recherche JNDI
J'ai constaté plusieurs problèmes avec le fait de ne pas trouver de ressources JNDI. Sur Websphere (je sais, vous ne l'utilisez pas, mais c'est bon à savoir ...) vous aurez des problèmes avec
Context envCtx = (Context) initCtx.lookup("java:comp/env");
Session session = (Session)envCtx.lookup("mail/Session");
Ce qui fonctionne (sur Websphere) est
Session session = (Session) initCtx.lookup("java:comp/env/mail/Session");
D'après ce que vous avez écrit dans une autre réponse, je comprends que ce n'est pas votre problème. Je le laisse ici aux personnes qui rencontreront le même problème dans des circonstances différentes plus tard.
Recherche de ressources JNDI à partir de threads auto-générés
De même, l'accès aux ressources JNDI peut dépendre du thread qui recherche les ressources. Autant que je me souvienne, le threading n'est pas bien défini dans l'API du servlet (ni dans Java EE ni dans les domaines connexes. Il peut même être volontairement et explicitement non défini.) Par conséquent, il n'est pas obligatoire que le serveur fournisse des ressources JNDI . dans les discussions que vous vous êtes engendrées (encore une fois, Websphere m’a mordu avec cela, je n’ai pas testé Tomcat6 à cet égard, les versions antérieures fournissant des ressources JNDI à toutes les discussions)
Vous avez écrit que vous cherchiez des ressources JNDI à partir d'un singleton. Si vous , au moment de rechercher des ressources, examinez le tracé de pile (dans votre environnement de développement, en lançant une exception ou en bousillant Thread.currentThread().getStacktrace()): est existe-t-il un connecteur Tomcat dans le stacktrace ou une de vos propres méthodes run () de Thread se trouve-t-elle à la racine du stacktrace ? , cela répondrait à la question derrière Jacks question si vous effectuez la recherche à partir d'une classe d'action. (voir la réponse de Jack)
Sujets et environnement de l'appel, deuxième partie
Créez une nouvelle action Struts et appelez votre code de recherche JNDI à partir de là pour voir si cela fonctionne s'il est placé aussi près que possible de struts et dans le traitement d'une demande http. Si cela fonctionne ici, suivez les étapes ci-dessus.
validité du fichier web.xml
Vous pouvez également consulter la définition de schéma de web.xml pour vous assurer que votre ressource-ref est correctement positionnée. La spécification de servlet 2.4 est disponible sur jcp.org et devrait être suffisante. à vérifier, même si tomcat implémente la version 2.5.
Après tout, j'estime que tomcat6 valide le fichier web.xml, de sorte que vous l'avez probablement déjà à la bonne position. (Je ne me souviens plus, car mon éditeur d'EDI se plaint lorsque je me trompe, dois-je écrire un fichier web.xml?)
Options de débogage de Tomcat
De nombreuses entrées context.xml respectent l'attribut 'debug'. Bien que je pense que des valeurs faibles à un chiffre suffisent, j'ai pris l'habitude d'ajouter 'debug = & Quot; 99 & Quot;' à des éléments tels que 'Context' ou autres. Vous voudrez peut-être voir si cela génère des entrées de journal utiles.
Assurez-vous que ce n'est pas le chemin de classe
Comme vous semblez avoir fondamentalement changé l'environnement, assurez-vous de disposer de toutes les bibliothèques requises - l'API de messagerie se compose de plusieurs fichiers jar. Téléchargez une nouvelle copie et décompressez toutes les bibliothèques dans $ CATALINA_HOME / lib. Vous pourriez retirer les ressources inutilisées une fois que cela fonctionnera avec toutes les bibliothèques qu'il contient.
En ce qui concerne votre question sur le chemin d'accès aux classes :
La raison pour laquelle la classe a été trouvée dans $ CATALINA_HOME / lib est que la connexion est établie par le serveur (rappelez-vous que vous l'avez définie dans le fichier context.xml qui est lu par le serveur afin de démarrer l'application. ), le fichier jar doit donc se trouver sur le chemin d'accès aux classes serveurs - et pas seulement sur les applications (voir HOWTO sur les commandes de classe tomcat pour plus d'informations)
EDIT:
Concernant votre solution partielle :
$ CATALINA_HOME / conf / context.xml contient le global & "défaut &"; éléments de contexte. Ce n’est pas là que vous souhaitez que votre configuration spécifique à l’application soit.
La position standard de tomcat est soit dans l'application Web META-INF / context.xml, soit dans un fichier xml (nommé comme vous le souhaitez, se terminant par .xml) dans $ CATALINA_HOME / conf / Catalina / localhost /. La dernière solution est en fait préférable en ce qui concerne META-INF / context.xml, car la configuration est ainsi indépendante de l’application et n’est pas écrasée lors du déploiement d’une nouvelle application.
Ce contexte contient généralement des attributs supplémentaires tels que docBase et path:
<Context docBase="/location/where/you/deployed/your/application" path="/app">
...
</Context>
Ainsi, votre application est disponible sur http://servername:8080/app. Si vous déployez dans le répertoire $ CATALINA_HOME / webapps, la valeur docBase peut être relative à webapp. Cependant, soyez prudent en ce qui concerne les conditions de concurrence: Tomcat déplacera automatiquement les applications dans $ CATALINA_HOME / webapps et pourrait créer le fichier de contexte. En outre, la suppression de l'application Web pour en déployer une nouvelle pourrait amener Tomcat à supprimer le fichier de configuration XML.
Donc, quel que soit votre problème, essayez si votre définition / application de contexte fonctionne quand elle est placée dans $ CATALINA_HOME / conf / Catalina / localhost / app.xml. J'ai l'impression que c'est quelque chose de très simple, où il ne manque que la dernière information pour voir le vrai problème.
Autres conseils
Je pense que vous devriez définir votre contexte dans META-INF / context.xml, et non pas META-INF / web.xml (bien que cela puisse n'être qu'une faute de frappe dans votre message d'origine).
Lorsque vous avez indiqué que vous aviez déplacé votre code vers une application Struts, pourriez-vous être plus précis? Voulez-vous dire que vous faites votre contexte rechercher dans une classe d'action maintenant?
De plus, vous le savez peut-être déjà, mais lorsque vous définissez votre contexte (entrées JNDI, etc.) dans vos applications Web, META-INF / context.xml est acceptable dans l'environnement d'un développeur, je déconseille fortement de l'utiliser dans toute forme d'environnement partagé. et certainement pas dans un environnement de production.
Et que recommandez-vous?
Définissez-le dans JNDI, mais en dehors de votre application Web / WAR. Dans Tomcat, vous pouvez le faire en le plaçant dans le fichier $ {CATALINA_BASE} /conf/context.xml. Cela permet de définir la configuration des ressources externes (courrier, base de données, etc.) en dehors de votre application Web, évitant ainsi de reconditionner votre fichier WAR lorsque vous modifiez la configuration de la base de données ou que vous passez dans un environnement différent avec une base de données différente, par exemple.
Je fais la recherche de contexte en singleton Classe appelée mailer.
Cette classe de courrier est-elle dans WEB-INF / classes ou un fichier JAR dans WEB-INF / lib? Ou est-ce défini ailleurs dans votre classpath? Dans ce dernier cas, vous pouvez envisager de le transférer dans votre application.
Modifier: sur la base de vos dernières découvertes, il semble que le fichier META-INF / context.xml de votre application Web n’entre pas en vigueur. Dans Tomcat, plusieurs scénarios vont mener à cela. Je ne les connais pas en détail, mais voici quelques informations que j'ai pu trouver:
Per - http://tomcat.apache.org/tomcat -5.5-doc / config / host.html
Si le "ient deployXML " l'attribut est défini sur false dans votre élément Host (je crois en server.xml).
deployXML - Définissez la valeur sur false si vous le souhaitez. désactiver l'analyse du fichier context.xml fichier intégré à l'application (situé à /META-INF/context.xml). Les environnements soucieux de la sécurité devraient définir ceci sur false pour empêcher applications d'interagir avec le configuration du conteneur. le l'administrateur sera alors responsable pour fournir un contexte externe fichier de configuration, et le mettre dans $ CATALINA_HOME / conf / [nom_ordinateur] / [nom_hôte] /. La valeur par défaut du drapeau est true.
Per - http://tomcat.apache.org/tomcat -5.5-doc / config / context.html
Si vous avez défini le fichier $ CATALINA_HOME / conf / [nom_ordinateur] / [nom_hôte] / [chemin_contexte] .xml.
Je suis sûr qu'il y en a d'autres, ce sont juste ceux que j'ai pu trouver rapidement.
Comme il s'agit d'un scénario complètement différent de la solution ci-dessus, j'ai choisi d'ajouter une autre réponse plutôt que de modifier la précédente:
Juste au cas où: Assurez-vous qu'il n'y a pas de faute de frappe dans votre définition de contexte, faites extra extra extra extra . Comparez-le avec la version de travail dans $ CATALINA_HOME / conf / context.xml
Nous ne voudrions pas d'un " mail / Sessoin " faire la différence ...
