Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Working with third-party JAR files in WebLogic systems

Updated on August 28, 2019

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.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us