0

これまで、Mavenの目標を使用してアプリケーションをコンパイル/パッケージ化/実行するTapestry5.1.0.5Webアプリを開発してきました。mvn jetty：runゴールを使用して、JettyMavenプラグインを実行しました。これは常に正常に機能しました。MavenはJetty6.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)

私は当初、アプリケーション全体の手動依存関係の一部としてLog4J1.2.8を使用していました。このサイトhttp://tapestry.apache.org/tapestry5.1/jetty.htmlを読んだ後、TRACEレベルに1.2.12以上を使用する必要があることに気付きました。まず、依存関係をLOG4J1.2.16に更新しました。これは機能しませんでした。

次に、apache-commons-loggingの依存関係が、その動作方法が原因でロギング全体に問題を引き起こす可能性があることを示唆する、さらにいくつかの読み物を行いました。私は依存関係の階層全体を調べ、apache-commons-loggingをすべてから除外しました。この時点では、アプリケーションはまだMaven Jettyプラグインで動作するため、これを実行しても何も壊れませんでした。しかし、WARをデプロイしても例外が発生するため、それは解決策ではありませんでした。

次のステップでは、tapestry-iocの依存関係が、システム側のlog4jと必要なlog4jの間でlog4jバージョン間で競合していることに気付きました。log4j 1.2.13を使用しており、依存関係自体のslf4jはコンパイルLog4J1.2.14を使用しているようです。

システムの依存関係を最初の1.2.14に更新し（このエラーはTapestryのslf4jで発生しているため）、その後、1.2.13で再び失敗しました。これらのケースはどちらもうまくいきませんでした。

JettyがLog4Jを、独自のロギングに使用するより低いバージョンでオーバーライドしないようにすることについての言及を聞いたことがあります。しかし、Jettyファイルには、log4jの依存関係を見つけることができる場所はありません。

4

1 に答える 1

1

私は推測するつもりです：

この「可能性があります」

  1. mavenがlog4j依存関係をダウンロードしたとき、失敗したか破損していました-mavenリポジトリ（windows：docs and settings / user / .m2 / ....）のlog4jディレクトリを削除してみてください

  2. ある種の依存関係の競合があり、Mavenはどちらも含めないことでそれを解決するためにくだらない仕事をしています-これはありそうもないです、私はそれが最新バージョンを含むと思います

  3. 他のMavenプラグインまたは構成により、log4j jarがWAR作成から除外されています（duh）

他に何がこれを引き起こす可能性があるのか​​わからない...

再コメントを編集：

ああ、そうです、あなたがそれを言ったので、私はその問題を抱えています！私はいくつかの「自己管理」（つまり、Maven管理ではない）jarを持っており、私が知る限り、それらをMavenクラスパスに含める唯一の方法はそれらにsystemスコープを与えることです。あなたの質問は次のようになります：「MavenビルドにMaven以外のjarファイルを含めるにはどうすればよいですか？」

要素のドキュメントscope：

依存関係の範囲-コンパイル、ランタイム、テスト、システム、および提供。コンパイル、テストなどに使用されるさまざまなクラスパスを計算するために使用されます。また、このプロジェクトの配布に含めるアーティファクトを決定するのにも役立ちます。詳細については、依存関係のメカニズムを参照してください。

また、systemPathを使用してエントリのスコープを変更すると、pomでエラーが発生します。

システムスコープとの依存関係のみがsystemPathを指定できます。

編集2：良い解決策を見つけました...

私はこの「問題」レポートを見つけ、最後のコメントで提案されたパスをたどりました。

これは行いません。必要なファイルのインクルードとtargetPathを含むwebresourceセクションを追加すると思います。

これがメカニズムに関するドキュメントです。

だからあなたがする必要があるのは：

<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'は、この場合、プロジェクトのルートのdirです（つまり、pom.xmlのレベル）

于 2010-11-18T01:49:11.113 に答える