Fotolia_81329697_XS_T.png

Some Background

WebSphere controls whether applications (EARs and WARs) are in PARENT_FIRST or PARENT_LAST classloading mode by its deployment.xml. RAD, or Rational Application Developer, has tools to generate this, as does the application server itself, but the Eclipse plugins do not at the time of this writing. So how do you configure your applications?

Wait, what does the classloading mode do?

Simply, when your application attempts to load a class, say IOUtils from Apache Commons IO, the JVM needs to know what to do when it finds multiple classes with the same fully qualified name. You could have classes provided by your application server, global JARs that you have put into your application server, and JARs in your application.

_PARENT_FIRST _classloading means take classes found in WebSphere (the parent), or global JARs first. So if you bundle a version of Apache Commons IO that doesn’t match the parent version, your application will run with the parent version instead of your application’s version.

_PARENTLAST classloading means prefer your application’s first.

So what’s the problem?

Imagine this scenario:

  • Your servers have global JARs setup that specific applications running in the same WebSphere profile require
  • You start a new application in your local development environment and you don’t realize the server has overridden certain JARs
  • You bundle newer versions of those JARs in your application
    So, with the “It works on my machine” stamp of approval you push to your servers only to find… failure.

There are plenty of other scenarios that could lead to an issue as well.

What’s the silver bullet?!

Unfortunately, there is no silver bullet. You may want to re-evaluate having shared libraries, update their versions, change the classloading mode of your application, or use a different WebSphere profile. The right answer really depends on your environment, but if changing the classloading mode is right for you, read on!

Changing the classloading mode

There are a few ways to make this change:

  • Deploy your application to WebSphere and update the configuration in the admin console (or wsadmin)
  • Use RAD (Rational Application Developer) to change it, if you have RAD
  • Or, use a new tool that I’ve created!

Generating deployment.xml in WebSphere

To obtain a deployment.xml from WebSphere:

  1. Build your application as an EAR
  2. Manually install it to WebSphere (via your admin console at http://localhost:9060/ibm/console for example)
  3. Open your application in the admin console and configure your EAR’s classloader mode
  4. Use Manage Modules to configure the WARs’ classloader modes
  5. Save your changes to WebSphere
  6. Export your application from the admin console as an EAR
  7. Copy its ibmconfig with deployment.xml deeply nested in it

Generating deployment.xml in RAD

Generating deployment.xml in RAD is much easier:

  1. Right click your EAR
  2. Go to Java EE -> Open WebSphere Application Server Deployment
  3. Scroll to the bottom and configure classloader settings as desired

Comparing WebSphere’s generated deployment.xml to RAD’s

Updating the configuration in WebSphere generates a deployment.xml that you may not want to re-use. Let’s take a look at the differences:

WebSphere’s version

deployment.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
<?xml version=“1.0” encoding=“UTF-8”?>
<appdeployment:Deployment xmlns:appdeployment=“http://www.ibm.com/websphere/appserver/schemas/5.0/appdeployment.xmi“ xmlns:xmi=“http://www.omg.org/XMI“ xmi:version=“2.0” xmi:id=“Deployment_1428026415557”>
<deployedObject xmi:type=“appdeployment:ApplicationDeployment” xmi:id=“ApplicationDeployment_1428026415557” deploymentId=“0” startingWeight=“1” binariesURL=“$(APP_INSTALL_ROOT)/WIN-F8QH15674T8Node02Cell/JpaExample.ear” useMetadataFromBinaries=“false” enableDistribution=“true” createMBeansForResources=“true” reloadEnabled=“false” appContextIDForSecurity=“href:WIN-F8QH15674T8Node02Cell/JpaExample” filePermission=“..dll=755#..so=755#..a=755#..sl=755” allowDispatchRemoteInclude=“false” allowServiceRemoteInclude=“false” asyncRequestDispatchType=“DISABLED” standaloneModule=“false” enableClientModule=“false”>
<targetMappings xmi:id=“DeploymentTargetMapping_1428026415557” enable=“true” target=“ServerTarget_1428026415557” />
<modules xmi:type=“appdeployment:WebModuleDeployment” xmi:id=“WebModuleDeployment_1428026415557” deploymentId=“1” startingWeight=“10000” uri=“JpaExampleWeb.war” classloaderMode=“PARENT_LAST” containsEJBContent=“0”>
<targetMappings xmi:id=“DeploymentTargetMapping_1428026415558” target=“ServerTarget_1428026415557” />
<classloader xmi:id=“Classloader_1428026415558” />
</modules>
<classloader xmi:id=“Classloader_1428026415557” mode=“PARENT_LAST” />
<properties xmi:id=“Property_1428026415557” name=“metadata.complete” value=“false” />
</deployedObject>
<deploymentTargets xmi:type=“appdeployment:ServerTarget” xmi:id=“ServerTarget_1428026415557” name=“server1” nodeName=“WIN-F8QH15674T8Node02” />
</appdeployment:Deployment>

RAD’s version:

deployment.xml
1
2
3
4
5
6
7
<?xml version=“1.0” encoding=“UTF-8”?>
<appdeployment:Deployment xmlns:appdeployment=“http://www.ibm.com/websphere/appserver/schemas/5.0/appdeployment.xmi“ xmlns:xmi=“http://www.omg.org/XMI“ xmi:version=“2.0” xmi:id=“Deployment_1423511656329”>
<deployedObject xmi:type=“appdeployment:ApplicationDeployment” xmi:id=“ApplicationDeployment_1423511656329” startingWeight=“10”>
<modules xmi:type=“appdeployment:WebModuleDeployment” xmi:id=“WebModuleDeployment_1423511656329” startingWeight=“10000” uri=“JpaExample.war” classloaderMode=“PARENT_LAST” />
<classloader xmi:id=“Classloader_1423511656329” mode=“PARENT_LAST” />
</deployedObject>
</appdeployment:Deployment>

The differences

Primarily, the WebSphere version includes node/cell specifics. If you take that version and deploy to a different server, you will end up with new folders in your profile/installedApps directory. This doesn’t cause any issues (that I’ve experienced) but its annoying.

A better solution for non-RAD users

If you take a look at the RAD version, its pretty basic and just lists the applications deployed and which classloading mode they are in. The ids are a standard format with the time after them.

So, assuming you are not using anything else in deployment.xml, this file is easy to reproduce! And to make it easier, I created a command line application to do it for you!

https://github.com/craigstjean/WebSphere-Deployment-Xml-Tool

To use it, invoke the JAR, passing it your application.xml as the first parameter, followed by either:

  • Nothing (which shows you its menu)
  • list (lists the EAR and all web application’s classloading mode)
  • set parent first (sets the EAR and all web applications to PARENT_FIRST)
  • set parent last (sets the EAR and all web applications to PARENT_LAST)
    For example:
1
java -jar WebSphere-Deployment-Xml-Tool.jar C:\workspace\MyProject\MyEar\META-INF\application.xml set parent last

And that’s it!

If you have any troubles with it, please create a GitHub issue and I’ll take a look!