[#XSTR-226] support for Hibernate collections

XStream

support for Hibernate collections

Created: 14/Jun/05 07:00 AM Updated: 22/May/08 02:32 PM

Component/s:

None

Affects Version/s:

None

Fix Version/s:

1.1.3

File Attachments:

HibernateCollectionConverter.java (4 kB)
2.

HibernateCollectionsMapper.java (3 kB)

Issue Links:

Duplicate

This issue is duplicated by:

XSTR-377 Sanitizing hibernate proxied objects ( GetOutOfMyPojo)

Related

This issue is related to:

~~XSTR-423~~ CGLIBEnhancedConverter "only one CAllback is registered"

Description

« Hide

A converter/mapper for supporting hibernate collections.

All

Comments

Change History

Sort Order:

[ Permalink | « Hide ]

Costin Leau added a comment - 14/Jun/05 07:11 AM

converter

[ Permalink | « Hide ]

Costin Leau added a comment - 14/Jun/05 07:11 AM

mapper

[ Permalink | « Hide ]

Donald Ball added a comment - 29/Jul/05 10:49 AM

I found this more comprehensive solution only after I'd written my own. I'd love for this to be included in the main xstream distro, it's probably going to be a very common use case.

Question while I'm at it - anyone done any work on handling proxy classes decorated by cglib by hibernate? The simple solution would be to simply disable them, but lazy loading of fields is occasionally a big big win, so I'm reluctant to go down that road.

[ Permalink | « Hide ]

Costin Leau added a comment - 17/Aug/05 09:19 AM

I've seen your comment only now - I didn't had any watches placed on. I'm glad you like the solution.
I have done some work on decorated classes some time ago and I can donate some code if there is such a need. If you are in need of a quick fix make a mapper that removes the signature of CGLIB.

[ Permalink | « Hide ]

Costin Leau added a comment - 18/Aug/05 05:08 AM

After struggling with the HB api I stopped working on the tests. PersistentCollections & Co. are highly connected to HB API and to me it seems almost impossible (you have to create the whole internal HB hierarchy with dummy objects that in the end do not work).

[ Permalink | « Hide ]

Costin Leau added a comment - 18/Aug/05 05:11 AM

I've added a mapper for CGLIB enhanced classes: http://jira.codehaus.org/browse/XSTR-238

[ Permalink | « Hide ]

David Hay added a comment - 08/Sep/05 05:31 PM

Also see http://forum.hibernate.org/viewtopic.php?t=939007&highlight=xstream for apparent error in the code (have checked it myself).

[ Permalink | « Hide ]

Joerg Schaible added a comment - 11/Apr/06 07:47 PM

I just reopen the issue, since the HIbernate problem is not solved, but asked at a constant rate. So the issue will not get lost, even if the donated code might not solve any issue.

[ Permalink | « Hide ]

Hector U. Velez added a comment - 07/May/07 11:52 AM

The following line of code might be incorrect in the HibernateCollectionConverter

// the set is returned as a map by Hibernate (unclear why exactly)
if (source instanceof PersistentSet)

{ collection = new HashSet(((HashMap)collection).entrySet()); }

((HashMap)collection).entrySet() will return a set of Map.Entry and not the value which I think is what we want.

Maybe it should be something like:
if (source instanceof PersistentSet)
{
Set newSet = new HashSet();
Set mapEntrySet = ((HashMap) collection).entrySet();
for (Object o : mapEntrySet)

{ Map.Entry entry = (Map.Entry)o; newSet.add(entry.getValue()); }

}

[ Permalink | « Hide ]

Eric Raymond added a comment - 10/Aug/07 01:49 PM

Another approach here is to integrate functionality provided by beanlib to make this problem go away.

http://beanlib.sourceforge.net/

Hibernate3BeanReplicator().deepCopy() handles two issues with hibernate:

It de-proxies all the (lazy) objects
It replaces hibernate specific collection types with the Java built in versions.

Of course this deep copy is not very efficient if you do it in addition to XStream's traversal of the object. Ideally this would be handled internally as XStream is traversing.

[ Permalink | « Hide ]

Shahiduzzaman added a comment - 21/May/08 10:41 PM

Other than converting the Hibernate collection type as Java standard collection types, is there any other benefit of this converter (And why should one need to do that) ? If I'm not wrong, It does not facilitate serializing hibernate lazy loaded classes.