Hibernate version: 2.1.6

The following line in net.sf.hibernate.connection.ConnectionProviderFactory throws a ClassCastException when I run my applications within WebSphere:

(ConnectionProvider) ReflectHelper.classForName(providerClass).newInstance();

I have found the cause of the problem, but I don't know how to solve it. The problem is caused by different classloaders loading ConnectionProvider and my class that implements ConnectionProvider. To prevent this problem, wouldn't it be safer to write:

(ConnectionProvider) ConnectionProvider.class.getClassLoader().loadClass(providerClass).newInstance();

This code would guarantee that a ClassCastException would never happen due to different classloaders. But it would circumvent using the current thread's context classloader to load the class if ConnectionProvider was not loaded by the current thread's context classloader.

What are the disadvantages of this approach? Why do we need to use the current thread's context classloader to load our class? If it is important to use the current thread's context classloader, shouldn't Hibernate be written to load ConnectionProvider using the current thread's context classloader (or one of its parents)?

This ClassCastException disappeared when we applied IBM's JDK fix pack for WebSphere 5.0.2.x

one should always look in the current thread context classloader to integrate nicely with containers and other classloading dependent frameworks.