Troubleshooting
Problem
There are several instances when applications require specific versions of libraries which are different from the ones that are packaged with the server distribution. For example, LOG4J-1.2.14 is distributed with WebSphere Application Server Community Edition version 2.1.1.1. If an application requires a version later than the supplied version, WebSphere Application Server Community Edition provides several mechanisms to make these specific versions of the libraries available to applications at runtime. This technote explains several methods available to address the same problem.
Resolving The Problem
All the solutions listed below refer to inclusion of certain XML elements to geronimo specific plans. These XML elements change the default behavior of the class loading policy.
- <inverse-classloading/>
If this element is omitted, in the normal case, if the classes are available in parent classloader, they will be loaded from the parent classloader. If this element is added, classloading will be always attempted from the current classloader before parent classloaders are contacted. Therefore, the behavior is reversed when the element is added. This is often enabled to give the JARs in WEB-INF/lib precedence over anything that might be in a parent class loader. This element does not take any content, it is simply present or absent.
The following sample plan is declaration of tag <inverse-classloading/> in <environment> element of geronimo-web.xml plan.
- <hidden-classes>
The hidden classes will always be loaded by the current classloader. If the current classloader cannot load the classes, the application throws "ClassNotFoundException". This mandates applications load their own specific classes. Below steps explain the usage of the XML element.
Include this element to hide certain classes available in parent classloader from the applications.
Specify a list classes with package prefix in the <filter> element which is a child of <hidden-classes> as below in gronimo-web.xml plan.
- <non-overridable-classes>
This element forces applications to load the specified classes from parent classloader only. The classes listed are never loaded from WEB-INF/lib or WEB-INF/classes.
. . <sys:environment> . . <inverse-classloading/> </sys:environment> . . |
Copy the required version of library into WEB-INF/lib, or upload it to server repository and declare a dependency in the geronimo specific plan. |
. . <sys:environment> . . . <hidden-classes> <filter>com.ibm.TestMe1</filter> <filter>com.ibm.TestMe2</filter> </hidden-classes> . </sys:environment> . . |
Copy the contents of specific version of library that contain the specific classes into WEB-INF/lib, or upload it to server repository and declare a dependency in the geronimo specific plan. Note: The following illustration explains how to hide classes in a package. |
<hidden-classes> <filter>com.ibm</filter> <filter>com.ibm</filter> </hidden-classes> |
. . <sys:environment> . . . <non-overridable-classes> <filter>com.ibm.TestMe1</filter> <filter>com.ibm.TestMe2</filter> </non-overridable-classes> </sys:environment> . . |
The com.ibm.TestMe1 and com.ibm.TestMe2 are always to be loaded by the parent classloader. Note: The following illustration explains how to load classes in a package always from the parent classloader. |
<non-overridable-classes> <filter>com.ibm</filter> <filter>com.ibm</filter> </non-overridable-classes> |
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21261287