WebSphere Class Loaders and Shared Library, Part 4 (Answer to case scenario + troubleshooting)

following part 3..

Answer to Case Scenario

After you understand the class loader in WebSphere Server environment, you will know the answer is not unique. There are many alternatives to achieve the goal.

Assumption:

Application Classloader Policy = Multiple

Application Classloader Mode = PARENT_LAST

War Classloader Policy = Module

War Classloader Mode = PARENT_LAST

Scenario1

This is one enterprise application (CoPortletEar) with two war modules (SourcePortlet.war and TargetPortlet.war). Both war modules will access CoJava.

 

Alternative 1:

Putting the CoJava.jar on the Application module level (CoPortletEar) will be one choice.

Steps:

1. Go to the CoPortletEar -> Properties -> J2EE Module Dependencies, check CoJava.jar


2. Go to SourcePortlet -> Properties -> J2EE Module Dependency -> J2EE Modules tab, check CoJava.jar.


3.      Repeat step 2 for TargetPortlet.

 

Alternative 2:

Using shared library and associate the shared library to CoPortlet.Ear.

Steps:

1.      Make sure that CoJava.jar is not selected in CoPortletEar’s J2EE Module Dependencies, and Cojava.jar is not selected in SourcePortlet (and TargetPortlet)’s J2EE Module Dependencies, either in J2EE Modules or in Web Libraries.

2.      After step 1, you may get compile error that “XXX can not be resolved”, to circumvent this, you reference the project CoJava in the Project Properties > Java Build Path, Required Projects. By doing this the project is not included in the .war files.

    

3.      Define shared library CoJavaLib in Admin Console





4.      Associated the shared library to CoPortlet.Ear:

Admin Console -> Applications -> Enterprise Applications-> CoPortletEar ->Libraries->Add CoJavaLib:



Alternative 3:

You can follow the alternative 1 in Scenario2 to put CoJava.jar under portal_server_root/shared/app. However, to keep application’s isolation as good as possible, it is not recommended here since CoJava .jar will be visible to all applications running in portal server if it resides in Portal Server Core Runtime, which is not necessary in this case as only CoPortlet.Ear requires CoJava.jar.

Scenario2

This is two enterprise applications which access the CoJava.

Alternative 1:

Putting CoJava.jar inside Portal Server Core Runtime which is portal_server_root/shared/app. In this case, restart Portal server is required.
Steps:

1.      Check the Step 1 and 2 in Scenario 1.

2.  Put CoJava.jar under portal_server_root/shared/app

3.      Restart Portal Server and run applications.

 

Troubleshooting

Java.lang.ClassCastException

This exception often occurs when two utility jar files are found in either Web Module or Application Module.

For example, in scenario1, if you associated CoJava to both SourcePortlet and TargetPortlet’s J2EE Module Dependencies -> Web Libraries, like:

 


in this case, the CoJava.jar is rendered as part of war file. The Server generates for each CoJava.jar different ID. So, when you try to cast an object to a class defined in CoJava, for example in TargetPortlet, the machine picks up the class resides in the TargetPortlet.war whose id is different than the one in SourcePortlet.war. Therefore, ClassCastException is thrown out.

The same with Scenario2, if you associate CoJava.jar to CoPortlet.Ear and Target.Ear either through J2EE Module Dependencies or through shared library. Two varied id is created for each CoJava.jar.

To resolve this problem, the best way is to let Web Modules or Application Modules refer to the same id of the utility jar file, like we have done in the previous section, to move the utility jar file one level upper. In the scenario 1, we put the CoJava.jar in the application level, in the scenario 2, we put the CoJava.jar in the Application extension level.

ClassNotFound Exception

One cause of ClassNotFound is when the request tries to find class which is in the child class loader. For example, WebSphere extensions class loader is requested to find a class in Application module class loader. So remember, requests can only go to a parent class loader; they cannot go to a child loader.

Resources:

Shared Libraries: WAS6 InfoCenter (Setting up the application serving environment->Administrating application servers-> Managing shared libraries)

Class Loaders: WAS6 InfoCenter (Developing and deploying applications->Class loading)

Classloading in WebSphere Portal: WebSphere Portal InfoCenter (Developing portlets->Portlet development basics->Creating a simple portlet)

Best Practice for Using Common Application Files

Learning more about the Classloader