Configuring and Using the WebLogic Diagnostics Framework

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Using Wildcards in Expressions

WLDF allows for the use of wildcards in instance names within the <harvested-instance> element, and also provides drill-down and wildcard capabilities in the attribute specification of the <harvested-attribute> element.

WLDF also allows the same wildcard capabilities for instance names in Harvester watch rules, as well as specifying complex attributes in Harvester watch rules.

These capabilities are discussed in the following sections:


Using Wildcards in Harvester Instance Names

When specifying instance names within the <harvested-instance> element, you can:


The instance specification in Listing C-1 indicates that all instances of the WorkManagerRuntimeMBean are to be harvested. This is equivalent to not providing an instance-name qualification at all in the <harvested-type> declaration.

Listing C-1 Harvesting All Instances of an MBean

The example in Listing C-2 shows a JMX ObjectName pattern as the <harvested-instance> value:

Listing C-2 Using a JMX ObjectName Pattern

In the example shown in Listing C-3, some of the values in the ObjectName property list contain wildcards:

Listing C-3 Using Wildcards in the Property List

The example in Listing C-4 indicates that all harvestable attributes of all instances of com.acme.CustomMBean are to be harvested, but only where the instance name contains the string “Name=mybean”.

Listing C-4 Harvesting All Attributes of Multiple Instances


Specifying Complex and Nested Harvester Attributes

The Harvester provides the ability to access metric values nested within complex attributes of an MBean. A complex attribute can be a map or list object, a simple POJO, or different nestings of these types of objects. For example:

In addition, wildcards can be used for list indexes and map keys to specify multiple elements within a collection of those types. The following wildcards are available:

You can also specify a discrete set of key values by using a comma-separated list.

For example:

In the last example, where the ‘*’ wildcard is used for the index to a list and as the key value to a nested map object, nested arrays of values are returned.

If you embed the ‘*’ wildcard in a comma-separated list of map keys, such as:


it is equivalent to specifying all map keys:

Notes: Leading or trailing spaces will be stripped from a map key unless the map key is enclosed within quotation marks.
Note: Using a map key pattern can result in a large number of elements being scanned and/or returned. The larger the number of elements in a map, the bigger the impact there will be on performance.
Note: The more complex the matching pattern is, the more processing time will be required.


To use drill-down syntax to harvest the nested State property of the HealthState attribute on the ServerRuntime MBean, you would use the following diagnostic descriptor:

Listing C-5 Using drill-down syntax

To harvest the elements of an array or list, the Harvester supports a subscript notation wherein a value is referred to by its index position in the array or list. For example, to refer to the first element in the array attribute URLPatterns in the ServletRuntimeMBean, specify URLPatterns[0]. If you want to reference all the elements of URLPatterns using a wildcard:

Listing C-6 Using a wildcard to reference all elements of an array

To harvest the elements of a map, each individual value is referenced by the key enclosed in parentheses. Multiple keys can be specified as a comma-delimited list, in which case the values corresponding to specified keys in the map will be harvested.

The following code example harvests the value from the map with key Foo:


The next example harvests the value from the map with keys Foo and Bar:


The next example uses the % character with a key specification to harvest all values from the map if their keys start with Foo and end with Bar:


The next example harvests all values from a map by using the * character:


In the next example, the MBean has a JavaBean attribute MyBean which has a nested map type attribute MyMap. This code example harvests this value from the map whose key is Foo:



Using the Accessor with Harvested Complex or Nested Attributes

While a large number of complex or nested attributes can be specified as a single expression in terms of the Harvester and Watch and Notifications configuration, the actual metrics are persisted in terms of each individually gathered metric.

For example, if the attribute specification:


maps to the following actual nested attributes:


then each of these six metrics are stored in a separate record in the HarvestedDataArchive, with the shown attribute names stored in the ATTRNAME column in each corresponding record. The values in the ATTRNAME column are the values you must use in Accessor queries when retrieving them from the archive.

Here are some example query strings:

  NAME=”foo:Name=MyMBean” ATTRNAME=”mymap(key1).a”
  NAME=”foo”Name=MyBean” ATTRNAME LIKE “mymap(%).a”
  NAME=”fooName=MyMBean” ATTRNAME MATCHES “mymap\((.*?)\).a”


Using Wildcards in Watch Rule Instance Names

Within Harvester watch rules, you can use the ‘*’ wildcard to specify portions of an ObjectName, giving you the ability to watch for multiple instances of multiple types.

For example, to specify the OpenSocketsCurrentCount attribute for all instances of the ServerRuntimeMBean that begin with the name managed, use the following syntax:


Alternatively, you can use JMX ObjectName query patterns, as shown here:

Note: The ObjectName query pattern syntax supported by the Harvester will be whatever is supported by the underlying JMX implementation. The above example demonstrates syntax supported by JDK 5 and later. Refer to the JavaDoc for for the specific JDK version being used to run the server for the full syntax that is supported.


Specifying Complex Attributes in Harvester Watch Rules

You can specify complex attributes (a collection, an array type or an Object with nested intrinsic attribute types) within Harvester watch rule expressions. There are several ways to do this.

The following example shows a drill-down into a nested attribute in a complex type, which is then checked to see if it is greater than 0:

${somedomain:name=MyMbean//complexAttribute.nestedAttribute} > 0 

You can also use wildcards to specify multiple Map keys. The following wildcards are available for specifying complex attributes:

In addition, you can use a comma-separated list to specify a discrete set of key values.

In this example:

${[]//aList[*].(some%partialKey%).(aValue,bValue)} > 0

the rule would examine all elements of the aList attribute on all instances of the, drilling down into a nested map for all keys starting with the text some and containing the text partialKey afterwards. The returned values are assumed to be Map instances, from which values for the keys aValue and bValue will be compared to see if they are greater than 0.

When using the MethodInvocationStatistics attribute on the WLDFInstrumentationRuntime type, the system needs to determine the type from the variable. If the system can’t determine the type when validating the attribute expression, the expression won’t work. For example, the expression:

${ com.bea:Name=myScope, * //MethodInvocationStatistics.(...).(...) 

will not work. You must explicitly declare the type in this situation, as shown in this code example, which drills down into the nested map structure:

$(com.bea:Name=hello,Type=WLDFInstrumentationRuntime,*//MethodInvocationStatistics(*)(*)(*)(count)) >= 1

  Back to Top       Previous  Next