Okay, this has me stumped. I have a webapp project in RAD running on websphere that uses a project reference to a lib project that contains all the model code including my hibernate logic. The Junit test of the lib directory works fine. A junit test in the webapp project, but running outside the J2EE container works fine. However, once we are running in the J2EE container, the same code crashes the JVM.
Note that not ALL code does this. An update works fine. However a quartz process dies on sessions.createQuery, and a web service call dies on createQuery. When I say ‘dies’ I mean the entire JVM shuts down and spews the following dump into the console:
Unhandled exception
Type=Unhandled trap vmState=0x00040000
J9Generic_Signal_Number=00000040 ExceptionCode=c00000fd ExceptionAddress=003A065D ContextFlags=0001007f
Handler1=0037A0C0 Handler2=003DC000
EDI=0037F178 ESI=26EDEB30 EAX=26EDEC00 EBX=00006030
ECX=33594900 EDX=33594900
EIP=003A065D ESP=2DB63000 EBP=002B2828 EFLAGS=00010206
GS=002B FS=0053 ES=002B DS=002B
Module=C:\Program Files (x86)\IBM\SDP\runtimes\base_v7\java\jre\bin\j9vm24.dll
Module_base_address=00370000 Offset_in_DLL=0003065d
Target=2_40_20110216_075791 (Windows 7 6.1 build 7601 Service Pack 1)
CPU=x86 (4 logical CPUs) (0x1f890f000 RAM)
----------- Stack Backtrace -----------
The queries appear to be correct (as I said, they work outside the j2ee container). If it helps, here is one of them:
Query sql = s.createQuery("from Type t where t.typeCode=? and t.applicationCode=? ");
We’ve never seen this before, and aren’t getting alot of Goggle traction. We’re on Windows 7, RAD 8, WAS 7.0.0.17, Hibernate 4.1.9, DB2 XA data source, and not that I think it matters, but we’ve conigured org.springframework.orm.hibernate4.HibernateTransactionManager as our transaction manager.
Any ideas?
Resolved. Here’s the deal – this would only happen in debug mode. In Run mode, we actually got a NoClassDefError on an antlr class. We had failed to move antler into web-inf/lib, but it WAS in the lib project’s dependencies which is why Junit ran. Once copied over this issue went away. I guess antlr is a dependency of Hibernate.
The great mystery here is why the debugger melted the JVM instead of giving an exception that would give us a chance to resolve the issue, but we are past our problem.