I ran into an unexpected problem the other day while working on a Java EE application. We deployed our entire application stack, which ran fine under GlassFish 2ur2, to GlassFish 3.1.2.2, using the compatibility=v2 property for deploying, as we're moving to GF3. After some testing, one of our features threw a TransactionRollbackException stating 'A system exception occurred during an invocation on an EJB'. I expected issues while migrating, but this one I hadn't seen before. The code is packaged in the following way:
server.ear
|-LIB1.jar (contains a persistence.xml)
|-EJB1.ejb
|-EJB2.ejb
|-EJB3.ejb
|-EJB4.ejb (contains a persistence.xml)
All 4 EJB's include LIB1. The call stack looks like this (simplified):
EJB1 -> EJB2 -> EJB3 -> DB
A search value is passed from EJB1 to EJB2 to EJB3 to be searched for in the DB. The return value is an Entity Bean (EB) which represents the data from the row in the DB. Digging into the code and debugging, I saw that the returned EB was not null and contained the proper data, right up to EJB2. Once the EB was returned to EJB1, the EB was not null, but was empty! All of the values in the fields were null. I was able to return other EB's, complete with their data in tact, using this same mechanism. So the problem had to do with this particular EB.
After doing some research, it looked like the problem might be EclipseLink's weaving feature, which performs byte-code manipulation to optimize the class. So I added the requisite eclipselink.weaving=false property to the persistence.xml. This, however, did not solve the problem. I then noticed that both persistence.xml files in this EAR defined separate Persistence Unit's (PU's), and both PU's referenced a handful of the same classes (including the one I was seeing the problem with). Aha!, a breadcrumb to chase. LIB1 contains utility classes as well as EB's which are shared among all of the EJB's. The EB's required in EJB1, EJB2, and EJB4 are all listed in LIB1's persistence.xml. EJB4 also already includes LIB1. So I removed the persistence.xml in EJB4...and problem solved.