Wednesday Oct 28, 2015

Weblogic Server 12.2.1 Multi-Tenancy Diagnostics Overview


WebLogic Server 12.2.1 release includes support for multitenancy, which allows multiple tenants to share a single WebLogic domain. Tenants have access to domain partitions which provides an isolated slice of the WebLogic domain's configuration and runtime infrastructure.

This blog provides an overview of the diagnostics and monitoring capabilities available to tenants for applications and resources deployed to their respective partitions.

These features are provided by the WebLogic Server Diagnostic Framework (WLDF) component.

The following topics are discussed in the sections below.

Log and Diagnostic Data

Log and diagnostic data from different sources are made available to the partition administrators. They are broadly classified into the following groups:

  1. Shared data - Log and diagnostic data not directly available to the partition administrators in raw persisted form. It is only available through the WLDF Accessor component.
  2. Partition scoped data - These logs are available to the partition administrators in its raw form under the partition file system directory.

Note that The WLDF Data Accessor component provides access to both the shared and partition scoped log and diagnostic data available on a WebLogic Server instance for a partition.

The following shared logs and diagnostic data is available to a partition administrator.

Log Type
Content Description
Server Log events from Server and Application components pertaining to the partition recorded in the Server log file.
Domain Log events collected centrally from all the Server instances in the WebLogic domain pertaining to the partition in a single log file.
DataSource DataSource log events pertaining to the partition.
HarvestedData Archive Metrics data gathered by the WLDF Harvester from MBeans pertaining to the partition.
Instrumentation Events Archive WLDF Instrumentation events generated by applications deployed to the partition.

The following partition scoped log and diagnostic data is available to a partition administrator.

Log Type
Content Description
HTPP access.log HTTP access.log from partition virtual target's WebServer
JMSServer JMS server message life-cycle events for JMS server resources defined within a resource group or resource group template scoped to a partition.
SAF Agent SAF agent message life-cycle events for SAF agent resources defined within a resource group or resource group template scoped to a partition.
Connector Log data generated by Java EE resource adapter modules deployed to a resource group or resource group template within a partition.
Servlet Context Servlet context log data generated by Java EE web application modules deployed to a resource group or resource group template within a partition.

WLDF Accessor

The WLDF Accessor provides the RuntimeMBean interface to retrieve diagnostic data over JMX. It also provides a query capability to fetch only a subset of the data.

Please refer to the documentation on WLDF Data Accessor for WebLogic Server for a detailed description of this functionality.

WLDFPartitionRuntimeMBean (child of PartitionRuntimeMBean) is the root of the WLDF Runtime MBeans. It provides a getter for WLDFPartitionAccessRuntimeMBean interface which is the entry point for the WLDF Accessor functionality scoped to a partition. There is an instance of WLDFDataAccessRuntimeMBean for each log instance available for partitions.

Different logs are referred to by their logical names according to a predefined naming scheme.

The following table lists the logical name patterns for the different partition scoped logs.

Shared Logs

Log Type

Logical Name

Server Log


Domain Log




Harvested Metrics


Instrumentation Events


Partition Scoped Logs

Log Type

Logical Name

HTTP Access Log


JMS Server Log


SAF Agent Log


Servlet Context Log


Connector Log


Logging Configuration

WebLogic Server MT supports configuring Level for java.util.logging.Loggers used by application components running within a partition. This will allow Java EE applications using java.util.logging to be able to configure levels for their respective loggers even though they do not have access to the system level java.util.logging configuration mechanism. In case of shared logger instances used by common libraries used across partitions also the level configuration is applied to a Logger instance if it is doing work on behalf of a particular partition.

This feature is available if the WebLogic System Administrator has started the server with -Djava.util.logging.manager=weblogic.logging.WLLogManager command line system property.

If the WebLogic Server was started with the custom log manager as described above, the partition administrator can configure logger levels as follows:

Please refer to the sample WLST script in the WLS-MT documentation.

Note that the level configuration specified in the  PartitionLogMBean.PlatformLoggerLevels attribute is applicable only for the owning partition. It is possible that a logger instance with the same name is used by another partition, each logger's effective level at runtime will defined by the respective partition's  PartitionLogMBean.PlatformLoggerLevels configuration.

Server Debug 

For certain troubleshooting scenarios you may need to enable debug output from WebLogic Server subsystems specific to your partition. The Server debug output is useful to debug internal Server code when it is doing work on behalf of a partition. This needs to be done carefully in collaboration with the WebLogic System Administrator and Oracle Support. The WebLogic System Administrator must enable the ServerDebugMBean.PartitionDebugLoggingEnabled attribute first and will advise you to enable certain debug flags. These flags are boolean attributes defined on the ServerDebugMBean configuration interface. The specific debug flags to be enabled for a partition are configured via the PartitionLogMBean.EnabledServerDebugAttributes attribute. It contains an array of String values that are the names of the specific debug outputs to be enabled for the partition. The debug output thus produced is recorded in the server log from where it can be retrieved via the WLDF Accessor and provided to Oracle Support for further analysis. Note that once the troubleshooting is done the debug needs to be disabled as there is a performance overhead incurred when you enable server debug.

Please refer to the sample WLST script in the WebLogic Server MT documentation on how to enable partition specific server debug.

Diagnostic System Module for Partitions

Diagnostic System Module provides Harvester and Policies and Actions components that can be defined within a resource group or resource group template deployed to a Partition.


WLDF Harvester provides the capability to poll MBean metric values periodically and and archive the data in the harvested data archive for later diagnosis and analysis. All WebLogic Server Runtime MBeans visible to the partition including the PartitionRuntimeMBean and its child MBeans as well as custom MBeans created by applications deployed to the partition are allowed for harvesting. Harvester configuration defines the sampling period, the MBean types and instance specification and their respective MBean attributes that needs to be collected and persisted.

Note that the archived harvested metrics data is available from the WLDF Accessor component as described earlier.

The following is an example of harvester configuration persisted in the Diagnostic System Resource XML descriptor.


For further details refer to the WLDF Harvester documentation.

Policies and Actions

Policies are rules that are defined in Java Expression Language (EL) for conditions that need to be monitored. WLDF provides a rich set of actions that can be attached to policies that get triggered if the rule condition is satisfied. 

The following types of rule based policies can be defined.

  • Harvester - Based on WebLogic Runtime MBean or Application owned custom MBean metrics.
  • Log events - Log messages in the server and domain logs.
  • Instrumentation Events - Events generated from Java EE application instrumented code using WLDF Instrumentation.

The following snippets show the configuration of the policies using the EL language.

    <rule-expression>wls.partition.query("com.bea:Type=WebAppComponentRuntime,*", "OpenSessionsCurrentCount").stream().anyMatch(x -> x >= 1)
  <rule-expression>log.severityString == 'Error'</rule-expression>
  <rule-expression>instrumentationEvent.eventType == 'TraceAction'</rule-expression>

The following types of actions are supported for partitions:

  • JMS
  • SMTP
  • JMX
  • REST
  • Diagnostic Image

For further details refer to the Configuring Policies and Actions documentation.

Instrumentation for Partition Applications

WLDF provides a byte code instrumentation mechanism for Java EE applications deployed within a partition scope. The Instrumentation configuration for the application is specified in the META-INF/weblogic-diagnostics.xml descriptor file.  

This feature is available only if the WebLogic System Administrator has enabled server level instrumentation. Also it is not available for applications that share class loaders across partitions.

The following shows an example WLDF Instrumentation descriptor.

    <pointcut>execution( * example.util.MyUtil * (...))</pointcut>

For further details refer to the WLDF Instrumentation documentation.

Diagnostic Image

The Diagnostic Image is similar to a core dump which captures the state of the different WebLogic Server subsystems in a single image zip file. WLDF supports the capturing of partition specific diagnostic images.

Diagnostic images can be captured in the following ways:

  • From WLST by the partition administrator.
  • As the configured action for a WLDF policy.
  • By invoking the captureImage() operation on the WLDFPartitionImageRuntimeMBean.

Images are output to the logs/diagnostic_images directory in the partition file system.

The image for a partition contains diagnostic data from different sources such as:

  • Connector
  • Instrumentation
  • JDBC
  • JNDI
  • JVM
  • Logging
  • RCM
  • Work Manager
  • JTA

For further details refer to the WLDF documentation.

RCM Runtime Metrics

WebLogic Server 12.2.1 introduced Resource Consumption Management (RCM) feature.  This feature is only available in Oracle JDK JDK8u40 and above.

To enable RCM add the following command line switches on Server start up

-XX:+UnlockCommercialFeatures -XX:+ResourceManagement -XX:+UseG1GC
Please note that RCM is not enabled by default in the startup scripts.
The PartitionResourceMetricsRuntimeMBean which is a child of the PartitionRuntimeMBean provides a bunch of useful metrics for monitoring purposes.

Attribute Getter



Checks whether RCM metrics data is available for this partition.


Total CPU time spent measured in nanoseconds in the context of a partition.


Total allocated memory in bytes for the partition.This metric value increases monotonically over time.


Number of threads currently assigned to the partition.



Total  and current number of sockets opened in the context of a partition.



Total number of bytes read /written from sockets for a partition.



Total  and current number of files opened in the context of a partition.



Total number of file bytes  read/written in the context of a partition.



Total  and current number of file descriptors opened in the context of a partition.


Returns a snapshot of the historical data for retained heap memory usage for the partition.  Data is returned as a two-dimensional array for the usage of retained heap scoped to the partition over time.  Each item in the array contains a tuple of [timestamp (long), retainedHeap(long)] values.


Returns a snapshot of the historical data for CPU usage for the partition. CPU utilization percentage indicates the percentage of CPU utilized by a partition with respect to available CPU to Weblogic Server.

Data is returned as a two-dimensional array for the CPU usage scoped to the partition over time. Each item in the array contains a tuple of [timestamp (long), cpuUsage(long)] values.

Please note that the PartitionMBean.RCMHistoricalDataBufferLimit attribute limits the size of the data arrays for Heap and CPU.

Java Flight Recorder

WLDF provides integration with the Java Flight Recorder which enables WebLogic Server events to be included in the JVM recording. WebLogic Server events generated in the context of work being done on behalf of the partition are tagged with the partition-id and partition-name. These events and the flight recording data are only available to the Weblogic System Administrator.


WLDF provides a rich set of tools to capture and access to different types of monitoring data that will be very useful for troubleshooting and diagnosis tasks. This blog provided an introduction to the WLDF surface area for partition administrators. You are encouraged to take a deeper dive and explore these features further and leverage them in your production environments. More detail information is available in the WLDF documentation for WebLogic Server and the Partition Monitoring section in the WebLogic Server MT documentation.

Partition Import/Export

This article will discuss common use cases scenarios of Import/Export Partition in Weblogic Multitenant Edition
[Read More]

Tuesday Oct 27, 2015

Resource Consumption Management in WebLogic Server MultiTenant 12.2.1 to Control Resource Usage of Domain Partitions

[This blog post is part of a series of posts that introduce you to new features in the recently announced Oracle WebLogic Server 12.2.1, and introduces an exciting performance isolation feature that is part of it.] 

With the increasing push to "doing more with less" in the enterprise, system administrators and deployers are constantly looking to increase density and improve hardware utilization for their enterprise deployments. The support for micro-containers/pluggable Domain Partitions in WebLogic Server Multitenant helps system administrators collocate their existing silo-ed business critical Java EE deployments into a single Mutitenant domain.

Say, a system administrator creates two Partitions "Red" and "Blue" in a shared JVM (a WebLogic Multitenant Server instance), and deploys Java EE applications and resources to them. A system administrator would like to avoid the situation where one partition's applications (say the "Blue" partition) "hogs" all shared resources in the Server instance's JVM (Heap)/the operating system (CPU, File descriptors), and negatively affecting the "Red" partition applications' access to these resources.

Runtime Isolation

Therefore, while consolidating existing enterprise workloads into a single Multitenant Server instance, system administrators would require better control (track, manage, monitor, control) over usage of shared resources by collocated Domain Partitions so that:


  • One Partition doesn't consume all available resources, and exhaust them from other collocated partitions. This helps a system administrator plan for, and support consistent performance to all collocated partitions.
  • Fair and effecient allocation of available resources are provided to collocated partitions. This helps a system administrator confidently place complementary workloads in the same environment, while achieving enhanced density and great cost-savings.

Control Resource Consumption Management


In Fusion Middleware 12.2.1, Oracle WebLogic Server Multitenant supports establishing resource management policies on the following resources


  • Heap Retained: Track and control the amount of Heap retained by a Partition
  • CPU Utilization: Track and control the amount of CPU utilization used by a Partition
  • Open File Descriptors: Track and control the amount of open file descriptors (due to File I/O, Sockets etc) used by a Partition.

    Recourse Actions

    When a trigger is breached, a system administrator may want to react to that by automatically taking certain recourse actions in response. The following actions are available out of the box with WebLogic.


    • Notify: inform administrator that a threshold has been surpassed
    • Slow: reduce partition’s ability to consume resources, predominantly through manipulation of work manager settings – should cause system to self-correct in certain situations
    • Fail: reject requests for the resource, i.e. throw an exception - only supported for file descriptors today
    • Stop: As an extreme step, initiate the shut down sequence for the offending partition on the current server instance


      The Resource Consumption Management feature in Oracle WebLogic Server Multitenant, enables a system administrator to specify resource consumption management policies on resources, and direct WebLogic to automatically take specific recourse actions when the policies are violated. A policy could either be created as one of the following two types


      • Trigger: This is useful when resource usage by Partitions are predictable and takes the form "when a resource's usage by a Partition crosses a Threshold, take a recourse action". 


      For example, a sample resource consumption policy that a system administrator may establish on a "Blue" Partition to ensure that it doesn't run away with all the Heap looks like: When the “Retained Heap” (Resource) usage for the “Blue” (Partition) crosses “2 GB” (Trigger), “stop” (Action) the partition.


      • Fair share: Similar to the Work Manager fair share policy in WebLogic, this policy allows a system administrator to specify "shares" of a bounded-size shared resource to a Partition. WebLogic then ensures that this resource is shared effectively (yet fairly) by competing consumers while honouring the "shares" allocated by the system administrator. 


      For example, a sample resource consumption policy that a system administrator who prefers "Red" partition over "Blue" may set the fair-share for the "CPU Utilization" resource in the ration 60:40 in favour of "Red".

      When complementary workloads are deployed to collocated partitions, fair-share policies also helps achieving maximal utilization of resources. For instance, when there are no or limited requests for the "Blue" partition, the "Red" partition would be allowed to "steal" and use all the available CPU time. When traffic resumes on the "Blue" partition and there is contention for CPU, WebLogic would allocate CPU time as per the fair-share ratio set by the system administrator. This helps system administrators reuse a single shared infrastructure and saving infrastructure costs in turn, while still retaining control over how those resources are allocated to Partitions. 


      Policy configurations could be defined at the domain level and reused across multiple pluggable Partitions, or they can be defined unique to a Partition. Policy configurations are flexible to support different combinations of trigger-based and fair-share policies for multiple resources to meet your unique business requirements. Policies can also be dynamically reconfigured without any restart of the Partition required. 

      The picture below shows how a system administrator could configure two resource consumption management policies (a stricter "trial" policy and a lax "approved" policy) and how they could be assigned to individual Domain Partitions. Heap and CPU resource by the two domain Partitions are then governed by the policies associated with each of them.

      WLS 12.2.1 RCM resource manager sample schematic

      Enabling Resource Management

      The Resource Consumption Management feature in WebLogic Server 12.2.1 is built on top of the resource management support in Oracle JDK 8u40. WebLogic RCM requires Oracle JDK 8u40 and the G1 Garbage Collector. In WebLogic Server Multitenant, you would need to pass the following additional JVM arguments to enable Resource Management:

      “-XX:+UnlockCommercialFeatures -XX:+ResourceManagement -XX:+UseG1GC”

      Track Resource Consumption

      Resource consumption metrics are also available on a per partition basis, and is provided through a Monitoring MBean, PartitionResourceMetricsRuntimeMBean. Detailed usage metrics on a per partition basis is available through this monitoring Mbean, and system administrators may use these metrics for the purposes of tracking, sizing, analysis, monitoring, and for configuring business-specific Watch and Harvester WLDF rules.


      Resource Consumption Managers in WebLogic MultiTenant helps provide the runtime isolation and protection needed for applications running in your shared and consolidated environments.

      For More Information

      This blog post only scratches the surface of the possibilities with the Resource Consumption Management feature. For more details on this feature, and how you can configure resource consumption management policies in a consolidated Multitenant domain using Weblogic Scripting Tool (WLST) and Fusion Middleware Control, and best practices, please refer the detailed technical document at "Resource Consumption Management (RCM) in Oracle WebLogic Server Multitenant (MT) - Flexibility and Control Over Resource Usage in Consolidated Environments".

      The Weblogic MultiTenant documentation's chapter "Configuring Resource Consumption Management" also has more details on using the feature.

      This feature is a result of deep integration between the Oracle JDK and WebLogic Server. If you are attending Oracle OpenWorld 2015 in San Francisco, head over to the session titled "Multitenancy in Java: Innovation in the JDK and Oracle WebLogic Server 12.2.1" [CON8633] (Wednesday, Oct 28, 1:45 p.m. | Moscone South—302) to hear us talk about this feature in more detail.

      We are also planning a series of videos on using the feature and we will update this blog entry as they become available.

      [Read More]

      Domain Partitions for Multi-tenancy in WebLogic Server 12.2.1

      One of the signature enhancements in WebLogic Server 12.2.1 is support for multi-tenancy. Some of the key additions to WebLogic for multi-tenancy are in the configuration and runtime areas where we have added domain partitions, resource groups, and resource group templates. This post gives you an overview of what these are and how they fit together.

      Domain Partition

      A domain partition (partition for short) is an administrative and runtime slice of a WebLogic domain. In many ways you can think of a partition as a WebLogic micro-container.

      In 12.1.3 and before, you define managed servers and security realms in the domain and you deploy apps and resources to the domain. You target the apps and resources to managed servers and clusters to control where they will run.

      And in 12.2.1 you can still do all that.

      But you can also create one or more partitions in the domain. Each partition will contain its own apps and resources. 

      You can target each partition to a managed server cluster where you want the partition’s apps and resources to run. (More about targeting later.)

      You can start and shut down each partition independently, even if you have targeted multiple partitions to the same cluster. You can have different partitions use different security realms.

      Plus, for each partition you can identify partition administrators who can control that partition. You can begin to see how a partition is a micro-container — a slice of the domain which contains it.

      Resource Group and PaaS

      Suppose you have a set of Java EE applications and supporting resources that are a human resources solution, and you have another set of apps and their resources that are a finance package. In 12.1.3 you would deploy all the apps and all the resources to the domain. You might target them to different clusters — in fact you would have to do that if you wanted to start up and shut down the two packages independently.

      Or, in 12.1.3 you could use separate WebLogic domains — one for the HR apps and one for the finance ones. That would give you more control over targeting and starting and shutting down, but at the cost of running more domains.

      With 12.2.1 we introduce the resource group which is simply a collection of related Java EE apps and resources. You can gather the HR apps and resources into one resource group and collect the finance apps and resources into another resource group.

      Things get even more interesting because each partition can contain one or more resource groups. 

      If you were thinking about running two separate domains before — one domain for HR and one for finance — you could instead use one domain containing two partitions — one partition for HR and one for finance. With our simple example the HR partition would have a resource group containing the HR apps and resources, and the finance partition would have a resource group containing the finance apps and resources.

      In 12.2.1 you actually target each resource group. If it makes sense, you could target the resource groups in both the HR and finance partitions to the same cluster. And, because you can control the partitions independently, you can start or shut down either one without disturbing the other. The managed servers in the cluster stay up throughout. When you start up or shut down a partition, it is the apps and resources in the partition’s resource groups that are started up or shut down, not the entire server.

      People often call this the consolidation use case — you are consolidating multiple domains into one by mapping separate domains to separate partitions in a single consolidated domain. This is also called the platform-as-a-service (PAAS) use case. Each partition is used as a WebLogic “platform” (a micro-container) and you deploy different apps and resources to each.

      Resource Group Template and SaaS

      There is an entirely different way to use partitions and resource groups to solve different sorts of problems, but we need one more concept to do it well.

      Suppose you wanted to offer those HR and finance suites of apps, running in your data center, as services to other enterprises.

      In 12.1.3 you might create a separate domain for each client and deploy the HR and finance apps and resources the same way in each domain. You might use a domain template to simplify your job, but you’d still have the overhead of multiple domains. And one domain template might not work too well if one customer subscribed to your HR service but another subscribed to HR and finance.

      In 12.2.1 terms this sounds like two resource groups — the HR resource group and the finance resource group — but each running once for each of your enterprise customers. Using one partition per client sounds just right, but you would not want to define the two resource group repetitively and identically in each customer's partition.

      WebLogic 12.2.1 introduces the resource group template for just such a situation.

      You define the HR apps and resources in a resource group template within the WebLogic domain. Do the same for the finance apps and resources in another resource group template. Create a partition for each of your enterprise customers, and as before, in each partition, you create a resource group. 

      But now the resource group does not itself define the apps and resources but instead ">references the HR resource group template. And, if one customer wants to use both suites you create a second resource group in just that customer's partition, linked to the second resource group template.

      When you start the partition corresponding to one of your customers, WebLogic essentially starts up that customer's copies of the apps and resources as defined in the resource group template. When you start another client’s partition, WebLogic starts that customer's copies of the apps and resources.

      This is the classic software-as-a-service (SAAS) use case. And, if you replace the word “customer” with the word “tenant” in this description you see right away how simply WebLogic 12.2.1 supports multi-tenancy through partitions, resource groups, and resource group templates.

      There are other ways to use resource group templates besides offering packaged apps as a service for sale to others, but this example helps to illustrate the basics of how you can use these new features in WebLogic Server together to solve problems in whole new ways.

      Some Details

      The multi-tenancy support in WebLogic 12.2.1 is very rich. We’ve just scratched the surface here in this posting, and as you might expect there are other related features that make this all work in practice. This posting is not the place to cover all those details, but there are a few things I want to mention briefly.

      Resource Overriding

      About the SAAS use case you might be thinking “But I do not want each tenant’s partition configured exactly the same way as set up in the resource group template. For example, different tenants need to use different databases, so the JDBC connection information has to be different for different partitions.”

      WebLogic 12.2.1 lets you create overrides of the settings for apps and resources that are defined in a resource group template, and you can do so differently for each partition. For common cases (such as JDBC connection information) these overrides expose the key attributes you might need to adjust. For each partition and for each resource within the partition you can set up a separate override.

      We intend these overrides to cover most of the cases, but if you need even more control you can create — again, separately for each partition — a resource deployment plan. If you are familiar with application deployment plans in WebLogic the idea is very much the same, except applied to the non-app resources defined in resource group templates.

      To illustrate, here is what WebLogic does  conceptually, at least  when you start a partition containing resource groups linked to resource group templates:

      • The system reads all the resource settings from the resource group template.
      • If there is a resource deployment plan for the partition, the system applies any adjustments in the plan to the resource settings.
      • Finally, if you have created any overrides for that partition, the system applies them.
      • WebLogic uses the resulting resource settings to create that partition’s copies of the resources defined by the template.


      In this post I’ve mentioned targeting but WebLogic 12.2.1 lets you set up targeting of partitions and resource groups ranging from simple to very sophisticated (if you need that). My colleague Joe DiPol has published a separate posting about targeting.

      What Next?

      Here is the WebLogic Server 12.2.1 documentation that describes all the new features, and this part specifically describes the new multi-tenancy features. 

      Remember to check out Joe DiPol's posting about targeting

      For even more about the release of WebLogic Server please browse other postings on the WebLogic Server blog

      Monday Oct 26, 2015

      WLS Data Source Multitenancy

      See the  Blog announcing Oracle WebLogic Server 12.2.1 for more details on Multenacy and other new features.

      The largest and most innovative feature in WebLogic Server (WLS) 12.2.1 is Multitenancy.  It is integrated with every component in the application server.  As part of the Multi-tenancy effort one of the key concepts being introduced is the notion of a slice of the domain which is referred to as a Partition or Domain Partition.  A Partition defines applications and resources for a specific Tenant where each Partition's configuration and runtime are isolated from other Partitions in the Domain.  Multi-tenancy is expected to reduce administrative overhead associated with managing multiple domains and application deployments, and to improve the density of these deployments, such that operational and infrastructure costs are reduced.

      The concepts of the WLS MT feature are described WebLogic Server Multitenant (MT).  The details for MT data source are in the Configuring JDBC  chapter.  This article summarizes the use of data sources in a MT environment and focuses on finding your way around the administrative console and Fusion Middleware Control.

      When working without the WLS Multi Tenant feature, a data source (DS) may be defined as a system resource or deployed at the domain level. When using the Multi Tenant feature, a data source may also be defined in the following scopes.

      • Domain
        • DS with global scope
        • Domain-level Resource Group with DS with global scope
        • Domain-level Resource Group Template with DS
        • Partition
          • Partition-level Resource Group with DS
          • Partition-level Resource Group based on Resource Group Template
          • Partition-level JDBC System Resource Override
          • Partition-level Resource Deployment Plan
          • Object deployed at the partition level

      The following table summarizes the various deployment types and the mechanism to update or override the data source definition.

      Data Source Deployment Type

      Parameter Override Support

      Domain-level System Resource, optionally scoped in RG

      No override support – change the DS directly.

      RGT System Resource

      Change the DS directly or override in the RG derived from the RGT

      Partition-level System Resource in RG

      No override support – change the DS directly.

      Partition-level System Resource in a RG based on RGT

      JDBC System Override or Resource deployment plan.

      Application Scoped/Packaged Data Source deployed to domain or partition

      Application Deployment plan.

      Standalone Data Source Module deployed to domain or partition

      Application Deployment plan.

      Data Source Definitions (Java EE 6) deployed to domain or partition

      No override support.

      Creating a data source that is scoped to a Domain-level RG or in a Partition is similar to creating a domain-level system resource. The only additional step is to specify the scope. In the administration console or Fusion Middleware Control (FMWC), there is a drop-down on the first step of creation that lists the available scopes in which to create a data source. In WLST, it’s necessary to create the data source using createJDBCSystemResource on the owner MBean (the MBean for the domain, RG, or RGT).

      The WLST example at Configuring JDBC Data Sources: WLST Example is very useful in setting up a partitioned domain. It demonstrates creating a virtual target, partition, RGT, RG, and data sources at all levels.

      The remainder of this article focuses on the graphical user interfaces. 

      In the administration console, start by selecting the Data Source summary from the Home page. In this first figure, we see the four data sources that were created by running the WLST script.  One is global and the remaining three have various scopes within the partition. 

      If we click on the “ds-using-template” data source and look at the connection pool properties, we see the original values for the data source based on the template.  The overrides don’t show up at this level.

      Selecting New on the Data Source Summary page and creating a Generic Data Source, we can see the drop-down Scope on the first page.  It changes based on the scopes that are currently available.

      Back on the Home page, we can select Domain Partitions and we see the one “partition1” partition with two resource groups.

      If we click on “partition1” and go to the overrides page, we can see the JDBC override for “ds-in-template”. Note that the URL has now been overridden from using “otrade” to “otrade2”.

      Clicking on the “ds-in-template’ link allows for changing the overrides. Note that on this page, we can also see that the user has been overridden to be “scott”.

      You can create a new JDBC System Resource Override by selecting New. The drop-down box for Data Source lists the available resources for creating the override. The administration console currently lists all RG in the partition. However, the intent is that only RG derived from RGT should be allowed to have an override. Non-derived RG should be updated directly so it’s recommended not to override such groups (it may be removed in the future).

      Going back to the Home page, Data Sources, select a Data Source, select Security, select Credential Mappings, then New, we can enter new User, Remote User, Remote Password triplets

      It’s possible to look at lists of data sources at various levels. From the domain level, the monitoring tab on the Data Sources page shows all running data sources in all scopes.

      From the Partition page selecting “partition1”, select Resource Group, select “partition1-rg”, select Services, select JDBC, we see the one data source defined in this scope.

      Partition-scoped deployments are handled as with non-partition scoped deployments, you start by selecting Deployments from the Home page and then find the ear or war file that you want to deploy. On the first page of the “Install Application Assistant”, you can select the Scope as shown in the following figure.

      Once you finish deploying the ear or war file, you can see the associated modules in the console, with the associated scope by clicking on the associated link. Initially there is no deployment plan.

      Creating an application deployment plan is a bit complex.  It's recommended to use the administration console to create it automatically.  Simply go to the deployed data source, change the configuration, and save the changes.  The console creates the associated deployment plan and fills in the Deployment Plan name.

      If you want to override attributes of a RGT-derived partition datasource that are not one of user, password, or URL, you will need to create a Resource Deployment Plan. There is no automation in the console for doing this. You can massage an Application Deployment Plan to look like a Resource Deployment Plan or create one from scratch using an XML editor. Here is an equivalent Resource Deployment Plan.  To use the resource deployment plan, go to Home, Domain Partitions, click on the Partition link, and type in the pathname in the Resource Deployment Plan Path.

      The capabilities in FMWC are similar to the administrative console but with a different look and feel. FMWC currently does not have security pages; data source security configuration must be done in the administration console.

      If you select JDBC Data Sources from the WebLogic Domain drop-down, you will see something like this.

      Selecting Create brings up a page that includes a Scope drop-down.

      Selecting a resource group name brings up a page to edit the RG.

      Selecting an existing DS brings up a page to edit the DS.

      Selecting a partition name brings up a page to edit the Partition attributes.

      If you are looking for the Partition system resource overrides, select the partition name, select the Domain Partition drop-down, select Administration, then select Resource Overrides.

      The page looks like this.

      This page will list every RG that is derived from a RGT. If there is no existing override, the “Has Overrides” column will not have a check and clicking on “Edit Overrides” will create a new override. If “Has Overrides” has a check, clicking on “Edit Overrides” will update the existing overrides, as in the following figure.

      The focus of this article has been on configuration of data sources in a Multi Tenant environment.  It is the intent that using an application in a Multi Tenant environment should be largely transparent to the application software.  The critical part is to configure the application server objects and containers to be deployed in the partitions and resource groups where they are needed.

      Wednesday Jul 29, 2015

      WebLogic Update @ Voxxed Days Istanbul

      It's relatively rare Java focused conferences have clearly WebLogic centric sessions. This is understandable as conference organizers must carefully balance between education, vendor-neutrality, sharing useful information and outright sales pitches. The distinction is very tenuous and historically frequently abused at Java conferences. As a result Java conference organizers (and attendees) often choose to err on the side of caution and avoid content focused on commercial products (note that while WebLogic is beyond a doubt a commercially licensed product developers can use it freely on their own local machines with an OTN license). An unfortunate side effect of this problem is that many developers remain woefully unaware of the changes happening in mission critical bits of industry infrastructure such as WebLogic. The exception to this unfortunate situation is events like Oracle OpenWorld and other Oracle technology centric conferences where WebLogic is far better represented.

      For these reasons it was a breadth of fresh air to be able to deliver a brief WebLogic centric session at Voxxed Days Istanbul 2015. I am so grateful to the organizers for lending me the benefit of the doubt and recognizing the distinction between selling and informing current/prospective users about important technological changes that can help their organizations. Titled "What's New in WebLogic 12.1.3 and Beyond", the talk essentially covers the very important hard work that we have already done in WebLogic 12.1.3 including supporting some of the most critical Java EE 7 APIs as well as the fundamental changes coming soon in WebLogic 12.2.1 including full Java EE 7 platform support. Below is the slide deck for the talk (click here if you can't see the embedded slide deck.):

      If you have not yet taken a look at WebLogic 12.1.3 and the road map for 12.2.1, the deck should offer a quick way to do so. Here is the abstract for the talk to give you better context:

      WebLogic 12.1.3 was released about a year ago. It brings a large set of changes including support for some key new Java EE 7 APIs such as WebSocket, JAX-RS 2, JSON-P and JPA 2.1, support for Java SE 8, WebSocket fallback support, support for Server-Sent Events (SSE), improved Maven support, enhanced REST administration support, Oracle Database 12c driver support and much, much more. In this session we will take a detailed tour of these features. In addition we will also cover updated WebLogic support in the Oracle Cloud, the new Oracle public Maven repository, using WebLogic with Arquillian for testing and well as official Docker support for WebLogic. Towards the end of the session we will discuss what's coming in WebLogic 12.2.1 this year including full support for Java EE 7, multi-tenancy and more.

      Besides the brief WebLogic talk I also covered Java EE 7 and Java EE 8 at Voxxed Days Istanbul as well as the Istanbul and Ankara JUG. More details of the event are posted on my personal blog.

      Friday Jul 17, 2015

      Accessing WebLogic Logs via REST

      One of the most significant changes in the WebLogic 12.1.3 release is improvements in the REST management interface. Oracle ACE Director and WebLogic expert Dr. Frank Munz does a very nice job summarizing the changes on his blog. The REST management capability is really quite a nice addition to the existing DevOps oriented capabilities such as WLST and of course the admin console. One of the very interesting things you can do via the REST management interface in WebLogic 12.1.3 is easily access all WebLogic logs. Dr. Frank Munz explains nicely step by step how to do this via another excellent blog entry well worth a read.

      The best way to learn the details of the REST management capabilities is of course always the WebLogic documentation.

      Thursday Jun 18, 2015

      Managing Logs in WebLogic

      Logging is your first line of defense in terms administering, debugging and monitoring any part of the data center and especially the application server. WebLogic generates a number of very helpful log files for that reason. In addition WebLogic also provides ways to robustly manage these log files in terms of tuning things like log rotation and filtering. Ahmed Aboulnaga introduces some of these capabilities in a recent article on OTech Magazine (his article is mostly focused on the admin console).

      The most detailed and up-to-date way to learn about WebLogic logging is always of course the WebLogic documentation. For example a couple of important logging aspects the article does not get into include configuring the logs themselves as well as easily viewing the logs through the WebLogic console.

      Tuesday Jun 09, 2015

      Your Spring application takes longer to deploy? Think again!

      Uday Joshi of the WebLogic Team was recently asked to understand why a large Spring based application took longer to deploy on WebLogic than on Tomcat. And to do that, Uday only had one constraint, i.e. he was not given access to that Spring application! The only thing Uday had at his disposal was the deployment-time thread dumps of that application, nothing else.

      In this detailed article, Uday describes how he mimicked the 'suspicious' application to understand what was going on. He also shares some of his findings and some recommendations like using filtering classloader. This article is based on a large Spring application but those recommendations also apply to any large application. 

      Friday Jun 05, 2015

      A Gentle Introduction to the WebLogic Diagnostic Framework (WLDF)

      The WebLogic Diagnostic Framework (WLDF) is a powerful feature that has been around since WebLogic 9. It is an extremely robust way of live monitoring and diagnostics for the server, the underlying JVM, deployed applications and configured resources. Few if any other Java application servers can match the capabilities offered by WLDF. If you using WebLogic in production and don't know about WLDF, you are doing yourself a serious disservice.

      Because of the power and flexibility offered by WLDF, it is not trivial to pick up and for some can be daunting. Fortunately Mike Croft of Oracle partner C2B2 consulting can help us out. He wrote up a very nice series of blog entries as a gentle introduction to WLDF. He provides a high level overview and discusses watches, notifications and the monitoring dashboard. The definitive way to learn about WLDF is of course always the latest WebLogic documentation :-).

      Monday May 18, 2015

      WLS Tip: Getting started with Arquillian on WebLogic Server

      Arquillian is a popular open-source testing framework for Java EE containers. In this short video, Phil Zampino of the Oracle WebLogic Server Development Team shows how to get started with Arquillian to test applications running in WebLogic Server. For a more details on using Arquillian with WebLogic, you can then check this article.

      For your convenience, you can also download this archive that contains the test application and the configuration files (pom.xml & arquillian.xml) used in the video.

      Wednesday Apr 15, 2015

      WLS Tip: Installing WebLogic with Chef

      Chef is a popular open source infrastructure automation framework that has been popularized with the whole DevOps movement. In a nutshell, Chef has the notion of Recipe and Cookbook. A Recipe is written using a Ruby based DSL to describe how to install and configure software(s) on a host. And as the name suggest, a Cookbook is a collection of related Recipes.

      This article explains how to create a simple WebLogic Cluster (on a VM) with two Managed Servers using Chef. The Cookbook described in the article can obviously be used as the basis for more advanced scenarios involving WebLogic.

      Thursday Apr 02, 2015

      An Introduction to WLST Script Profiles

      In case you are not familiar with WLST (the WebLogic Scripting Tool), it is a powerful scripting runtime for administering WebLogic domains. Jython is used as the scripting language. Although other application servers now boast similar capabilities, WebLogic was one of the earliest to innovate this feature around 2006 with WebLogic 9. In fact, WLST maintains the most impressive set of features compared to competing offerings.

      WLST is of course just one way of administering WebLogic. You can also work with WebLogic domains using Ant, Maven, the command line and of course the user-friendly admin console depending on your needs and preferences. WLST is particularly useful for automating entire deployment environments or complex administration scenarios. Matt Brasier of C2B2 Consulting (an Oracle partner) recently did an excellent talk on WLST. The slide deck for his talk is embedded below:

      We also recently caught up with Peter Bowers, a key developer on the WebLogic team about WLST. He talked to us about the WLST script profile feature, including some cool sample code and a demo. Here's the video with Peter:

      The best place to learn more about WLST is none other than the excellent latest WebLogic docs on the topic.

      Tuesday Jan 20, 2015

      WLS Tip: Introduction to WLST

      WLST (WebLogic Scripting Tool) is one of the many WebLogic features that ease the management and administration of WLS instances. It is a command line based tool that can be used to create, manage, and monitor WebLogic domains.  WLST has a set of WLS specific commands (e.g. deploy an application - see here for the whole commands list), so creating WLS automated tasks is really easy. And since WLST is running on the JVM (*), those various scripted WLS taks can be easily integrated in the overall infrastructure (e.g. build platform, management infrastructure).

      Mark Piller has recently written an technical introduction to WLST. In his article, Mark explains how to write WLST scripts.

      You can also watch this WLST tutorial video produced by Frank Munz.

      (*) Technically, WLST is using Jython on top of the JVM. 

      Wednesday Jan 14, 2015

      WebLogic Server Plug-in for Java Mission Control: installation

      Java Mission Control (JMC) and Java Flight Recorder (JFR) provide a complete tool chain to continuously collect low level and detailed runtime information of Java applications enabling after-the-fact incident analysis.  The WebLogic Team has developed a WLS Plug-in for Java Mission Control.  This Plug-in provides custom WLS views that can be used to analyze more efficiently the contents of Flight Recordings produced by WebLogic instances (e.g. database queries, EJB calls, servlet invocations, etc.).

      In the following short video, Tony Vlatas of the WebLogic Development Team explains how to install the WebLogic Server Plug-in in Java Mission Control.  You'll see that it's very simple! 

      Java Mission Control and Java Flight Recorder combined with this Plug-in enables WLS developers and administrators to collect and easily analyse data from WebLogic instances running locally or instances deployed in production environments.  At this stage, the WLS Plug-in is still considered as experimental but it's worth giving it a try!


      The official blog for Oracle WebLogic Server fans and followers!

      Stay Connected


      « November 2015