This chapter describes how to use the shared application classloaders in WebLogic Server Multitenant (MT). The chapter refers to the WebLogic Server documentation set and online help for additional information as appropriate.
This 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 class loading 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 application (EAR).Shared application classloader—the shared application classloader is relevant only in the 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 deployment descriptors support a new shareable configuration to identify JARs and classes under APP-INF/classes within the application packaging. These classes should be loaded from the shared application classloader.
The shareable configuration is only supported 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 shareable JARs 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.
You cannot assume that class loading 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, sharing is not possible. For information on filtering classloaders, see "Using a Filtering ClassLoader" in Developing Applications for Oracle WebLogic Server.
Therefore, you can indicate which JARs are shareable, but cannot assume that the classes from these JARs 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-style APP-INF/lib directory.
LIB-DIR identifies the Java EE-style library directory.
APP-INF-CLASSES identifies the WebLogic-style APP-INF/classes.
For APP-INF-LIB and LIB-DIR, the value you set in <include></include> elements identifies JAR files that you believe can be shared without any problems. The classes in these JARs cannot be dependent on:
Classes in JARs that are not considered shareable.
Partition-scoped classes such as global connectors.
Similarly, for APP-INF-LIB and LIB-DIR, the <exclude></exclude> elements helps identify JARs that must not be shared.
The following configuration rules apply:
If APP-INF-LIB and LIB-DIR is identified without an include or exclude configuration, all the JARs of that directory are considered as shareable.
If APP-INF-LIB and LIB-DIR is identified with an include configuration, only the JARs identified with the include pattern are considered shareable.
If APP-INF-LIB and LIB-DIR is identified with an exclude configuration, all the JARs of the directory except the JAR identified by the exclude pattern are considered shareable.
For APP-INF-CLASSES, include and exclude configurations are ignored, even if present. If you identify APP-INF-CLASSES as shareable, all the classes are declared shareable.
APP-INF-CLASSES 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.
APP-INF-CLASSES is valid only for the packaging unit the descriptor is in, application or library. You must declare it separately for the application and libraries.
For information on filtering classloaders, see "Using a Filtering ClassLoader" in Developing Applications for Oracle WebLogic Server.