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

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