6

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.

Angular University
  • 42,341
  • 15
  • 74
  • 81
  • Using local classloader first (parent last) with one classloader per WAR seems the best approach. What was the error that the application was giving with parent last, was it related to Javassist? – Angular University Jan 03 '14 at 23:16
  • Yes same error I was getting either (parent last) or first. Also I have latest javassist (3.18.1) jar exist in WEB-INF/lib – Seeta Ramayya Vadali Jan 04 '14 at 12:54

7 Answers7

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.

Angular University
  • 42,341
  • 15
  • 74
  • 81
  • Thanks for the detailed explanation and link you have given to me. But in the link they mentioned `By specifying PARENT_LAST, your application can override classes contained in the parent classloader, but this action can potentially result in ClassCastException or LinkageErrors if you have mixed use of overriden classes and non-overriden classes` how to figure it out which classes are used in mix mode? – Seeta Ramayya Vadali Jan 06 '14 at 11:03
  • Wow I fixed the problem... your post especially the link you have given me put me in correct direction to solve the problem. – Seeta Ramayya Vadali Jan 06 '14 at 12:21
  • Try to start it maybe there are no errors. There are ways to query the classpath with getClass().getClassLoader().getResource() /getResources(), see tmy answer on this post http://stackoverflow.com/questions/20909446/caused-by-java-lang-noclassdeffounderror-org-apache-log4j-logger/20911191#20911191 – Angular University Jan 06 '14 at 12:23
  • I am glad I could help, please consider marking it as accepted in case you found it useful to tackle these problems in general. There's a tool JHades http://jhades.org/ I wrote to help with these problems, (works under Java 7), it helps on server startup problems as well, regards – Angular University Jan 06 '14 at 12:35
  • JHades tool is interesting. I'll try to use it when ever I have problem with app server classpaths. – Seeta Ramayya Vadali Jan 06 '14 at 14:56
2

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

0

Change the WAR class loader policy to module.

  • ,If you are taking about WAR class loader policy then I tried both of the following `Class loader for each WAR file in application` `Single class loader for application` – Seeta Ramayya Vadali Jan 04 '14 at 15:40
  • after reading jhadesdev comment and especially [link](http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzatz/51/program/clsadmcns.htm) I understood what you were saying but little unfortunate your statement was too generic. So couldn't figure it out. – Seeta Ramayya Vadali Jan 06 '14 at 12:23
0

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

0

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.

javapapo
  • 1,342
  • 14
  • 26
0

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/

Christian Beikov
  • 15,141
  • 2
  • 32
  • 58
0

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

Debanga
  • 1
  • 1