Log4j, Tapestry 5.1, Stand-alone Jetty 6 ne joue pas le jeu?

Question

Jusqu'à présent, j'ai développé une application Web Tapestry 5.1.0.5 en utilisant des objectifs Maven pour compiler/compiler/exécuter l'application. J'ai utilisé mvn jetty: run run pour lancer le plugin Jetty maven. Cela a toujours bien fonctionné. Il semble que Maven ait utilisé Jetty 6.1.9.

J'ai maintenant besoin de configurer un environnement de production qui n'utilise pas les objectifs maven pour l'exécution. Je pensais que Jetty semblait assez simple et qu'il travaillait déjà avec Maven. J'ai obtenu 6.1.26 (plus tard essayé 6.1.9 aussi sans aucune chance), a obtenu mon fichier WAR de l'application dans le répertoire webapp et ensuite essayé de l'exécuter ... pas de chance.

Chaque fois que je reçois cette erreur, ne change jamais:

2010-11-17 18:33:13.436:WARN::Error starting handlers 
java.lang.NoClassDefFoundError: org/apache/log4j/Level 
at org.slf4j.LoggerFactory.getSingleton(LoggerFactory.java:228) 
at org.slf4j.LoggerFactory.bind(LoggerFactory.java:120) 
at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:111) 
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:269) 
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:242) 
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:255) 
at org.apache.tapestry5.TapestryFilter.<init>(TapestryFilter.java:45) 
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) 
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) 
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) 
at java.lang.reflect.Constructor.newInstance(Constructor.java:513) 
at java.lang.Class.newInstance0(Class.java:355) 
at java.lang.Class.newInstance(Class.java:308) 
at org.mortbay.jetty.servlet.Holder.newInstance(Holder.java:153) 
at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:92) 
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) 
at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:713) 
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) 
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282) 
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518) 
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499) 
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) 
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) 
at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) 
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) 
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) 
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) 
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) 
at org.mortbay.jetty.Server.doStart(Server.java:224) 
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) 
at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
at java.lang.reflect.Method.invoke(Method.java:597) 
at org.mortbay.start.Main.invokeMain(Main.java:194) 
at org.mortbay.start.Main.start(Main.java:534) 
at org.mortbay.start.Main.start(Main.java:441) 
at org.mortbay.start.Main.main(Main.java:119) 

j'utilisais d'abord Log4J 1.2.8 dans le cadre de mes dépendances manuelles pour mon application dans son ensemble. J'ai lu ce site http://tapestry.apache.org/tapestry5.1/jetty.html puis j'ai réalisé que je devrais utiliser 1.2.12 ou plus pour le niveau TRACE. J'ai d'abord mis à jour ma dépendance à LOG4J 1.2.16. Cela n'a pas fonctionné. J'ai ensuite fait d'autres lectures qui suggéraient que la dépendance d'apache-commons-logging pouvait causer des problèmes de journalisation en raison de son fonctionnement. J'ai parcouru toute ma hiérarchie de dépendances et exclu la journalisation apache-commons de tout. L'application fonctionne toujours avec maven jetty plugin à ce stade, donc je n'ai rien cassé en faisant cela. Mais quand je déploie le WAR, je reçois toujours l'exception, donc ce n'était pas la solution.

La prochaine étape J'ai réalisé que la dépendance de la tapestry-ioc était en conflit sur les versions de log4j entre mon log4j côté système et celui qu'il voulait. Il semble qu'il utilise log4j 1.2.13 et que slf4j dans la dépendance elle-même utilise une compilation Log4J 1.2.14.

J'ai mis à jour ma dépendance de système pour être 1.2.14 d'abord (puisque cette erreur se produit à slf4j dans la tapisserie) et puis quand cela a encore échoué avec 1.2.13. Aucun de ces cas n'est arrivé à travailler non plus.

J'ai entendu parler de faire en sorte que Jetty ne remplace pas votre Log4J avec une version inférieure qu'il utilise pour sa propre journalisation. Pourtant, il n'y a nulle part dans les fichiers Jetty que je peux trouver une dépendance de log4j.

Answer 1

je vais avoir une estimation:

cette « pourrait » être causé par

1. lorsque maven téléchargé la dépendance log4j, il a échoué ou a été corrompu - essayez de supprimer le répertoire log4j dans votre référentiel maven (windows: docs et settings/user/.m2/....)

2. il y a une sorte de conflit de dépendance et maven fait un travail de merde pour le résoudre en ne comprenant pas non plus - c'est peu probable , je pense qu'il comprendrait le plus à jour Version

3. un autre plugin Maven ou la configuration est à l'origine du pot de log4j à exclure de la création WAR (duh)

ne sais pas ce autre pourrait provoquer ce ...

EDIT re commentaire:

ah oui, maintenant que vous le mentionnez j'ai ce problème à!J'ai un couple de jars 'auto-géré' (c'est-à-dire non géré par maven) et autant que je sache, la seule façon de les inclure dans le classpath maven est de leur donner une portée de system. votre question devient: "comment puis-je inclure des jarres non-maven dans la construction maven?"

la documentation de l'élément scope:

La portée de la dépendance - la compilation, l'exécution, test, système, et fourni. Utilisé pour calculer les différents classpaths utilisés pour la compilation, les tests, etc. Il aide également à déterminer les artefacts à inclure dans une distribution de ce projet. Pour plus d'informations, voir le mécanisme de dépendance.

aussi une erreur que vous obtenez dans votre pom si vous changez la portée d'une entrée avec un systemPath:

seule dépendance avec la portée du système peut spécifier systemPath.

EDIT 2: a trouvé une bonne solution ...

j'ai trouvé this 'issue' report, et a suivi le chemin proposé par le dernier commentaire:

Nous ne le ferons pas. Je suppose que vous pourriez ajouter une section webresource avec un include pour les fichiers que vous voulez et un targetPath.

Here's the documentation regarding the mechanism.

donc ce que vous devez faire est:

<build> 
... 
    <plugins> 
... 

     <plugin> 
      <groupId>org.apache.maven.plugins</groupId> 
      <artifactId>maven-war-plugin</artifactId> 
      <version>2.1.1</version> 
      <configuration> 
       <webResources> 
        <resource> 
         <directory>unmanaged-lib</directory> 
         <targetPath>WEB-INF/lib</targetPath> 
         <includes> 
          <include>**/*.jar</include> 
         </includes> 
        </resource> 
       </webResources> 
      </configuration> 
     </plugin> 

... 
    <plugins> 
... 
<build> 

Note: le chemin « -lib non géré » est un répertoire à la racine de votre projet dans ce cas (niveau avec pom.xml)