Notes on EJB3 Exceptions and headaches…
Not all exceptions you see during EJB3 development are exceptions from the javax.ejb package.
ClassNotFoundException: antlr.RecognitionException
JBoss uses ANTLR to parse EJB queries. Query language errors sometimes show up as antlr exceptions. If you fail to capitalize an Entity name, you may get this ClassNotFoundException wrapping the antlr.RecognitionException.
ClassNotFoundException: org.hibernate.type.AbstractComponentType
When you define a relationship with a FetchType.LAZY the server response to a client will include an AbstractComponentType, which is a class not included in the Jboss client jars. The solution to this is to initialize the relationship before sending the response to the client by calling the relevant getter method or by changing the relationship to an EAGER fetch type.
WARN Adding multiple last resources is disallowed. Current resource is…
This error is triggered when a method triggers multiple 1-phase commit transactions. The following is from the article Multiple1PC by Mark Little:
In these situations we recommend one of the following approaches:
- Wrap the resources in compensating transactions. See the Web Services transactions guides for further details.
- Migrate the legacy implementations to two-phase aware equivalents. For DataSources deployed on JBoss Application Server, this is as simple as changing from
to . See ConfigDataSources for more information. - Refactor the code to use separate transactions. If you simply need to read from one DataSource and insert processed results into another, you may not want or need 2-phase commit (and thus the above optimization). In an EJB3 session bean, this can be accomplished by simply delegating the read to a separate method and annotating it with @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW). This causes the calling method’s Transaction to suspend, wait for the read to complete, and resume.
Silent failure of persist when an entity has a @Lob property
While creating an entity, it is very easy to write a line of code like the following:
@Lob private Set<String> categorySet = new HashSet<String>();
An entity with this kind of mapping will compile and deploy perfectly. However, the persistence operation will fail without triggering any errors or exceptions–which can turn into a trouble-shooting headache. What happens in this case is that JBoss inspects the instance variable type (Set) to determine how to handle serialization and because Set is not a concrete class, the operation will fail. The problem will therefore be corrected with the following:
@Lob private HashSet<String> categorySet = new HashSet<String>();
So, if you use @Lob to map an entity property, avoid interfaces and abstract classes.
javax.ejb.EJBException: Could not passivate; failed to save state
This exception is triggered when JBoss cannot save the state of a Stateful session bean. The reason for this failure is usually a resource that cannot be serialized. In order to correct the problem, check your implementation of @PrePassivate and @PostActivate methods.
In order to determine which session bean is causing this exception (which is likely to reoccur every 5 minutes),
check the log and look for a temporary file name shortly before the first exception is thrown. In the following block the problem session bean is SetupServiceEJB:
2011-01-29 18:30:01,968 DEBUG [org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager] Saving session state to: I:\JBoss\jboss-4.2.3.GA\server\default\tmp\sessions\SetupServiceEJB-gjj7ey35-7\5c4o11z-8p8pqd-gjj7dnjt-1-gjj7fptf-8.ser
2011-01-29 18:30:02,531 FATAL [org.jboss.serial.persister.RegularObjectPersister] error
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor154.invoke(Unknown Source)
There will be several exceptions thrown before the javax.ejb.EJBException.
