ClassCastExceptions due to upgrade to hibernate 4.2.8 in WebSphere 8.5.5 application container

Question

We recently upgraded hibernate from 4.0.1 to 4.2.8.Final.

Hibernate.4.2.8.Final is depending on javassist-3.18.1-GA. Unfortunately websphere is 8.5.5 is not shipped with latest javassist but it is not my issue. I tried to force websphere to take my javassist jar but I FAILED ( for some reason it is always loading from ${WAS_INSTALL_ROOT}/plugins).

What I tried?

• Classes loaded with local class loader first (parent last) in websphere console and WEB-INF/lib contains latest javassist jar. But application is not working
• Put latest javassit jar in ${WAS_INSTALL_ROOT}/lib/ext but no use
• Added shared library and referenced in application but no luck.
• If I replace javassist.jar in ${WAS_INSTALL_ROOT}/plugins then application started working but this is not good solution because other web applications might depend on old javassist

My question

How can I use (or inject or refer) latest javassist jar in Websphere 8.5.5?

This #blog helped me to figure our the problem little quickly.

Answer 1

This can be solved by adding the new version of javaassist as a shared library . The details are described here [http://www-01.ibm.com/support/docview.wss?uid=swg27006159#usingserver][1].

The shared library should be assigned against the a new class loader defined at the server configuration. The class loading policy should be PARENT_LAST for this class loader

Answer 2

We are using WAS 8.5.5 and Hibernate 4.3.5, and have faced the same issue. Adding Java Assist as shared library did work for us.

Note that the shared library has to be created with an isolated class loader

Answer 3

Here a little guide on how to update javassist in WAS. This was tested with WAS 8.0.0.1. The javassist.jar in WAS_HOME/plugins has to be replaced by the jar from: http://search.maven.org/remotecontent?filepath=org/javassist/javassist/3.18.1-GA/javassist-3.18.1-GA.jar Keep the old one as backup. Invoke WAS_HOME/profiles/PROFILE_NAME/bin/osgiCfgInit.sh and then WAS_HOME/profiles/PROFILE_NAME/bin/clearClassCache.sh or the *.bat files on windows machines.

Thanks to this post I found out how to do it: http://ramirezag.wordpress.com/2014/02/27/hibernate-4-2-8-and-websphere-8-5-5-1-issues/

Answer 4

when your app structure is fairly simple I think the experiment with the war (isolated / parent last classloader) might do the trick.In my case we package in full ear form snd we use skinny wars -meaning that the actually module that contains the jpa/ hibernate entities is a full blown ejb-jar and is packaged at the ear top level. I am not sure I can easily play around with the classloader if this module (not an websphere expert though)

My second problem is tha ideally I want all these exotic classloader policy setting to be performed during packaging with no after deploy admin action (meaning an admin to do some clickd in Websphere's panel). This file based way exist but its too complex and ugly iMho, i blame Websphere for that.

Answer 5

Solution to the problem is PARENT_LAST but I have changed in application settings page (Applications -> Application Types -> WebSphere enterprise applications -> *application_name* -> Class loading and update detection).

Unfortunately this is not correct place to put PARENT_LAST option. Because my application is web module (to be precise war file ;)) I would have put PARENT_LAST option in (Applications -> Application Types -> WebSphere enterprise applications -> *Application_Name*-> Manage Modules -> Module Name -> Class loader order). I don't know this option until I have seen jhadesdev comment and especially the link.

@jhadesdev Thanks once again. I have summarized everything HERE

Answer 6

Where did you put parent last, in which window of the console?

Because there are two places in the console where to put parent last, one at the application level, and the other at the WAR level and that is the one that you want to choose.

Put 'Class loader for each WAR file in application' and I believe from inside the screen where you chose that option, click the WAR and set the classloader policy at the WAR level to parent last:

I think the path is this (don't have a console now):

Application -- > Enterprise Application --> application_instance --> Web Module --> Web Module_instance

Have a look at this to see that are two places to set classloader policies, and let me know if you found the setting and if it worked, or a new error is thrown.

Sometimes when we switch the setting we find new errors because other jars where being read from the server and not the WAR, such as bean validation errors etc. If you get a different error non javassist related, it might be caused by that and you can always post it in a new question.

Answer 7

Change the WAR class loader policy to module.