HibernateMapper reports incorrect class

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

HibernateMapper reports incorrect class

Daniel Ferber
Hi,

The HibernateMapper.serializedClass reports the HibernateProxy's super class as the effective class that XStream should consider during serialization. This works well to hide the proxy for collections and most of the proxies of lazily initialized objects. However, I observed that this approach fails for a certain circumstance.

Suppose a class hierarchy mapped by hibernate and a pojo, to be serialized as xml, that declares a reference to the abstract object, but actually references an instantiable object. The issue arises when hibernate creates a proxy for this reference. In such situation, the HibernateProxy subclasses the abstract class, as it cannot know the real object type in advance. However, the initialization of the proxy will load the correct subclass. As the proxy cannot be replaced, it will still subclass the abstract class.

Therefore, HibernateMapper.serializedClass will report the abstract supper class as being the actual class of the object, and XStream will serialize the name of the abstract class in the "class" attribute. This misleads the de-serialization to instantiate the abstract class. However, HibernateProxyConverter will correctly serialize the attributes of the propert subclass. Only the "class" attribute contains the wrong class name.

A fix could be quite easy by changing HibernateMapper.serializedClass(). Instead of clazz.getSuperclass(), one may get the actual class by calling ((HibernateProxy)object).getHibernateLazyInitializer().getPersistentClass(). However, this would require Mapper.serializedClass() to receive the object instead of its type, changing its method signature. This would be reasonable if we consider that proxies might only be resolved by inspecting their state.

Best regards,
Daniel Felix Ferber


Reply | Threaded
Open this post in threaded view
|

Re: HibernateMapper reports incorrect class

Jörg Schaible-2
Hi Daniel,

first of all, I never did something real with Hibernate, any code in XStream
is contributed.

Daniel Ferber wrote:

> Hi,
>
> The HibernateMapper.serializedClass reports the HibernateProxy's super
> class as the effective class that XStream should consider during
> serialization. This works well to hide the proxy for collections and most
> of the proxies of lazily initialized objects. However, I observed that
> this approach fails for a certain circumstance.
>
> Suppose a class hierarchy mapped by hibernate and a pojo, to be serialized
> as xml, that declares a reference to the abstract object, but actually
> references an instantiable object. The issue arises when hibernate creates
> a proxy for this reference. In such situation, the HibernateProxy
> subclasses the abstract class, as it cannot know the real object type in
> advance. However, the initialization of the proxy will load the correct
> subclass. As the proxy cannot be replaced, it will still subclass the
> abstract class.
>
> Therefore, HibernateMapper.serializedClass will report the abstract supper
> class as being the actual class of the object, and XStream will serialize
> the name of the abstract class in the "class" attribute. This misleads the
> de-serialization to instantiate the abstract class. However,
> HibernateProxyConverter will correctly serialize the attributes of the
> propert subclass. Only the "class" attribute contains the wrong class
> name.

If you could enhance one of XStream's unit tests to demonstrate the problem,
it would help to find some kind of solution.

> A fix could be quite easy by changing HibernateMapper.serializedClass().
> Instead of clazz.getSuperclass(), one may get the actual class by calling
>
((HibernateProxy)object).getHibernateLazyInitializer().getPersistentClass().
> However, this would require Mapper.serializedClass() to receive the object
> instead of its type, changing its method signature. This would be
> reasonable if we consider that proxies might only be resolved by
> inspecting their state.

Well, this is actually not possible. It is by design that the Mapper
interface works with types and names, but never with the values (resp. the
real objects). A solution must be found within the converter code. Therefore
I'd like to have a working unit test.

Cheers,
Jörg



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email