Pot de conflit dans Maven et Tomcat?

Je vais avoir quelques problèmes avec pot de chargement. J'ai déployé une Struts2 web application sur Tomcat, et il a entraîné une erreur:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:....../Tomcat%206.0/lib/slf4j-log4j12-1.5.8.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:....../Tomcat%206.0/webapps/Timesheet/WEB-INF/lib/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
2011-03-31 14:33:48,302 DEBUG com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.loadConfigurationFiles:748 - Loading action configurations from: struts-default.xml
2011-03-31 14:33:50,592 DEBUG com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.loadConfigurationFiles:832 - Loaded action configuration from: struts-default.xml
...
2011-03-31 14:33:50,809 DEBUG com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.register:202 - Loaded type:com.opensymphony.xwork2.util.XWorkConverter name:struts impl:com.opensymphony
.xwork2.util.AnnotationXWorkConverter
Mar 31, 2011 2:33:50 PM org.apache.catalina.core.StandardContext start
SEVERE: Error filterStart
Mar 31, 2011 2:33:50 PM org.apache.catalina.core.StandardContext start
SEVERE: Context [/Timesheet] startup failed due to previous errors

J'ai exclu tous les jar-les conflits dans pom.xml, mais il semble être un autre slf4j-log4j de fichiers dans lib de Tomcat.

Puis j'ai essayé de supprimer le slf4j-log4j12-1.5.8.jar dans Tomcat/lib et exécutez de nouveau la guerre à nouveau, mais encore une autre erreur:

Mar 31, 2011 2:44:51 PM org.apache.catalina.loader.WebappClassLoader validateJarFile
INFO: validateJarFile(...\Tomcat 6.0\webapps\Timesheet\WEB-INF\lib\servlet-api-2.4.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class:
javax/servlet/Servlet.class
... //Struts file still loaded here, but another Error filterStart: the same as above.

Ne me manque quelque chose ici?

EDIT: j'ai supprimer le redondante servlet-api inclus dans pom.xml: il est accidentellement inclus par un autre bocal. Mais après l'exclusion de pot j'ai obtenu l'erreur:

Mar 31, 2011 4:11:19 PM org.apache.catalina.loader.WebappClassLoader validateJarFile
INFO: validateJarFile(...\Tomcat 6.0\webapps\Timesheet\WEB-INF\lib\servlet-api-2.4.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class:
javax/servlet/Servlet.class
2011-03-31 16:11:20,234 DEBUG com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.loadConfigurationFiles:748 - Loading action configurations from: struts-default.xml
2011-03-31 16:11:21,028 DEBUG com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.loadConfigurationFiles:832 - Loaded action configuration from: struts-default.xml

Ma servlet-api dans mon Tomcat a la version 2.5; les exclus servlet-api.jar dans pom.xml a la version 2.4.

OriginalL'auteur Hoàng Long | 2011-03-31

  1. 7

    Je ne pense pas que tomcat est livré avec slf4j groupés, afin de l'enlever de tomcat/lib est une bonne étape.

    Ensuite, vous ne devriez pas avoir servlet-api-x.jar dans WEB-INF/lib, car livré avec tomcat. Marquer comme <scope>provided</scope> dans le pom maven.

    Pour s'assurer que tout est nettoyé appel mvn clean

    Je pense qu'il peut-être en partie la cause, mais le problème persiste encore. Auriez-vous l'esprit de l'examen de ma mise à jour de question?
    Long mvn clean assurez-vous que les vieux pots ne sont pas présents dans la cible
    en fait, "mvn clean" résoudre mon problème même si je n'exclue pas servlet-api-2.4.jar dans pom.xml. Étrange.

    OriginalL'auteur Bozho

  2. 2

    Il semble que quelque chose est en tirant dans servlet-api-2.4.jar ce qui n'est pas censé être déployé dans le cadre d'une webapp. Si vous avez servlet-api comme une dépendance dans votre projet, de s'assurer qu'il a une portée de fourni. Cela indique à maven de l'utiliser pour la compilation, mais pas pour l'emballage. (voir cette Maven entrée de la FAQ et Introduction à la Dépendance Mécanisme).

    Cependant, servlet-api peut également être retiré, car il est référencé transitivement à partir de l'un de vos dépendances du projet. Si c'est le cas, en essayant de course:

    mvn dépendance:arbre

    pour imprimer une liste de dépendances transitives et d'où ils viennent. Dans la sortie, recherche pour le servlet-api de dépendance avec un non-fourni portée. Vous pouvez alors retirer le délinquant par l'ajout de l'exclure de son ancêtre de la dépendance dans votre POM.

    Vous avez raison, mais après exclure de la servlet-api, le problème persiste encore. Je pense que si Tomcat fournir le pot, je n'ai pas besoin de l'inclure dans pom.xml. Est ce que le droit?
    Long: Vous aurez toujours besoin de servlet-api pour la compilation Maven, sinon rien en se référant à la base de Servlet/JSP classes (HttpServlet, ServletRequest, etc.) wont être trouvé lors de la compilation. Il doit toujours être inclus, mais avec "bénéficier" de la portée.
    désolé, mais je ne peux pas trouver un moyen de le faire. Comment puis-je spécifier un bocal, comme prévu, alors que c'est tiré par une dépendance transitive?

    OriginalL'auteur prunge