i have a domain object, say Emploee, with a List of Children, everything works find in my web app world, but i have an applet that needs to get a copy of this domain object (serialized the object over HTTP and de-serialize in applet).. now my applet is getting ClassNotFoundExceptions.. looking for the sneaky classes that hibernate replaces in a List (xxx.xx.hibernate.List).. so it looks like my applet needs to include the boat load of hibernate classes required by hibernate, which sucks hugely.

is this correct?

thanks
G

it's not the nicest solution but I wonder what would happen if you used non-lazy collections.

hibernate
cglib
and commons logging is required AFFAIK
We planned to do a client jar version of Hibernate when we will have some time.

The hibernate requirement is mandatory because of the (so cool) dettach support

This is interesting (in this context). Could you point me to information about using Hibernate-persisted POJOs across detached media, i.e. SOAP or EJB exchanges? Do the POJOs have to be fully serialized or can lazy instantiation be exploited?

Thanks in advance,
Scott

Actually this is a long subject I can't really discuss on a forum. The objects are serialized and deserialized (the java way) so SOAP won't work.
In case of a proxied and uninitialized object (or collection), the proxy is passed and a LazyInitializationException will be thrown when you try to access it.
You can read the reference guide for some information or even better Hibernate In Action, all that stuff is very well explained.

Emmanuel, thanks for the primer, and I'm very much looking forward to reading about it in the book (would they print that thing already?! :-) )

I think I understand the issues around proxies and uninitialized objects, but I haven't seen a summary about how to best implement Hibernate when it's serving up data through EJBs or the increasingly popular SOAP protocol. I imagine that with EJBs, you could catch LazyInitializationException in the client and go back to retrieve a deeper graph, but with SOAP, you might never know that the POJO was incomplete.

Does this mean that it's impractical to use lazy instantiation over SOAP services? Do you know if the book covers this issue specifically?

Thanks in advance!
Scott

The book isnot printed yet but the electronic version is partially available in the Manning Early Access.
You could add a wrapper on top of your SOAP layer and suppose null value means uninitialized.

Be careful however, loading a unitialized part of a graph from a dettached object leads to break the data consistency... we no not recommand that (and did not write a wrapper on top of remote access.

Thanks again Emmanuel! I appreciate your point about the dettached objects and am shy about using nulls as an uninitialized indicator.

I think I'm beginning to lean towards using slimmed-down data transfer objects (only) in the SOAP service layer and above, or creating totally non-lazy Hibernate domain objects for the SOAP services to use. Sure, you don't get the (wonderful) benefits of laziness, but the complexity that laziness adds to dettached Hibernate objects seems to outweigh its benefits.

It should be underscored that this is not a Hibernate limitation - it is simply one of lazy instantiation vs. dettached object consumption. You still get to keep all the other goodies, like a pure object model, multiple levels of caching, etc.

Or am I wrong?

Scott

I think this is what other SOAP guys do.