One feature of WebLogic Server that helps developers to pinpoint class conflicts and other classloader issues is the Classloader Analysis Tool (CAT). Here's the description of what it does, taken from its main page:
CAT is a small web application that is designed to help application developers understand, analyze, and resolve classloading issues in their applications.
It does so by showing all applications and modules on the server where you're running CAT, and from there, you can drill down and check which classes were loaded by each classloader, searching for potential conflicts.
In order to use CAT, there are a few points that must be observed:
- Your server must be running in the development mode. By default, CAT is not enabled on production servers
- You cannot run CAT on servers running over IBM SDK for Java, as some functions depend on implementation provided by HotSpot
- A console credential is required to access it, so if you're not able to access the administration console, you will not be able to access CAT either
If all the previously mentioned requirements apply, just open a browser and direct it to http://localhost:7001/wls-cat to load the application. The package is deployed on demand, so wait for a few seconds for this process, and a credential pop up will be displayed, asking for the username and password, and the main page will be loaded.
Another way to start it is by going to the Testing tab of any deployed application and clicking on the Classloader Analysis Tool link:
In the top-left corner, you can see a list of the modules and applications enabled on the server where CAT is running, something like the following screenshot:
From this tree, you can check the classloaders of each application. Clicking on Store.war under Store and then clicking on Classloader Tree on the blue ribbon will show us details of all classloaders attached to this specific module:
The previous screenshot shows basic information of each classloader. If you click on the detailed link on the top blue ribbon, the same list will be presented, along with all libraries loaded by each one. It is great to do a visual check of which libraries are being loaded, but the volume of output can be overwhelming, making it difficult to sort out all the information, so another feature can be used to check for conflicts, as explained in the next section.
An easier way to look for conflicts is to use CAT's Analyze Conflicts function. To do so, you just need to click on the module name you want to analyze, then on the Analyze Conflicts link on the blue ribbon. And it's done!
To show how it works, we left the file StoreBO.jar in the domain's lib folder (we added it in Chapter 7, Remote Access with JMS, to be able to see what's inside a JMS message), and we also have a shared library exposing the same classes, and this shared library is explicitly referenced by the Store's web application. When we ask WebLogic to check for possible conflicts, the output generated would look like the following screenshot:
A list with all classes from the library is presented. To check on which files carry a specific class, just click on the class' name to show its details:
Just by looking at the paths of the libraries, we can tell that the first reference comes from the domain lib (/opt/packt/domains/ticket/lib/…), and the other is a standalone deployment (…/AdminServer/upload/StoreBO.jar…). As the classes are being loaded from the domain library, any changes to the shared library (the one we are supposed to use) aren't going to be reflected, and errors may arise—for instance, if there's a new version of a class with a couple more methods that the application can't find, MethodNotFoundException errors are likely to happen.
CAT is a very handy feature, even more so when you don't have full control of the server, and several projects and applications are running and applying changes to it simultaneously.