ejb deployment : avoid ClassNotFoundException on client side after unmarshalling --------------------------------------------------------------------------------- Key: JBPM-1008 URL: http://jira.jboss.com/jira/browse/JBPM-1008 Project: JBoss jBPM Issue Type: Bug Affects Versions: jBPM jPDL 3.2.1 Environment: enterprise jBPM Reporter: Adrian Dimulescu Assigned To: Tom Baeyens Fix For: jBPM jPDL 3.2.4 Two aspects in this jira : 1: hide hibernate-specific exceptions; 2: hide hibernate-specific datatypes. 1. The EJB client only depends on the jBPM jar (for the various Command implementations) and on the JBoss client jar. If a Hibernate exception occurs, it is wrapped by a JBPMException and rethrown. When deserialiezed on the client side (which does not have a Hibernate dependency), a ClassNotFoundException occurs. I think the CommandServiceBean should not wrap internal implementation-specific exceptions; it should instead simply copy the stack trace and throw a new implementation-independent exception which contains the exception trace without containing the causes themselves. That typically avoids ClassNotFoundExceptions without losing exception history. 2. The second problem is that hibernate-specific collections get serialized over the wire, here is the description of the problem : I use the GetProcessInstancesCommand in order to experiment with querying the remote ejb. This command returns a list with ProcessInstances. A ProcessInstance is read by Hibernate from the database. As Hibernate uses specific lazy-loading-aware implementations for collections -- the ProcessInstance.instances attribute, which is declared of type java.util.Map, is actually implemented by org.hibernate.collections.PersistentMap. Which generates class loading exception while deserializing to hibernate-unaware ejb clients. The solution would then be for the Command implementations to return clean JDK collections, by replacing Hibernate collection with JDK standard ones. Note that IIUC only the collections must be replaced, not the collection contents too, so the "cleaning" operation should not be that expensive. Cleaning should be only done in the SLSB remote call use case -- because in-JVM callers may want to benefit lazy-loading.