2013-06-25 4 views
0
15:31:58,339 TRACE Grizzly(1) org.hibernate.engine.jdbc.internal.JdbcResourceRegistryImpl:211 - Closing prepared statement [[email protected]: select producttyp0_.id as id5_, producttyp0_.name as name5_ from production_queue.Product_Type producttyp0_ where producttyp0_.name='Phone Case'] 
15:31:58,339 TRACE Grizzly(1) org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler:88 - Handling invocation of statement method [invalidate] 
15:31:58,339 TRACE Grizzly(1) org.hibernate.engine.jdbc.internal.LogicalConnectionImpl:234 - Starting after statement execution processing [ON_CLOSE] 
15:31:58,339 TRACE Grizzly(1) org.hibernate.engine.internal.StatefulPersistenceContext:1016 - Initializing non-lazy collections 
15:31:58,339 TRACE Grizzly(1) org.hibernate.internal.SessionImpl:1383 - Setting cache mode to: NORMAL 
15:31:58,339 TRACE Grizzly(1) org.hibernate.internal.SessionImpl:340 - Closing session 
15:31:58,340 TRACE Grizzly(1) org.hibernate.engine.jdbc.internal.LogicalConnectionImpl:193 - Closing logical connection 
15:31:58,340 TRACE Grizzly(1) org.hibernate.engine.jdbc.internal.proxy.ConnectionProxyHandler:110 - Handling invocation of connection method [close] 
15:31:58,340 TRACE Grizzly(1) org.hibernate.engine.jdbc.internal.proxy.ConnectionProxyHandler:206 - Invalidating connection handle 
15:31:58,340 TRACE Grizzly(1) org.hibernate.engine.jdbc.internal.JdbcResourceRegistryImpl:205 - Closing JDBC container [[email protected]b620] 
15:31:58,340 DEBUG Grizzly(1) org.hibernate.engine.jdbc.internal.LogicalConnectionImpl:314 - Releasing JDBC connection 
15:31:58,341 DEBUG Grizzly(1) org.hibernate.engine.jdbc.internal.LogicalConnectionImpl:332 - Released JDBC connection 
15:31:58,341 DEBUG Grizzly(1) org.hibernate.engine.jdbc.internal.proxy.ConnectionProxyHandler:219 - HHH000163: Logical connection releasing its physical connection 
15:31:58,341 TRACE Grizzly(1) org.hibernate.engine.jdbc.internal.LogicalConnectionImpl:207 - Logical connection closed 
WARNING: Exception during FilterChain execution 
WARNING: service exception 

Несмотря на то, что настроен log4j.rootCategory=TRACE, stdout, он, похоже, не помогает мне получить более подробную информацию об этом исключении.Как получить трассировку стека для этого исключения?

log4j.properties

log4j.rootCategory=TRACE, stdout 

log4j.appender.stdout=org.apache.log4j.ConsoleAppender 
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout 
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %t %c:%L - %m%n 
+0

Показать свой файл log4j.properties или log4.xml. – anubhava

+0

Пожалуйста, укажите лучший заголовок. – Raedwald

+0

@ Raedwald - Хороший звонок, спасибо! Я хотел вернуться и улучшить этот титул, но так и не добрался до него. – Webnet

ответ

0

Регистратор выглядит правильно настроен, но это не означает, что проблемный код вызывает его правильно. Если регистратор просто называется LOG.warn(e), он будет регистрировать только сообщение об исключении, а не полную трассировку стека.

Думая об этом, тем не менее, странно, что временная метка и файл класса отсутствуют в журнале. Вы уверены, что Grizzly использует Log4J и не выполняет свою собственную регистрацию через систему ведения общедоступных записей или ведение журнала Java Util?

+0

Ох, ты прав. Я отключил их! Я совсем забыл об этом. Duh! – Webnet