JBossDeveloper

I stumbled into the same problem. ClassCastException with SerializableProxy being assigned to a lazily fetched OneToMany relationship in my entity bean. I'm not a hibernate code expert, but it seems to me since all my beans implement java.io.Serializable, and SerializableProxy also implements this, that there should not be a ClassCastException (unless there is some serious CGLib hacking going on). I am using isolated classloading with the jbossall-client.jar to pull stateful session bean and execute a method that pulls an entity beans with OneToMany mappings. Is this a problem with the EJB3 container? or with the client jars?


Caused by: java.lang.ClassCastException: cannot assign instance of org.hibernate.proxy.SerializableProxy to field com.ed.data.AdOrg.adClient of type com.ed.data.AdClient in instance of com.ed.data.AdOrg
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:65)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
at org.jboss.ejb3.stateful.StatefulRemoteProxy.invoke(StatefulRemoteProxy.java:133)
at $Proxy1.getResultList(Unknown Source)
at com.ed.tests.ClientTest.(ClientTest.java:43)
at com.ed.tests.ClientTest.main(ClientTest.java:60)

In my test case, I tried to make the simplest possible scenario with no inheritance: just two simple entities in a OneToMany relationship. The problem actually seems to occur on the ManyToOne side though. Also a problem on OneToOne.

Hello,

I've got a similar problem:
some attributes defined as LAZY causes a SerializationException and later on a ClassCastException when serialized to the client.
When I configure them as EAGER it works, but a SerializaionException is thrown on bean passivation.

The configuration of the attributes is
@ManyToOne(optional=true,fetch = FetchType.LAZY, cascade = CascadeType.REFRESH)
or
@ManyToOne(optional=false,fetch = FetchType.LAZY, cascade = CascadeType.REFRESH)

I use JBoss 4.0.4RC1 including ejb3, using the installer.

I have seen that there are different hibernate-libraries in server\\lib and server\\deploy\ejb3.deployer with different size. I've deleted the libraries in deploy\ejb3.deployer, on client side I use the librarires in the lib directory. It didn't change anything, the errror is still there.

My client testclass (JUnit called in Eclipse) calls a StatefulSessionBean BeanA that calls a StatefulSessionBean BeanB, BeanB creates the hibernate object and reads the data.

When I use only one StatefulSessionBean it seems to work (very confusing), but our apllication architecture uses 2 SessionBeans and we can't change this in a foreseeable timeframe.

Any idea ?

Annegret

The Stacktrace is

 java.lang.reflect.UndeclaredThrowableException
 at $Proxy519.readData(Unknown Source)
 at com.tenovis.oam.acm.as.versionsb.SubscriberTestASBBean.readData(SubscriberTestASBBean.java:54)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:109)
 at org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor.invoke(ExtendedPersistenceContextPropagationInterceptor.java:57)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
 at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
 at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
 at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:192)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
 at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
 at org.jboss.ejb3.stateful.StatefulInstanceInterceptor.invoke(StatefulInstanceInterceptor.java:81)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
 at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
 at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
 at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
 at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:294)
 at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:107)
 at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
 at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:660)
 at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:513)
 at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:290)
 at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:344)
 at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:202)
 Caused by: org.jboss.serial.exception.SerializationException
 at org.jboss.serial.persister.PrivateWritePersister.writeData(PrivateWritePersister.java:83)
 at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:117)
 at org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:260)
 at org.jboss.serial.io.JBossObjectOutputStream.writeObjectOverride(JBossObjectOutputStream.java:111)
 at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:287)
 at org.jboss.serial.io.MarshalledObject.<init>(MarshalledObject.java:51)
 at org.jboss.ejb3.SessionContainer.marshallResponse(SessionContainer.java:211)
 at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:308)
 at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:55)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
 at org.jboss.ejb3.stateful.StatefulRemoteProxy.invoke(StatefulRemoteProxy.java:133)
 ... 32 more
 Caused by: java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.serial.persister.PrivateWritePersister.writeData(PrivateWritePersister.java:73)
 ... 42 more
 Caused by: java.lang.ClassCastException: [Ljava.lang.Class;
 at org.jboss.serial.persister.ClassReferencePersister.writeData(ClassReferencePersister.java:42)
 at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:117)
 at org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:260)
 at org.jboss.serial.persister.RegularObjectPersister.defaultWrite(RegularObjectPersister.java:81)
 at org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:46)
 at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:117)
 at org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:260)
 at org.jboss.serial.persister.RegularObjectPersister.defaultWrite(RegularObjectPersister.java:81)
 at org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:46)
 at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:117)
 at org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:260)
 at org.jboss.serial.persister.RegularObjectPersister.defaultWrite(RegularObjectPersister.java:81)
 at org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:46)
 at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:117)
 at org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:260)
 at org.jboss.serial.persister.ObjectOutputStreamProxy.writeObjectOverride(ObjectOutputStreamProxy.java:45)
 at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:287)
 at java.util.ArrayList.writeObject(ArrayList.java:570)
 ... 47 more

Let me state the differences:

There are two bugs related to Lazy Attributes.

One is regarding JBossSerialization which was failing during Hibernate Proxy serialization, which is solved. To solve that you simply need to replace jboss-serialization.jar by the version available at jboss-serialization/download page. (it looks this is your problem)

Another one is related to inheritance. Something related to ClassCastException, and I think this one is replicated and hibernate team still working on that one.

As for the ClassCastException -- this is a "Blocker" bug for me (JIRA talk). How are others working around this issue?

This bug fixed or not?
Thanx.

I just wanted to ask as to the intended behavior if this bug were to be fixed. From what I understand from the EJB3 specs.. if an entity bean becomes serialized, it becomes detached and there is no responsibility for the container to ensure any binding after that. I am assuming with the SerializableProxy, that the hibernate team is attempting to allow the bean to remain live even though it is remote (ie, lazily fetching associations remotely through the proxy). Is this the goal here? Is this what is expected as per the spec? I can understand it would be a nice feature to have, but I guess I'm just looking for clarification on this as it seems that this is an unecessary bug to have to deal with.

Thanks for Carlo de Wolf, EJBTHREE-440 is now fixed.

http://jira.jboss.com/jira/browse/EJBTHREE-440

But if you had a failing scnearion on this, I guess it would be a good idea if you could test it from CVS@Head.