Working with third-party JAR files in WebLogic systems
Summary
If you are using third-party .jar files when developing a Process Commander application on BEA WebLogic, issues and conflicts can arise, depending upon the .jar file used.
For example, BEA Systems embeds a number of third-party class files within weblogic.jar
, including a version of ANTLR for use with BEA's JSP compiler (which is an earlier version than the one used in Process Commander).
If you need to use a different version of one of the packages listed below, you may have to set a switch to use the appropriate file.
Suggested Approach
Unlike other application servers (such as Tomcat), there is no attempt made by default to segregate WebLogic internal classes from application classes through creative use of classloaders. Based on a review of the content of weblogic.jar
, the high- level paths that appear to be third-party classes include:
- antlr
- bsh
- com/adventnet
- com/asn1c
- com/certicom
- com/intrinsyc
- com/linar
- com/netscape
- com/octetstring
- com/oroinc
- com/rsa
- COM/rsa
- net/n3
- netscape
- org/mozilla
- org/omg
- org/w3c
- org/xml
- utils
BEA documents that WebLogic classloaders follow the standard Java delegation convention instead of the delegation model contained in the servlet specification (see below). As a result, including additional jar files on the WebLogic classpath could also introduce version incompatibilities for some Web applications (for example, incompatible versions of XML parsers).
Process Commander requires that the J2EE server in which it is deployed follow the J2EE / servlet specification for classloader delegation. WebLogic can be instructed to use the servlet delegation model as follows:
With WebLogic 8, there is a setting in weblogic.xml
(analogous to the ibm-web-ext.xmi
files for WebSphere) that one can set to control this automatically when the application is deployed. (This setting is "on" by default.)
BEA's commentary on how to override embedded versions of third-party classes (including specific instructions for WebLogic 7, while the rationale applies to all versions of WebLogic).
Using PreferWebInfClasses in J2EE Applications
By default, the classloader for a Web application follows the standard delegation model described in the Javasoft documentation. The servlet specification requires that a Web application obtain its class definition from the WAR file.
To support this requirement, BEA has included a switch that modifies the delegation model for a Web application so that the Web application's classloader looks for a class in the WAR file before asking its parent classloader for the class. This switch is named PreferWebInfClasses and is located on the WebAppComponentMBean.
You can set this switch in the WebLogic Server console.
- When you set PreferWebInfClasses to false (the default), the classloader for a Web application follows the standard delegation model.
- When set to true, it looks for class definitions in the WAR file before asking its parent for a class definition.
This switch satisfies the specification requirement. However, it leads to the possibility of having different versions of the same classes loaded in the Web application classloader than those versions existing in parent classloaders. This can lead to ClassCastExceptions if you are not careful to keep these two instances separate. For this reason, Pegasystems has set the default for this to false, which means you use the standard delegation model.