5:09 p.m.
[ http://jira.jboss.com/jira/browse/JBPM-1008?page=comments#action_12407421 ]
JeanDenis Bertron commented on JBPM-1008:
-----------------------------------------
I don't think Hibernate's lazy loading is an advantage at all. Sure there is the
performance/resource issue. Maybe I don't understand the idea but I though lazy
loading implied some kind of transparency from the point of view of the client. But I have
yet to see how I can use the objects that were incompletely loaded by the lazy mechanism
without having to call hibernate.initialize() repeatedly.
For instance, if you want to navigate from a node to its tasks to the controllers and
their variables you have to call Hibernate.initialize on every single one. It's the
opposite of transparency and the code would be better off with a true API as in :
context.getTasksForNode(..)
context.getControllersforTask()
context.getVariablesForController().
As for the Hibernate collections I agree with Adrian above. And it's a shame the
client has to include Hibernate as a dependency without being able to use them.
Even then, the functionality is severely restricted because you can't navigate the
object tree properly for fear of causing a hibernate aneurysm.
For instance, why can't Node.getTasks() handle the work of figuring out if the data
is there and do the work to get it appropriately ? I mean, when the node was built, the
remote interface or local context is available, and could be used again either to tell
Hibernate to fetch the stuff or to manufacture a Command for the remote interface.
J.D.
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