Log4j，Tapestry5.1，单机版Jetty6不能一起玩吗？

Question

到目前为止，我一直在使用Maven goals编译/打包/执行应用程序来开发Tapestry 5.1.0.5 web应用程序。我使用了mvn jetty:run目标来运行Jetty maven插件。这总是运行得很好。看起来Maven使用了Jetty 6.1.9。

我现在需要设置一个不使用maven目标执行的生产环境。我认为Jetty看起来很简单，而且它已经和Maven一起工作了。我得到了6.1.26 (后来也尝试了6.1.9，但没有成功)，将我的应用程序WAR文件放到webapp目录中，然后尝试运行它……不走运。

每次我收到这个错误，都不会改变：

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)

我最初使用Log4J 1.2.8作为整个应用程序的手动依赖项的一部分。我阅读了这个网站的http://tapestry.apache.org/tapestry5.1/jetty.html，然后意识到我应该使用1.2.12或更高的跟踪级别。首先，我将依赖项更新到LOG4J 1.2.16。这不起作用。

然后，我做了一些进一步的阅读，表明apache-commons-logging依赖关系可能会导致日志问题，这是由于它的工作方式。我检查了我的整个依赖层次结构，并从所有内容中排除了apache-commons-loging.这个应用程序在这一点上仍然可以使用maven jetty插件，所以我这样做并没有破坏任何东西。但是当我部署WAR时，我仍然得到异常，所以这不是解决方案。

下一步，我意识到tapestry-ioc依赖项在我的系统端log4j和它想要的那个之间的log4j版本上存在冲突。它似乎使用了log4j 1.2.13，而依赖项本身中的slf4j使用了编译Log4J 1.2.14。

我将我的系统依赖项更新为first 1.2.14 (因为这个错误发生在Tapestry中的slf4j )，然后当1.2.13再次失败时。这两种情况也都不起作用。

我听说过要确保Jetty不会用它自己用于日志记录的较低版本覆盖您的Log4J。然而，我在Jetty文件中找不到任何log4j依赖项。

Answer 1

我来猜一猜：

这“可能”是由

当maven下载log4j依赖项时，它失败或已损坏-尝试删除maven存储库中的log4j目录(windows: docs和

• 是某种依赖项冲突，maven在解决它方面做得很糟糕，不包括任何一个-这是不太可能的，我认为它将包括最新版本

• 一些其他maven插件或配置导致log4j jar被排除在WAR创建(duh)

之外

不知道还有什么原因会导致这种情况...

编辑重新评论：

啊，是的，既然你提到了，我就有这个问题了！我有几个‘自管理’(即不是maven管理的) jars，据我所知，将它们包含在maven类路径中的唯一方法是给它们一个system作用域。您的问题变成：“如何在maven构建中包含非maven jar？”

scope元素的文档：

依赖项的范围-编译、运行时、测试、系统和提供。用于计算用于编译、测试等的各种类路径。它还有助于确定将哪些工件包含在此项目的分发中。有关更多信息，请参阅依赖机制。

另外，如果您使用systemPath更改条目的作用域，则会在您的pom中出现错误：

只有具有系统范围的

依赖项才能指定systemPath。

EDIT 2:找到一个很好的解决方案...

我找到了this 'issue' report，并遵循了上一条评论所建议的路径：

我们不会这么做的。我猜您可能会添加一个webresource部分，其中包含所需文件的include和一个targetPath。

Here's the documentation regarding the mechanism.

所以你需要做的是：

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

注意:在本例中，路径'unmanaged-lib‘是项目根目录下的一个目录(即pom.xml级别)