[jboss-jira] [JBoss JIRA] Commented: (JBPM-1008) ejb deployment : avoid ClassNotFoundException on client side after unmarshalling

[Adrian Dimulescu (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBPM-1008?page=comments#action_12376044 ] 
            
Adrian Dimulescu commented on JBPM-1008:
----------------------------------------

I have tried to find an easy fix to this one and failed. Getting Hibernate out of an object tree is difficult. I think that the problem is inherent to a remote facade that exposes a rich domain model which is the case of the CommandServiceBean bean. 

When querying this service, you get rich domain object trees, with Hibernate lazy-loading behaviour as a plus. This is ok for local ejb interfaces; I think this is not ok for remote serialized facades. A remote facade should offer non-rich, plained-down information like, for example, long[] getNonFinishedTaskIds() and the like. Even if cleaning Hibernate-specific structures were possible, returning rich object trees would mean either initializing lazy links and returning half the database or returning semantically wrong null-values.

So I basically think the remote interface and the local interface should not be the same. 

I my case I offer as much functionality as possible using a web interface which uses the local ejb interface; for remote access, I offer a different remote facade that is independent jBPM and which uses the jBPM ejb in order to do its stuff. For direct access to the remote jBPM ejb, I stick to the constraints of including Hibernate among client dependencies and never dereferencing the lazy references. 

> 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.3
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira