Log4j、Tapestry 5.1、独立 Jetty 6 不兼容？

发布于 2024-10-02 15:00:08 字数 3923 浏览 0 评论 0原文

到目前为止，我一直在使用 Maven 目标来开发 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 或更高版本作为 TRACE 级别。首先，我将依赖项更新为 LOG4J 1.2.16。这不起作用。

然后我做了一些进一步的阅读，表明 apache-commons-logging 依赖项可能会由于其工作原理而导致整个日志记录出现问题。我检查了整个依赖层次结构，并从所有内容中排除了 apache-commons-logging。此时该应用程序仍然可以与 Maven jetty 插件一起使用，所以我这样做并没有破坏任何东西。但是当我部署 WAR 时，我仍然遇到异常，所以这不是解决方案。

下一步我意识到 Tapestry-ioc 依赖性在我的系统端 log4j 和它想要的 log4j 版本之间存在冲突。看起来它使用log4j 1.2.13并且依赖项本身中的slf4j使用编译Log4J 1.2.14。

我首先将系统依赖项更新为 1.2.14（因为 Tapestry 中的 slf4j 发生此错误），然后在 1.2.13 再次失败时。这两个案例都没有成功。

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

原文

up to this point I have been developing a Tapestry 5.1.0.5 web-app using Maven goals to compile/package/execute the application. I used the mvn jetty:run goal to run the Jetty maven plugin. This always worked fine. It seems Maven used Jetty 6.1.9.

I now need to setup a production environment that does NOT use maven goals for execution. I thought Jetty seemed simple enough and it was already working with Maven. I got 6.1.26 (later tried 6.1.9 too with no luck), got my application WAR file into the webapp directory and then tried to run it... no luck.

Every single time I get this error, never changes:

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)

I was initially using Log4J 1.2.8 as part of my manual dependencies for my application as a whole. I read this site http://tapestry.apache.org/tapestry5.1/jetty.html and then realized I ought to use 1.2.12 or higher for the TRACE level. First I updated my dependency to LOG4J 1.2.16. This did not work.

I then did some further reading that suggested the apache-commons-logging dependency can cause issues with logging at large due to how it works. I went through my whole dependency hierarchy and excluded the apache-commons-logging from everything. The application still works with maven jetty plugin at this point, so I didn't break anything by doing this. But when I deploy the WAR, I still get the exception, so that was not the solution.

Next step I realized that the tapestry-ioc dependency was conflicting over log4j versions between my system side log4j and the one it wanted. It seems that it uses log4j 1.2.13 and that the slf4j in the dependency itself uses a compile Log4J 1.2.14.

I updated my system dependency to be first 1.2.14 (since this error is occuring at slf4j in Tapestry) and then when that failed again with 1.2.13. Neither of these cases happened to work either.

I've heard mention of making sure Jetty does not override your Log4J with a lower version it uses for its own logging. Yet there is nowhere in the Jetty files that I can find any log4j dependency.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

遥远的绿洲 2024-10-09 15:00:08

我猜测：

这个“可能”是由

引起的

，当maven下载log4j依赖项时，它失败或被损坏 - 尝试删除maven存储库中的log4j目录（Windows：docs和settings/user/ .m2/....)
存在某种依赖冲突，maven 正在通过不包含任何一个来解决它，这很糟糕 - 这不太可能，我认为它会包含最新版本
其他一些 Maven 插件或配置导致 log4j jar从 WAR 创建中排除（废话）

不知道还有什么可能导致此...

编辑重新评论：

啊是的，既然你提到了，我就有这个问题了！我有几个“自我管理”（即非 Maven 管理）jar，据我所知，将它们包含在 Maven 类路径中的唯一方法是给它们一个 system 范围。你的问题变成：“我如何在 Maven 构建中包含非 Maven 罐子？”

scope 元素的文档：

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

如果您使用 systemPath 更改条目的范围，您的 pom 中也会出现错误：

只有系统范围的依赖才能指定systemPath。

编辑2：找到了一个很好的解决方案...

我发现这个“问题”报告，并遵循最后一条评论建议的路径：

我们不会这样做。我想您可能会添加一个网络资源部分，其中包含您想要的文件和一个 targetPath。

这是有关该机制的文档。

所以你需要做的是：

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

注意：在这种情况下，路径“unmanagement-lib”是项目根目录中的一个目录（即与 pom.xml 相同的级别）

i'm going to have a guess:

this 'could' be caused by

when maven downloaded the log4j dependency, it failed or was corrupted - try deleting the log4j directory in your maven repository (windows: docs and settings/user/.m2/....)
there is some kind of dependency conflict and maven is doing a crap job at resolving it by not including either - this is unlikely, i think it would include the most up-to-date version
some other maven plugin or configuration is causing the log4j jar to be excluded from the WAR creation (duh)

dunno what else could cause this...

EDIT re comment:

ah yes, now that you mention it i have that problem to! i have a couple of 'self managed' (ie not maven managed) jars and as far as i know the only way to include them in the maven classpath is to give them a system scope. your question becomes: "how do i include non-maven jars in the maven build?"

the documentation for the scope element:

The scope of the dependency - compile, runtime, test, system, and provided. Used to calculate the various classpaths used for compilation, testing, and so on. It also assists in determining which artifacts to include in a distribution of this project. For more information, see the dependency mechanism.

also an error you get in your pom if you change the scope of an entry with a systemPath:

only dependency with system scope can specify systemPath.

EDIT 2: found a good solution...

i found this 'issue' report, and followed the path suggested by the last comment:

We won't do this. I guess that you might add a webresource section with an include for the files you want and a targetPath.

Here's the documentation regarding the mechanism.

so what you need to do is:

<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: the path 'unmanaged-lib' is a dir in the root of your project in this case (ie level with pom.xml)

回复收藏 0 原文

~没有更多了~