I heard back from Steve and he agrees that getting the ClassLoader from WrappedBlob.class.getClassLoader() should be fine.
To answer Scott: IIUC, HHH-8010 has to do with using a specified OsgiClassLoader to build a SessionFactory or EntityManagerFactory. Most usages of ClassLoaderHelper.getContextClassLoader() are in fact involved in building the SessionFactory or EntityManagerFactory. AFAICT, SerializableBlobProxy and SerializableClobProxy are not involved in the process of building a SessionFactory or EntityManagerFactory, so making the suggested change to generate proxies shouldn't impact HHH-8010. After Scott mentioned the message discussing this same problem with BlobProxy, I found that ClobProxy, NClobProxy, and ResultSetWrapperProxy also prefer ClassLoaderHelper.getContextClassLoader(). I'll make a similar change to their getProxyClassLoader() methods (using the appropriate interface). I've replied to the thread. I also noticed that ReflectHelper and SerializationHelper use ClassLoaderHelper.getContextClassLoader() and I am guessing there are some uses of these classes that would be susceptible to the same Spring bug. I'm not going to deal with these now though. Thanks all for the feedback! :) Gail ----- Original Message ----- > From: "Gail Badner" <gbad...@redhat.com> > To: "Scott Marlow" <smar...@redhat.com> > Cc: "hibernate-dev" <hibernate-dev@lists.jboss.org> > Sent: Tuesday, July 8, 2014 2:40:00 PM > Subject: Re: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob classloading > problem > > Hi Scott, > > I believe the classloading problem you mention is the same. Both > BlobProxy.getProxyClassLoader() and > SerializableBlobProxy.getProxyClassLoader() return > ClassLoaderHelper.getContextClassLoader() if non-null. > > Gail > > ----- Original Message ----- > > From: "Scott Marlow" <smar...@redhat.com> > > To: "Gail Badner" <gbad...@redhat.com>, "hibernate-dev" > > <hibernate-dev@lists.jboss.org> > > Sent: Tuesday, July 8, 2014 2:19:50 PM > > Subject: Re: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob > > classloading problem > > > > On 07/08/2014 05:04 PM, Scott Marlow wrote: > > > This sounds similar to https://community.jboss.org/message/879546 > > > > I was hoping to hear more feedback from the above link but didn't. I > > suspect that its a classloader issue with ear sub-deployments having > > Hibernate on their classpath but not the ear top level classloader. > > > > > > > > > > On 07/08/2014 03:53 PM, Gail Badner wrote: > > >> HHH-8310 [1] mentions a Spring bug SPR-11125 [2] that results in threads > > >> having a different ContextClassLoader (CCL) than their caller. As a > > >> result, SerializableBlobProxy.generateProxy() throws > > >> IllegalArgumentException because WrappedBlob is not found. The same > > >> happens for SerializableClobProxy.generateProxy() because WrappedClob is > > >> not found. > > >> > > >> IIUC, this will be fixed by accessing the ClassLoaderService in > > >> Hibernate > > >> 5. > > >> > > >> I'm looking for either a fix or workaround for this in Hibernate 4.2.x > > >> and > > >> 4.3.x. > > >> > > >> A) A possible fix for HHH-8310 suggests using the ClassLoader returned > > >> by > > >> WrappedBlob.class.getClassLoader(). Could this somehow get an unintended > > >> ClassLoader? > > > > Good question but this change might impact HHH-8010. Might be good to > > check with Brett on why OSGi needs to use an alternative classloader > > (which is set in ClassLoaderHelper). > > > > >> > > >> B) A workaround is for the caller to initialize > > >> ClassLoaderHelper.overridenClassLoader before calling Spring. > > > > I don't think this will work in a multiple deployment environment (e.g. > > WildFly) unless ClassLoaderHelper defaulted to the ORM classloader > > instead of an application level classloader. > > > > >> > > >> Which would be more appropriate? > > >> > > >> Thanks, > > >> Gail > > >> > > >> [1] https://hibernate.atlassian.net/browse/HHH-8310 > > >> [2] https://jira.spring.io/browse/SPR-11125 > > >> _______________________________________________ > > >> hibernate-dev mailing list > > >> hibernate-dev@lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> > > > > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev@lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
