HHH-8310  mentions a Spring bug SPR-11125  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?
B) A workaround is for the caller to initialize ClassLoaderHelper.overridenClassLoader before calling Spring.
Which would be more appropriate?
When I started refactoring the Search code towards free-form I simply
started to remove all references to Class and replace them with
TypeIdentifier, essentially working only on hibernate-search-engine
and closing the ORM integration modules which don't need to be
The SearchFactory interface however is meant as public API and exposes
Class in its signatures to identify specific entity types (I'll use
"entity" in its conceptual meaning): for example we have
void optimize(Class entityType);
Since not only Hibernate Search / ORM will be using Class &
annotations, I could split out the SearchFactory and its default
"class to index mapping" strategies into a separate module, or I could
just keep it there: public API but ignored in case of different
I think I'll leave it there for now, but early comments are welcome.
I'm trying to understand if the NoopOptimizer could drop the
"synchronized" at line 53.
I added the synchronization myself some months ago, when we discovered
that we could remove a level of synchronization which was more coarse
grained, but then when inspecting the safety of the various smaller
parts, when hitting the NoopOptimizer I wasn't too sure - as the
AccessCallback is pluggable - and opted to be safe rather than sorry
as I thought this Optimizer would not be used in a high-performance
It seems I was wrong an some people actually use this Optimizer in a
scenario needing high scalability, and this one also happens to be the
By looking at all AccessCallback implementors in the ORM codebase, it
looks like safe to remove the synchronization, but are there reliable
tests I could use to verify this?
There are some more optimisations that come to mind when looking into
the various Optimizer and Generator implementors, but I don't feel
comfortable into changing these without running some stress tests.