I have an EJB with a method that returns a list of hibernate-persisted objects. These objects each have a Set relationship to a different entity.

My EJB fetches them with: from Motd m left join fetch m.shards

When calling this method remotely, I get an exception because the client can't load net.sf.hibernate.collection.Set.

I thought I remember reading something somewhere about Hibernate automatically converting all hibernate-specific collections into their standard implementations during serialization, but I can't find any reference to it now. Is this supposed to happen? Is there a way I can make this happen?

What is the best way of purging all the hibernate persistant collections before I pass an object back through a remote call? I don't have to replace every Set with a HashSet by hand, do I?

I'm using 2.1b6.

Thanks,
Jeff

No, this is not supposed to happen. The collection wrapper carries a snapshot around with it. This makes update() much more efficient.

Why dont you just include hibernate.jar in the classpath of you client? I never had any problems working with the hibernate collections on a remote client.

Hi,
Gavin, can you clarify what you mean by "No, that's not supposed to happen"? Do you mean the serialization should use some non-hibernate collection snapshot it carries inside, or do you mean that serialization will just put the hibernate collection in?

Thanks,

Derek

My clients are a variety of different departments within a large organization. If I include hibernate implementation classes in my remote interfaces, I would not be able to update my hibernate version without forcing all my clients to change. Hibernate is part of my implementation, it shouldn't be part of my interface.



That snapshot can't possibly be useful after serialization, can it? If I serialize an entity and send it across a wire, it's pretty effectively cut off from the session... why not strip out any hibernate implementation classes?

What would be the problem if the hibernate collection classes implemented writeObject() to write out their "normal" jdk-collection implementations (ie HashSet)?

Maybe this conversation should be moved to hibernate-devel.

I agree. I think it would be very useful to be able to extract a POJO from the mapped object.

Derek

It's also worth pointing out that this would eliminate the possibility that someone could make this guy's mistake:

http://forum.hibernate.org/viewtopic.ph ... =serialize

Is there any change on the status of this?

I've taken ownership of a service that uses Hibernate at its core and communicates over RMI. While this does neutralize a lot of the power of Hibernate, as far as I'm concerned, it does keep some level of database independence which is valuable.

Because the previous version of this service used pretty fine-grained method calls, none of the objects contained therein had Hibernate collections within them, and this problem didn't come up. But I'm loath to require every service above this service to have a copy of hibernate.jar and odmg.jar, not to mention the client applications that make use of these services.

The ability to configure Hibernate to serialize/deserialize into regular collections would be of great interest to me.