Re: [jboss-dev] [hibernate-dev] Solution for failing Isolated query cache tests in Hibernate trunk
For completion, getReturnedClass().getClassLoader() will always
return
null because SerializableType is initialised with java.io.Serializable
as returned class, and it's classloader returns null (quite likely cos
it's a system class?).
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#getClassLoad...
null generally indicates the loader is the "boot loader".
The nullness itself is not an issue, the issue is the lack of
visibility.
So, getReturnedClass().getClassLoader() is not the answer here.
There is the only answer unfortunately. Really you'd want the Class of
the class implementing Serializable, but given how Hibernate's "type
system" works currently, that's not an option.
Steve, from a chat earlier you indicated that you're not happy passing
Thread.currentThread().getContextClassLoader() but I don't understand
what issue do you have with this.
The main issue is that this relies on:
1) when the call is made
2) the classloader layout of the environment in which the call occurs.
OSGI comes to mind in which case there is actually no tccl afaik.
Finally, it might be worth understanding what, apart from query
cache,
is Hibernate's SerializationHelper used for. If it's only for caching,
you could maybe delegate serialization work to the cache providers?
Thats really a
simple matter of a usage search in your IDE.
--
Steve Ebersole <steve(a)hibernate.org>
Hibernate.org