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

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. > >