[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-6880) Implementations of org.hibernate.type.Type contain references to non-serializable entities

[Steve Ebersole (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44835#comment-44835 ] 

Steve Ebersole commented on HHH-6880:
-------------------------------------

{quote}
Q: Do you have a test case actually showing this?
A: Not really, as the real world scenario involves two different hosts and fat layer of configuration (including caching). It is however quite evident if you look at the source code of o.h.t.ComponentType or the others I mentioned.
{quote}
That is not accurate.  Just look at the test I wrote for the linked HHH-6822

{quote}
We do not want to bind SessionFactory to JNDI and the option for avoiding this is only available in Hibernate v4. For most enterprises, upgrading such a major library to a .0 version is not really an option.
{quote}
Nor apparently did you even look at the linked HHH-6822 :)  You do not have to bind it to JNDI.

As for the others, I don't think they really require response.  Something is getting serialized that should not; plain and simple.  So the fix was to not serialize it, or to serialize it in the correct manner.

Again, try looking at HHH-6822

> Implementations of org.hibernate.type.Type contain references to non-serializable entities
> ------------------------------------------------------------------------------------------
>
>                 Key: HHH-6880
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6880
>             Project: Hibernate Core
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.6.7
>         Environment: Seen this on MySQL but I believe this is environment-agnostic
>            Reporter: Mindaugas Žakšauskas
>            Assignee: Steve Ebersole
>            Priority: Critical
>              Labels: serialization
>          Time Spent: 59m
>
> This is a spin-off from
> - https://forum.hibernate.org/viewtopic.php?f=1&t=1013687&sid=e62b8ea711e4986a6ff419e3e641e2e8
> - http://stackoverflow.com/q/8404559/7345
> org.hibernate.cache.CacheKey is an object which is used for L2 cache notifications - e.g. to flush a cache on a different cluster node when a certain object has been updated.
> The problem comes from org.hibernate.cache.CacheKey carrying the type which (sometimes) happens to have a reference to objects like org.hibernate.impl.SessionFactoryImpl.
> This problem is actually not just theoretic but also causes real pain. First, it takes much longer to broadcast cache flush events. Secondly, I get this exception during deserialization of such a CacheKey: 
> java.lang.NullPointerException
>  at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
>  at org.hibernate.impl.SessionFactoryObjectFactory.getNamedInstance(SessionFactoryObjectFactory.java:159)
>  at org.hibernate.impl.SessionFactoryImpl.readResolve(SessionFactoryImpl.java:753)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>  at java.lang.reflect.Method.invoke(Method.java:597)
>  at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
>  at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
>  at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>  at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>  at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>  at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>  at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>  at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>  at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>  at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>  at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>  at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
>  at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
>  at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
>  at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
>  at java.io.ObjectInputStream.readUnshared(ObjectInputStream.java:441)
>  at my.class.deserializeKey(EhcacheUtils.java:35)
> I have done a quick scan through all the types, and found these problems related to their serializability:
> 1) org.hibernate.type.CollectionType, org.hibernate.type.ComponentType and subclasses of both - they use attribute "typeScope" (of type TypeFactory.TypeScope) which is assigned in the constructor and kept in the but seems to be never used. The typeScope in turn has a reference to the SessionImpl. Can it simply be removed?
> 2) org.hibernate.type.EntityType (and its subclasses) stores typeScope and only uses it in the getter, so I guess it should be safe to remove it, too.
> 3) org.hibernate.type.SortedSetType and org.hibernate.type.SortedMapType keeps a reference to the comparator, but does not enforce its serializability. It should at least throw a runtime exception in org.hibernate.mapping.Collection::getComparator if the comparator is not serializable.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira