Re: [hibernate-dev] [jboss-dev] Solution for failing Isolated query cache tests in Hibernate trunk
Hmm, I think I may have dropped something in translation when I ported
this test from the JBoss AS/EJB3 testsuite.
These tests originate in AS tests that check whether the JBC 2nd level
cache integration handles cases where the "key" Hibernate passes as a
param to cache write operations uses custom types. That is:
1) The primary key for a cached entity is not a simple JDK type but a
custom type.
2) The params for a cached query involve custom types.
At least in the past, those keys were not serialized, they were the
unserialized objects. And since they are keys the Region impl can't
manipulate them in ways that may effect equals/hashcode, so it just
stores them directly in the cache. Doing that can cause problems on
remote nodes (remote node can't deserialize a replication message)
unless the Region impl has taken steps to ensure JBC/Infinispan knows
how to find the correct classloader to use.
That's what the original tests were meant to be testing. Looking briefly
at this one today though, it looks like my porting job messed up; the
custom type here is just an ordinary field in the entity (not the
primary key) and isn't used as a param in any cached queries.
On 01/14/2010 01:23 PM, Steve Ebersole wrote:
Also, you seem to have a quite elaborate functional test that simply
checks whether SerializationHelper is able to handle deserialing a class
from an "isolated classloader" via the SerializableType. Couldn't we
just have a simple unit test that asserted exactly that?
On Wed, 2010-01-13 at 20:25 +0100, Galder Zamarreno wrote:
>
> 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#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.
>
> 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.
>>
>>
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat