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

Question 1

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

Question 2

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.

Question 3

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

Question 4

Change the WAR class loader policy to module.

Question 5

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.

Question 6

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/

Question 7

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