Persistent sets are *too* persistent - make em go away...

timasmith · **Joined:** Thu Jun 15, 2006 5:31 am **Posts:** 21

Very frustrating indeed. It is really a problem that the domain object has to have their collection - a Set interface *replaced* with a org.hibernate.collection.PersistentSet.

Despite instantiating a new set and copying all the values over in a DTO fashion I still get the client spewing up:

java.lang.ClassNotFoundException: org.hibernate.collection.PersistentSet
at java.net.URLClassLoader$1.run(Unknown Source)

On serialization - I mean what do I have to do to get rid of them.

Of course I am trying to do this in via an interface, and it is running under JBoss so I cant debug - just flail around trying to deal with a persistent set.

POJO maybe, but there is nothing plain about replacing instance variables.

emmanuel · **Posted:** Sun Sep 17, 2006 10:28 pm

A DTO with a proper copy mechanism shouldn't raise a CNFE.

But what's wrong with passing the domain model and having hibernate.jar on the other side? You're calling JBoss AS so you have the JBoss client jar anyway

timasmith · **Joined:** Thu Jun 15, 2006 5:31 am **Posts:** 21

I have a domain model Set which has rich functionality and I lose it all it silently replaced by a org.hibernate.collection.PersistentSet - not to mention generate some nasty bugs.

You see my 'domain' object is also my Hibernate object - which is quite slick as I dont have to use an intermediate object to pass values from client to server.

I just have to figure out how to eject the Hibernate specific content that gets added to my POJO and I will be all set.

All 'set', thats funny.

emmanuel · **Posted:** Sun Sep 17, 2006 11:03 pm

There are very good reasons for us to replace the collection implementation. Not doing it would end up in even completly broken object reattachment rules.

And if you have some functionality that you loose, it means you are not following the collection interface contract you agreed to follow which is really nasty ;-)
If you want to mess around that, check UserCollectionType, you can also write your own colelction persister.

jerryc · **Joined:** Fri Jan 06, 2006 12:10 am **Posts:** 7

I had to deal with your problem as our client app was not allowed to have a dependency on hibernate (don't ask). What we ended up doing was something like this:

Code:

**
 * Subclass of the Hibernate PersistentSet which serializes to a java.util.HashSet.
 */
public class SafePersistentSet extends PersistentSet
        implements Serializable {

    public SafePersistentSet() {
    }

    public SafePersistentSet(SessionImplementor session) {
        super(session);
    }

    public SafePersistentSet(SessionImplementor session, Set set) {
        super(session, set);
    }

    @SuppressWarnings({"unchecked"})
    public Object writeReplace()
            throws java.io.ObjectStreamException {
        return new HashSet(this);
    }
}

and then implemented a UserCollectionType to use this set (which requires more code than I originally expected). Of course, you must do this for every collection type that you use. There may also be some nasty bugs with regard to lazy loading, as we load everything up front in this case.

As emmanuel says, there are some very good reasons that hibernate replaces the collection implementations. In my experience, the most signifacant benefit is that it allows hibernate to keep track of deletes. As soon as you do something such as this, that all becomes your problem. Certainly not impossible, but not quite as automatic as things usually are.

thiago.de.almeida · **Joined:** Mon Dec 04, 2006 12:06 pm **Posts:** 4

Hi,
would you be able to give me an example of this ?
I have the same problem and cannot get it over it.

Thank you,
Thiago

jerryc wrote:

I had to deal with your problem as our client app was not allowed to have a dependency on hibernate (don't ask). What we ended up doing was something like this:

Code:

**
 * Subclass of the Hibernate PersistentSet which serializes to a java.util.HashSet.
 */
public class SafePersistentSet extends PersistentSet
        implements Serializable {

    public SafePersistentSet() {
    }

    public SafePersistentSet(SessionImplementor session) {
        super(session);
    }

    public SafePersistentSet(SessionImplementor session, Set set) {
        super(session, set);
    }

    @SuppressWarnings({"unchecked"})
    public Object writeReplace()
            throws java.io.ObjectStreamException {
        return new HashSet(this);
    }
}

and then implemented a UserCollectionType to use this set (which requires more code than I originally expected). Of course, you must do this for every collection type that you use. There may also be some nasty bugs with regard to lazy loading, as we load everything up front in this case.

As emmanuel says, there are some very good reasons that hibernate replaces the collection implementations. In my experience, the most signifacant benefit is that it allows hibernate to keep track of deletes. As soon as you do something such as this, that all becomes your problem. Certainly not impossible, but not quite as automatic as things usually are.