[hibernate-dev] Solution for failing Isolated query cache tests in Hibernate trunk
Galder Zamarreno
galder at jboss.org
Wed Jan 13 14:25:13 EST 2010
On 01/13/2010 07:10 PM, Steve Ebersole wrote:
>> 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#getClassLoader%28%29
>
> 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.
If it's not an option, why don't u throw an error or exception?
>
>>
>> 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.
>
>
More information about the hibernate-dev
mailing list