This chapter describes the following new and changed functionality in Oracle WebLogic Server 12.2.1:

Revision History of this Document

Configuring and Using the Diagnostics Framework for Oracle WebLogic Server

Updated Standards Support to clarify the specific versions of Java EE JSF that are supported in Oracle WebLogic Server 12.2.1.

Added documentation for additional JDBC data source runtime features provided in Oracle WebLogic Server 12.2.1. For more information, see JDBC Data Sources .

Multitenancy Support

Multitenancy in WebLogic Server provides a sharable infrastructure for use by multiple organizations. These organizations are a conceptual grouping of your own choosing, which you can think of as tenants. By allowing one domain to support multiple tenants, Weblogic Server Multitenant improves density and achieves a more efficient use of resources while eliminating the hurdles typically present when trying to share multiple applications: runtime cross-application impact, security differences, data co-mingling, and administrative challenges.

WebLogic Server Multitenant provides resource isolation within domain partitions, an administrative and runtime slice of a WebLogic domain that is dedicated to running application instances and related resources for a tenant. Domain partitions achieve greater density by allowing application instances and related resources to share the domain, WebLogic Server itself, the Java virtual machine, and the operating system while isolating tenant-specific application data, configuration, and runtime traffic.

WebLogic Server MT enables an end to end multitenant infrastructure, including multitenancy from the load balancer to the middle tier and cache tier, and to the database tier. WebLogic Server MT extends the Oracle WebLogic Server Enterprise Edition and Oracle WebLogic Suite products, and includes the following components:

Oracle WebLogic Server MT, which enables consolidation of applications into fewer domains (by allowing partitions within domains) while maintaining secure isolation

WebLogic MT extensions to Java SE Advanced, which enables memory, CPU and I/O isolation, monitoring, and management for applications within a JVM

Oracle WebLogic Coherence Enterprise Edition to Grid Edition option, which enables consolidation of caches into fewer Oracle Coherence clusters while maintaining secure isolation

Oracle Traffic Director which provides WebLogic Server MT-aware and fully integrated tenant-aware local load balancing

See Using WebLogic Server Multitenant for additional information.

WLST Changes to Support Multitenancy To support multitenancy, new WLST commands have been added to WebLogic Server 12.2.1 and existing commands have been modified to support new arguments for multitenancy environments. The following WLST commands have been added for multitenancy: importPartition —Imports a domain partition from a partition archive.

exportPartition —Exports a domain partition to a partition archive.

startPartitionWait —Starts a domain partition and waits until the partition has started.

migrateResourceGroup —Migrates a domain partition resource group from one target to another target. The following arguments have been added to existing WLST commands to support multitenancy: The resourceGroup , resourceGroupTemplate , and partition arguments have been added to the deploy command. Use these to specify the resource group, resource group template, and partition to which a deployment is scoped.

The resourceGroupTemplate , partition , and removePlanOverride arguments have been added to the redeploy command. Use these to specify the resource group template and partition to which the redeployment is scoped, and to specify whether or not the previous plan override at the resource group level should be removed.

The resourceGroupTemplate and partition arguments have been added to the undeploy command. Use these to specify the resource group template and partition to which the deployment is scoped.

The resourceGroupTemplate , partition , and removePlanOverride arguments have been added to the updateApplication command. Use these to specify the resource group template and partition to which the new deployment is scoped, and to specify whether or not the previous plan override at the resource group level should be removed.

The resourceGroup , resourceGroupTemplate , and partition arguments have been added to the distributeApplication command. Use these to specify the resource group, resource group template, and partition to which the copied deployment bundle is scoped.

The partition argument has been added to the startApplication and stopApplication commands. Use this argument to specify the partition to which the deployment is scoped.

The partition argument has been added to the exportDiagnosticDataFromServer command. Use this argument to specify the partition from which diagnostics data will be retrieved.

The partition argument has been added to the saveDiagnosticImageCaptureFile and saveDiagnosticImageCaptureEntry File commands. Use this argument to specify the partition from which the image or image entry will be retrieved.

The partition argument has been added to the captureAndSaveDiagnosticImage command. Use this argument to specify the partition from which the image will be retrieved. The partition argument is also supported for the following new WLST diagnostic commands. Use this argument to restrain the scope of the diagnostic command to a particular partition within a domain: activateDebugPatch

deactivateDebugPatches

exportHarvestedTimeSeriesData

exportHarvestedTimeSeriesDataOffline

getAvailableDiagnosticDataAccessornames

purgeCapturedImages For information about these and other new WLST commands, see WLST.

Deployment Support for Multitenancy Using WebLogic Server Multitenant, you can deploy applications and libraries to resource groups templates and resource groups at the domain and partition levels. You can perform deployment operations to these scopes using the new attributes added to existing deployment clients. The following deployment clients support multitenant application deployment: weblogic.Deployer

WLST deployment commands

JSR-88 API for deployment

JMX Deployment API

WLDeploy ant task

Maven goals for deployment

WebLogic Server Administration Console

Fusion Middleware Control For more information, see "Deploying Applications" in Using WebLogic Server Multitenant and "Deploying Applications to Resource Groups and Templates" in Deploying Applications to Oracle WebLogic Server. Additional multitenant deployment features include: Partition-Specific Deployment Plans

Concurrent Deployment Partition-Specific Deployment Plans You can use partition-specific deployment plans to customize any application deployed to a resource group template or resource group within a partition. Partition-specific deployment plans are specified at the resource group level within a partition, not at the partition level. When WebLogic Server applies a partition-specific deployment plan to a specified application, the changes prescribed by the plan affect only the application deployment within that partition. To configure partition-specific application deployment plans, use the redeploy or updateApplication WLST commands. The new WLST options resourceGroupTemplate and partition identify the scope of the application deployment, and the existing WLST options planPath and appName identify the location of the partition-specific deployment plan and the name of the application deployment to modify. For more information, see "Using Partition-Specific Deployment Plans" in Using WebLogic Server Multitenant. Concurrent Deployment WebLogic Server 12.2.1 supports concurrent deployment operations across multiple edit sessions. Concurrent deployment allows different partition administrators to deploy applications at the same time, without one administrator having to wait for another administrator's application to complete the deployment process. Concurrent deployment improves performance and prevents administrators from being blocked by other administrators. Concurrent deployment occurs automatically; there are no attributes to configure.

JNDI Support for Multitenancy To support multitenancy, JNDI will be partition-aware and provide partition isolation internally. Partition-aware JNDI includes the following features: Partition-scoped and domain-scoped global JNDI resources—There will be one global JNDI tree for every partition and domain on a node. For example, when deploying an EJB to multiple partitions and domains, the EJB's JNDI name is bound to the global JNDI tree for each partition and domain. When looking up the JNDI name, the JNDI tree that is used depends on the scope of the lookup (partition or domain).

Object-based partition association—When a JNDI context is created within a domain partition, the context object sticks to the partition namespace so that all subsequent JNDI operations are done within the context of the partition.

Cross-partition access—Partition JNDI resources can be accessed from remote standalone Java code using the WebLogic Server client, or by code that resides in a remote WebLogic Server instance. They can also be accessed from another partition on the same server.

Clustered JNDI—The JNDI tree that represents a cluster appears to the client as a single global tree. The tree containing cluster-wide services is replicated across each WebLogic Server instance or partition in the cluster.

Foreign JNDI—You can use foreign JNDI to access another partition whether it is local or remote. By setting up a foreign JNDI provider with the properties of the other partitions, you can look up and use an object that exists outside of the partition.

New provider URL patterns—For local access across partitions, the following new provider URL patterns have been introduced: local://?partitionName=DOMAIN creates the context on the domain. local://?partitionName= partitionName creates the context on the specified partition.

Partition JNDI resource lifecycle—Partition JNDI resources are maintained based on the partition lifecycle. When a partition is created and started, the partition JNDI tree is created with the partition root node and becomes available. When the partition is shut down, the partition JNDI tree is deleted.

Partition information binding—When initializing the partition tree, partition information is bound to the partition global JNDI tree. Therefore, you can obtain the partition information of the context by looking up: weblogic.partitionName , which returns the context-based partition's partition name or "Domain" if it is a domain. weblogic.partitionID , which returns the current partition's partition ID or "0" if it is a domain.

For more information, see "Configuring and Programming JNDI" in Using WebLogic Server Multitenant.

Partition Security To support multitenancy and partitions, the Weblogic Security Service includes the following new features in release 12.2.1: Multiple active realms To provide isolation of the security configuration and metadata, WebLogic Server now supports the ability to have multiple active security realms in a domain. Support for multiple active realms enables per-partition configuration for realm-based services by allowing each partition to execute against a different realm. Partitions may also share a security realm, which may be appropriate when the security configuration between two partitions does not require isolation.

Identity domains An identity domain is a logical name space for users and groups, typically representing a discrete set of users and groups in a physical store. Identity domains are used to identify the users associated with particular partitions.

Partition-aware security services Partition-aware security services contain context about the partition in which they execute so that, for example, they can control access to a resource based on the partition to which the resource belongs. Partition-aware services are also identity domain aware. To support partition-aware security services, WebLogic Server adds several new predicates that can be used in security policies to scope access at the partition level. For more information, see "Configuring Security" in Using WebLogic Server Multitenant.

Partition Work Managers Partition-specific Work Managers provide fairness of thread usage and prioritization of work requests among partitions that share the same WebLogic Server instance. Partition Work Managers: Allow system administrators to set thread usage policies among partitions and configure customized QoS levels.

Allow partition administrators to configure Work Manager policies for their partitions.

Support the prioritization of thread usage by work requests from various partitions.

Ensure the fairness in thread resource usage among partitions. For more information, see "Configuring Partition Work Managers" in Using WebLogic Server Multitenant.