Enabling class loader viewer service

Starting with version 6.0.2, WAS introduced a new utility called the Class Loader Viewer. When activated, this utility can help you diagnose class loading problems by showing you the different class loaders involved, their settings, and the classes loaded by each of them. By default the Class Loader Viewer Service is not enabled, the Class Loader Viewer only displays the hierarchy of class loaders and their classpaths, but not the classes actually loaded by each of the class loaders. This also means that the search capability of the Class Loader Viewer is lost

You can enable the Class Loader Viewer utility using WAS Admin Console by going to the server details page of the server for which you want to enable the service. On that page click on Class Loader Viewer Service link



The Class Loader Viewer Service page has only one checkbox "Enable Service at server startup", check that check box. Save your changes and restart that server.

Application and Web Module class loader

EJB Modules, Utility JARS, resource adapter files and shared libraries associated with an application are alwasy grouped together into the same class loader. THis class loader is called as Application class loader. By default each .ear file gets its own class loader but if you want to use same class loader for all the enterprise applications in your server then you do that by setting valuse of classloader policy to Multiple on the server detail page




Each Web Module i.e. .war file receives their own class loader, a WAR classloader to load the contents of WEB-INF/classes and WEB-INF/lib directories. You can modify this so that single classloader i.e. class loader of the enterprise application is used for loading all the web modules in that enterprise application. You can change that on WAS Admin Console by selecting the Enterprise application that you want to change and clicking on its class loader link.



The application class loader is the parent of Web Module class loader. So web module can access EJB or utility classes but EJB cannot access your servlet

Restricting access to websphere non public API

WebSphere Application Server V6.1 gives you the ability to restrict access to internal WebSphere classes so that your applications do not make unsupported calls to WebSphere classes not published in the official WebSphere Application Server API. This setting is a per-server (JVM) setting called Access to internal server classes

You can change this setting from WAS Admin Console, on server details page like this




The default setting is Allow, meaning that your applications can make unrestricted calls to non-public internal WebSphere classes. This is not recommended and may be prohibited in future releases. Therefore, as an administrator, it is a good idea to switch this setting to Restrict to see if your applications still work. If they depend on non-public WebSphere internal classes you will receive a ClassNotFoundException, and in that case you can switch back to Allow. Your developers should then try to migrate their applications so that they do not make unsupported calls to the WebSphere internal classes in order to retain compatibility with future WebSphere Application Server releases

WebSphere Extension class loader

WebSphere Provides serveral custom delegated class loader as shown



The top part is Java Class loader, which is Java class loader. WebSphere loads just enough to get itself bootstrapped and initialize WebSphere extension class loader.

The WebSphere extensions class loader is where WebSphere itself is loaded. In previous versions of WebSphere, the run time was loaded by this single class loader. However, beginning with WebSphere Application Server V6.1, WebSphere is now packaged as a set of OSGi bundles. Each OSGi bundle is loaded separately by its own class loader. This network of OSGi class loaders is then connected to the extensions class loader and the rest of the class loader hierarchy through an OSGi gateway class loader

In previous versions of WebSphere Application Server the WebSphere run time classes files were stored in the classes, lib, lib\ext, and installedChannels directories in the <was_home> directory. Because of the OSGi packaging, these directories no longer exist and the run time classes are now stored in the <was_home>\plugins directory.



Despite this architectural change in the internals of how WebSphere loads its own classes, there is no behavioral change as far as your applications are concerned. They still have the same visibility, and the same class loading options still exist for your application.

On the other hand, if you have developed Java applications that rely on the WebSphere JAR files that were previously in the <was_home>\lib directory, you will need to modify your application to retain compatibility. WebSphere Application Server V6.1 provides two thin client libraries designed specifically for such applications: one administrative client library and one Web services client library. These thin client libraries can be found in the <was_home>\runtimes directory:

• com.ibm.ws.admin.client_6.1.0.jar


• com.ibm.ws.webservices.thinclient_6.1.0.jar

These libraries provide everything your application might need for connecting to and working with WebSphere

The class path used by the extensions class loader is retrieved from the ws.ext.dirs system property, which is initially derived from the WAS_EXT_DIRS environment variable set in the setupCmdLine script file.

Java Class Loader

When you start a JVM, you use three class loaders: the bootstrap class loader, the extensions class loader, and the application class loader.

1. The bootstrap class loader is responsible for loading only the core Java libraries, that is vm.jar, core.jar, and so on, in the <JAVA_HOME>/jre/lib directory. This class loader, which is part of the core JVM, is written in native code.


2. The extensions class loader is responsible for loading the code in the extensions directories (<JAVA_HOME>/jre/lib/ext or any other directory specified by the java.ext.dirs system property). This class loader is implemented by the sun.misc.Launcher$ExtClassLoader class.


3.  The application class loader is responsible for loading the code that is found on java.class.path, which ultimately maps to the system CLASSPATH variable. This class loader is implemented by the sun.misc.Launcher$AppClassLoader class.

The parent-delegation model is a key concept to understand when dealing with class loaders. It states that a class loader delegates class loading to its parent before trying to load the class itself. The parent class loader can be either another custom class loader or the bootstrap class loader. But what is very important is that a class loader can only delegate requests to its parent class loader, never to its child class loaders

Application Level shared lib

The Application Level Shared Lib allows you to attach shared lib to particular enterprise application or .war file inside enterprise application. Follow these steps

• Create testsharedlib shared library by following the steps defined in Create Shared Lib section


• In the WAS Admin Console, Go to Application -> Enterprise Applications, select the application that you want to attach this shared lib to. I want to attach it to PA_SharedLib enterprise application. So its detail screen looks like this
  
  


• Click on Shared Library references link in the References section, it will display list of shared library referenced from both .ear and the .war file inside the .ear
  
  


• I want to attach the shared lib to the SharedLibPortlet, so select it and click on Reference Shared Libraries button
  
  
  


• It is displaying list of available shared libraries on the left hand side, select the testsharedlib and add it to selected section.
  
  


• When you click on Ok it will take you to the previous screen and now you will be able to see the testsharedlib being attached to SharedLibPortlet
  
  
  

After making this change i tested my enterprise application and it was able to access the classes defined in the shared lib. If that does not work try restarting the enterprise application

Shared Library

Shared libraries allow you to attach set of .jar files to application or server. Ex. Most of the portlets in your company are using JSF as MVC framework or say set of Apache Axis jars so instead of copying all the .jar files required by portlets in the WEB-INF/lib folder of every portlet you can create a directory on your server copy all the required jars in that directory and add that directory to the classpath of either your server or your portlet application.

Creating a shared library

You can create a shared library by following these steps

• Create c:\temp\shared directory on your machine and copy all the .jar files in this directory


• Log into the WAS Admin console and go to Environment -> Shared Libraries. Choose the appropriate scope and click on New
  
  On this screen assign name to the shared lib and set the class path for that shared lib.
  

This is how you create testsharedlib shared library.

Now you have two choices either you can make this shared lib available to all the enterprise applications in your server, which is called server level shared lib or you can assign this shared libs to few applications by adding application level shared lib.