The classloader feature is intended for use only by application developers. This chapter assumes that you are familiar with WebLogic Server application classloading, as described in "Understanding WebLogic Server Application Classloading" in Developing Applications for Oracle WebLogic Server. Read that chapter first if you are not familiar with WebLogic Server application classloading.
This chapter includes the following sections:
When running multiple instances of the same application in different partitions, you may want to optimize classloading memory across these instances. WebLogic Server MT includes a deployment-descriptor-based classloading feature for this purpose.
WebLogic Server MT includes two new types of classloaders:
Partition classloader: A partition classloader is created on your behalf for each partition. This classloader loads classes that must be visible to the entire partition and only that partition, and not to the rest of the domain. (This includes global connectors.)
Note:
Global connectors are a certain type of connector modules that are configured to be visible and available for all the applications in the server. These modules may be deployed standalone or may be deployed as a module of an Enterprise Archive (EAR) file.
Shared application classloader: The shared application classloader is relevant only in the Software-as-a-Service (SaaS) use case when an application is deployed to a resource group template. This classloader loads classes that should be visible to all the instances of an application across partitions, but not to other applications. Applications directly deployed to the domain (not to a partition) are not affected, even if partitions are configured.
WebLogic Server deployment descriptors support a new shareable configuration to identify JAR files and classes under the APP-INF/classes directory within the application packaging. These classes should be loaded from the shared application classloader.
The shareable configuration is supported only in the weblogic-application.xml file of enterprise applications, and only in production mode.
A new partition classloader is created when a partition is created and the first application for the partition is deployed to a resource group. An existing partition classloader is removed when a partition is removed and the last application for the partition is undeployed from a resource group.
A new shared application classloader may be created when an application (with sharable JAR files configured) is deployed to a resource group template and the resource group template is referenced by a resource group in a partition.
An existing shared application classloader is removed when the relevant application is undeployed from the resource group template. When you undeploy an application from a resource group template, it is immediately undeployed from any resource groups that reference that template.
Note:
You cannot assume that classloading will be shared. Sharing may or may not be possible. For example, if filtering is set up such that different configurations for each partition are obtained, then sharing is not possible. For information about filtering classloaders, see "Using a Filtering ClassLoader" in Developing Applications for Oracle WebLogic Server.
Therefore, you can indicate which JAR files are shareable, but cannot assume that the classes from these JAR files are loaded only once and shared.
Using an XML editor, application developers can edit the weblogic-application.xml file and add one or more shareable elements inside a <class-loading> element when creating the application.
Consider the following example:
<class-loading>
<shareable dir="APP-INF-LIB">
<include>coupon-generator.jar</include>
<include>group-discounts.jar</include>
</shareable>
<shareable dir="LIB-DIR">
<exclude>program-guide.jar</exclude>
</shareable>
</class-loading>
The dir attribute identifies the directory where subsequent patterns apply. The only supported values for dir are as follows:
APP-INF-LIB identifies the WebLogic Server-style APP-INF/lib directory.
LIB-DIR identifies the Java EE-style library directory.
APP-INF-CLASSES identifies the WebLogic Server-style APP-INF/classes directory.
For the APP-INF-LIB and LIB-DIR directories, the value that you set in <include></include> elements identifies JAR files that you believe can be shared without any problems. The classes in these JAR files cannot be dependent on:
Classes in JAR files that are not considered shareable.
Partition-scoped classes such as global connectors.
Similarly, for the APP-INF-LIB and LIB-DIR directories, the <exclude></exclude> elements helps identify JAR files that must not be shared.
The following configuration rules apply:
If APP-INF-LIB and LIB-DIR are identified without an include or exclude configuration, then all the JAR files of that directory are considered sharable.
If APP-INF-LIB and LIB-DIR are identified with an include configuration, then only the JAR files identified with the include pattern are considered sharable.
If APP-INF-LIB and LIB-DIR are identified with an exclude configuration, then all the JAR files of the directory except the JAR file identified by the exclude pattern are considered sharable.
APP-INF-CLASSES
For the APP-INF-CLASSES directory, include and exclude configurations are ignored, even if present. If you identify APP-INF-CLASSES as sharable, then all the classes are declared sharable.
The APP-INF-CLASSES directory is a code source location and does not require include and exclude elements. The shared application classloader implementation does not allow including or excluding elements within code source locations.
The APP-INF-CLASSES directory is valid only for the packaging unit the descriptor is in, whether it is an application or library. You must declare it separately for the application and libraries.
For information about filtering classloaders, see "Using a Filtering ClassLoader" in Developing Applications for Oracle WebLogic Server.