views:

153

answers:

2

I lack understanding of how does the generated proxy class object (CGLib enhanced POJO) is transferred to the remote client and still retains its ability to generate Lazy Init. Exceptions.

Does that mean that there is some kind of contract that all the transferred objects of some kind of class (a proxy) will be reinstantiated as proxies again? Where does the client obtain those generated classes? Sorry, but I totally do not understand.

A: 

The proxies are uninitialized. When they are transferred, they loose the Session they were originally associated with. So when an attempt is made to initialize them on the remote side, it logically fails.

You can initialize them fully before sending them, using Hibernate.initialize(aProxy)

For more information check this answer.

Bozho
yes, the proxies are empty. But how the java runtime knows for example the class name/version of the proxy? For what reason the aspects are still valid on the client side? Is that some kind of remote code??
Bubba88
A: 

Because your remote client application now has a dependency on Hibernate. If your remote client doesn't have Hibernate on the classpath you'll get a NoClassDefFoundError. This demonstrates how leaky the abstraction is with Hibernate.

Basically, don't pass objects across the network - pass messages (which can then be used to create objects, if you so wish).

hbunny
I have no problem with using Hibernate abstraction or anyother issues. I just wanted to understand how is hibernate able to persist that AOP-ish behaviour on the client side. I've read about that `readResolve()` and `writeReplace()` methods usage in Hibernate. But I can't still imagine how the transferred (aka "original" via writeReplace()) entity is ressurected as newly generated CGLib Proxy (via ReadResolve()) - that's basically an issue, cause how can Hibernate (client-side) synchronize the classgeneration not to duplicate proxy classes. Maybe my knowledge of java reflection is too weak..
Bubba88