Java и Tomcat: серьезная ошибка при запуске запутанного приложения с гибернацией внутри

#java #hibernate #tomcat #obfuscation #war

#java #спящий режим #tomcat #запутывание #Война

Вопрос:

Это немного сложно объяснить..

Я использую tomcat 6.0 для тестирования развертывания файла WAR. Я использую ProGuard для запутывания файла WAR.

Чтобы использовать ProGuard, все com.*, org. * и т.д., Которые обычно находятся в WEB-INF / classes, Должны быть упакованы в один файл .jar в WEB-INF / lib.

Пока все в порядке.

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

Мой файл журнала (настроен на ОТЛАДКУ) выдает мне:

 [2011-11-11 10:19:33] [1381 prunsrv.c] [debug] Commons Daemon procrun log initialized
[2011-11-11 10:19:33] [info] Commons Daemon procrun (1.0.2.0) started
[2011-11-11 10:19:33] [info] Running Service...
[2011-11-11 10:19:33] [1165 prunsrv.c] [debug] Inside ServiceMain...
[2011-11-11 10:19:33] [info] Starting service...
[2011-11-11 10:19:33] [447  javajni.c] [debug] Jvm Option[0] -Dcatalina.home=C:tomcatTomcat 6.0
[2011-11-11 10:19:33] [447  javajni.c] [debug] Jvm Option[1] -Dcatalina.base=C:tomcatTomcat 6.0
[2011-11-11 10:19:33] [447  javajni.c] [debug] Jvm Option[2] -Djava.endorsed.dirs=C:tomcatTomcat 6.0endorsed
[2011-11-11 10:19:33] [447  javajni.c] [debug] Jvm Option[3] -Djava.io.tmpdir=C:tomcatTomcat 6.0temp
[2011-11-11 10:19:33] [447  javajni.c] [debug] Jvm Option[4] -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
[2011-11-11 10:19:33] [447  javajni.c] [debug] Jvm Option[5] -Djava.util.logging.config.file=C:tomcatTomcat 6.0conflogging.properties
[2011-11-11 10:19:33] [447  javajni.c] [debug] Jvm Option[6] -Djava.class.path=C:tomcatTomcat 6.0binbootstrap.jar
[2011-11-11 10:19:33] [447  javajni.c] [debug] Jvm Option[7] vfprintf
[2011-11-11 10:19:33] [629  javajni.c] [debug] argv[0] = start
[2011-11-11 10:19:33] [655  javajni.c] [debug] Java Worker thread started org/apache/catalina/startup/Bootstrap:main
[2011-11-11 10:19:34] [1006 prunsrv.c] [debug] Java started org/apache/catalina/startup/Bootstrap
[2011-11-11 10:19:34] [info] Service started in 1138 ms.
[2011-11-11 10:19:34] [1272 prunsrv.c] [debug] Waiting worker to finish...
  

а затем останавливается.

Каталина выдает мне:

 11-Nov-2011 10:21:35 org.apache.catalina.core.StandardContext start
SEVERE: Error listenerStart
  

Есть ли у кого-нибудь опыт запуска hibernate внутри запутываемой war (war на самом деле еще не запутан, он просто настроен в формате, в котором он нужен ProGuard для запутывания), независимого jar или даже просто как получить более точное ведение журнала!

Спасибо

ОБНОВЛЕНИЕ: Я думал, что Tomcat находит jar, где находятся классы com.* и т.д., Но теперь я не уверен. Кто-нибудь знает, как использовать web.xml указывать внутри определенного файла .jar в папке WEB-INF / lib?

В настоящее время это, например:

 <listener>
    <listener-class>com.*etc*.HibernateListener</listener-class>
</listener>

<servlet>

    <servlet-name>Application Name</servlet-name>
    <servlet-class>com.vaadin.terminal.gwt.server.ApplicationServlet</servlet-class>

etc etc...
  

но все эти пути должны указывать внутри файла .jar. Или же свойство в web.xml необходимо определить, где можно найти эти пути.

Спасибо

Комментарии:

1. listenerStart не означает, что прослушиватель не найден. Вместо этого это означает, что прослушиватель выдает исключение при загрузке. В вашем журнале не отображается никакого журнала org.hibernate? Не могли бы вы настроить ведение журнала так, чтобы показывать все? Я подозреваю, что ошибка пропущена.

Ответ №1:

Решена.

Для всех, у кого такая же проблема: я наконец-то запустил ведение журнала, используя файл logging.properties в WEB-INF/classes . я ввел настройки, найденные во многих сообщениях на форуме, именно на этот случай. Основной настройкой была ОТЛАДКА, чтобы уловить максимальную детализацию.

Это протоколирование позволило мне увидеть, что отсутствовал jar, я ранее поместил его в /WEB-INF/lib папку, но приложение его не увидело, поэтому мне пришлось поместить класс в /src/ папку и перекомпилировать. В любом случае это сработало.

У меня все еще возникают серьезные проблемы с другими элементами запутывания WAR, но это касается других вопросов.

-S