How to configure classloader for ear in websphere 6.1 (specifically wsdl4j)

Question

I have a war file (actually not my own, it's Apache ODE 1.2) that fails to deploy into WAS 6.1 because of a classloader issue - and a specific incompatibility with wsdl4j. If I manually edit the classloader for ODE and create a shared-library for wsdl4j1.6.1 it's all fine.

However, the client has come back stating this is not acceptable and that I should provide an ear that is a self-contained install, with no manual steps involved.

I've been able to build the ear file that bundles the war, but I cannot find any relevant information on how to include a shared-lib within the ear - and have that used at the start of the classloader (needs to take preference over the wsdl4j bundled with WAS). Do I need to modify the ear file construct? Or the application.xml?

Can anyone offer any help? As you may guess, I am from a "tomcat just needs a war file" background, struggling to get to grips with ear files.

My application.xml just contains: http://java.sun.com/xml/ns/j2ee/application_1_4.xsd"> XXX ODE ode.war ode etc

Answer 1

You have three simple steps to accomplish this

1. Place the jar file in the ear, we typically create a lib directory, but that is not necessary.
2. Update the manifest for the war to include this jar file.
3. Set the classloading policy for your ear to PARENT_LAST. This is required to load your local (to the ear) classes before those loaded by the server.

Edit: As an alternative, since you are only using the EAR to wrap the WAR and not actually sharing the jar file.

1. Put the jar in the lib directory of the WAR.
2. Set the classloading policy for your ear to PARENT_LAST. This is required to load your local (to the ear) classes before those loaded by the server. I do this via RAD by editing the application.xml file. It is IBM specific configuration, so if you are not using RAD you will have to figure out what files to change manually.

This should leave you with a consistent war between app servers.

Answer 2

This post suggests a way to package the deployment.xml within the EAR