Log4j, Tapestry 5.1, Stand-Alone Jetty 6 не подыгрывает? - PullRequest
Новая
       17

Log4j, Tapestry 5.1, Stand-Alone Jetty 6 не подыгрывает?

0 голосов
/ 17 ноября 2010

до этого момента я разрабатывал веб-приложение Tapestry 5.1.0.5, используя цели Maven для компиляции / упаковки / выполнения приложения. Я использовал mvn jetty: запустить цель, чтобы запустить плагин 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 (поскольку эта ошибка возникает в slf4j в Tapestry), а затем, когда это снова не удалось с 1.2.13. Ни один из этих случаев не сработал.

Я слышал упоминание о том, что Jetty не переопределяет ваш Log4J с более низкой версией, которую он использует для собственной регистрации. Тем не менее, в файлах Jetty нет нигде, чтобы я мог найти какую-либо зависимость log4j.

1 Ответ

1 голос
/ 18 ноября 2010

У меня будет предположение:

это может быть вызвано

  1. когда maven загрузил зависимость log4j, она не удалась или была повреждена - попробуйте удалить каталог log4j в вашем хранилище maven (windows: документы и настройки / user / .m2 /....)

  2. существует некоторый конфликт зависимостей, и maven делает дерьмовую работу, решая его, не включая ни того, ни другого - это маловероятно, я думаю, что это будет включать самую последнюю версию

  3. какой-то другой плагин или конфигурация maven вызывает исключение файла log4j из файла WAR (duh)

Не знаю, что еще может вызвать это ...

РЕДАКТИРОВАТЬ комментарий:

ах да, теперь, когда вы упомянули об этом, у меня есть проблема! У меня есть пара «самоуправляемых» (то есть не управляемых maven) фляг, и, насколько я знаю, единственный способ включить их в путь классов maven - это дать им область действия system. Ваш вопрос звучит так: «Как мне включить не-maven банки в сборку maven?»

документация для элемента scope:

Область действия зависимости - компиляция, время выполнения, тестирование, система и предоставляемые. Используется для вычисления различных путей к классам, используемых для компиляции, тестирования и так далее. Это также помогает определить, какие артефакты включить в дистрибутив этого проекта. Для получения дополнительной информации см. Механизм зависимости.

также ошибка, которую вы получаете в pom, если вы изменяете область записи с помощью systemPath:

только зависимость от области системы может указывать 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>

примечание: в этом случае путь 'unmanaged-lib' - это каталог в корне вашего проекта (т.е. уровень с pom.xml)

...