[jboss-dev] [hibernate-dev] Solution for failing Isolated query cache tests in Hibernate trunk

[Brian Stansberry]

Looking again, the custom type is used in the test as a query param. The 
test would be better if it also used some sort custom type as the 
primary key.

On 01/14/2010 02:11 PM, Brian Stansberry wrote:
> 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#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.
>>>>
>>>>
>
>


-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat