Tải bản đầy đủ - 0 (trang)
Table?4-1. Predefined severity values and meanings

Table?4-1. Predefined severity values and meanings

Tải bản đầy đủ - 0trang








Unknown or indeterminate


Critical or failure

Major or severe

Minor, marginal, or error


Normal or informative

You may create your own values for severity, but consider those summarized in Table

4-1 to be reserved. This helps to ensure compatibility between vendors.

Example: "severity=3" value

This field is not required and applies only to attributes. This field acts as a cache for the

current value of the attribute. Each time an attribute's value is accessed or changed, this

field is updated to reflect the current value. This field can be used in conjunction with

currencyTimeLimit to minimize the impact of instrumentation on application

performance, by acting as a cache for get requests of the attribute's current value. When

currencyTimeLimit expires, the next get request for the attribute invokes the attribute's

getter and the value is updated. If you want to set this field value to an Object reference,

you must use the setField() method of the Descriptor object.

Example: "value=SomeStringValue" visibility

This field is not required and provides a built-in abstraction mechanism for MBeans.

There are four predefined values, ranging from 1 to 4. At the least abstract level, 1, the

MBean is nearly always visible to any management application. At the greatest

abstraction level, 4, the MBean is the least visible. The concrete meanings of "nearly

always visible" and "least visible" are not clear in the specification. The meaning of this

field will certainly require some sort of agreement between instrumentation developers

and management application developers and will most likely be firmed up in a future

version (or maintenance release) of the specification.

Example: "visibility=1" Other fields

Three additional fields are predefined by the JMX specification and are considered to be

reserved: presentationString, iterable, and messageID.

The interpretation of the values of each of these fields is covered fairly well (if somewhat

necessarily vaguely) in the JMX specification, and we won't discuss them further here.


Why not? Remember, one of the strengths of descriptors (and hence of model MBeans) is

that they provide a richer set of metadata than is available for dynamic MBeans. The

JMX specification provides general guidelines for interpreting predefined field values,

but it does not constrain the model MBean instrumentation developer or the management

application in terms of exactly how they are to interpret these values.

This openness of field values leads us into our next topic of discussion: user-defined field

values. Are they allowed? Absolutely. The JMX specification does not prohibit the model

MBean instrumentation developer, the agent level developer, or the management

application developer from agreeing on a specific set of field values, as long as they do

not conflict with the reserved field names we have already discussed.

So, how do you create a descriptor? As we have already seen, the Descriptor interface

defines the contract between the instrumentation level and any other level of the JMX

architecture. The JMX implementation must ship with at least one concrete class that

implements the Descriptor interface. In the RI, this class is called DescriptorSupport.

(It is a common pattern in the RI for interfaces to be implemented by classes named by

adding "Support" to the name of the interface.) DescriptorSupport provides several

constructors, but we will only look at a few of the more interesting ones here. Note that in

the following discussion we'll use the terms descriptor, Descriptor, and

DescriptorSupport synonymously (descriptor is a generic term for the Descriptor

interface or a class such as DescriptorSupport that implements it, respectively).

The easiest way to create a descriptor is to use the default constructor:

// . . .

Descriptor desc = new DescriptorSupport();

// . . .

What then? The next step is to set the fields that make up the descriptor, using the

setField() method:

// . . .

import javax.management.Descriptor;

import javax.management.modelmbean.DescriptorSupport;

// . . .

Descriptor desc = new DescriptorSupport();

desc.setField("name", "WorkFactor");

desc.setField("descriptorType", "attribute");

desc.setField("getMethod", "getWorkFactor");

// . . .

DescriptorSupport also provides three constructors that let you do all of this at once.

One lets you pass an XML-like String object that contains the field names and values.

Its signature is:

public DescriptorSupport(String inStr)

throws MBeanException,



// . . .


XMLParseException {

This XML-like String must be of the format:

. . .

where fieldname1 is the name of the first field, fieldvalue1 is its corresponding value,

and so on. Let's use the WorkFactor attribute described earlier to demonstrate how to use

the DescriptorSupport constructor:

// . . .

import javax.management.Descriptor;

import javax.management.modelmbean.DescriptorSupport;

// . . .

String xmlString =

"" +

"" +

"" +

"" +


Descriptor desc = new DescriptorSupport(xmlString);

// . . .

If you think this XML String is not well formed, you are correct;

notice that what appear to be XML attributes in the field tag are not

surrounded by single or double quotes. I am not certain if this is

intentional—if it's simply an oversight, it will certainly be fixed in a

future version of the JMX RI. Regardless, this is how the JMX RI

behaves, so it deserves mention.

If you need to set a number of fields whose values are String objects, you can create a

String array and pass it to another DescriptorSupport constructor. This constructor's

signature is:

public DescriptorSupport(String[] fields) {

// . . .


The String objects in the array are of the format name=value, where name is the name

of the field and value is its String value. Using the WorkFactor example again, here's

how to create a descriptor with this constructor:

// . . .


import javax.management.Descriptor;

import javax.management.modelmbean.DescriptorSupport;

// . . .

String[] fields = new String[] {





Descriptor desc = new DescriptorSupport(fields);

// . . .

This constructor parses through the String objects in the array and sets each field


The third and final constructor we'll look at in this section takes two arguments: a String

array containing the names of the fields and an Object array containing references to the

objects that represent the field values. The signature for this constructor is:

public DescriptorSupport(String[] fieldNames, Object[] fieldValues)

throws RuntimeOperationsException {

// . . .


Note that the number of items in the String array must match the number of items in the

Object array, or none of the fields will be set for the descriptor you are trying to create.

Let's again use the WorkFactor attribute from earlier to demonstrate how to use this


// . . .

import javax.management.Descriptor;

import javax.management.modelmbean.DescriptorSupport;

// . . .

String[] fieldNames = new String[] {

"name", "descriptorType", "getMethod"


Object[] fieldValues = new Object[] {

"WorkFactor", "attribute", "getWorkFactor"


Descriptor desc = new DescriptorSupport(fieldNames, fieldValues);

// . . .

We used an attribute here to demonstrate how to create descriptor objects, but the

principles are exactly the same for an MBean, operation (including a constructor), or

notification. The only differences are the allowable field names.

A final note about the DescriptorSupport constructors: all of these constructors are

valid ways to create DescriptorSupport objects, and none is preferable over another.

However, the following two constructors will be used most often throughout the rest of

this book:

1. Default constructor, setField() approach


2. String array parameter constructor

Every attempt will be made to give these two constructors equal treatment in the

examples that follow. However, bear in mind that you are free to use any of the

constructors (that is, after all, why they are there) as your needs dictate.

By now you should be familiar with the DescriptorSupport constructors available to

you to create descriptors for your MBeans, attributes, operations, and notifications. While

descriptors provide metadata to other levels of the JMX architecture, as well as to

management applications, we must still provide the MBean server with metadata classes

that satisfy the DynamicMBean behavior of our model MBeans. In the next section, we

will look at how to create the metadata classes that are required to describe the

management interface to the MBean server.

4.2.2 Describing the Management Interface

As with dynamic MBeans, every feature of a model MBean, including the MBean itself,

must have a corresponding metadata class. Furthermore, for model MBeans, each

metadata class must contain a descriptor. In this section, we will examine the metadata

classes that are used to describe the management interface of your managed resource.

You may notice a similarity between the layout of this section and the corresponding

section in Chapter 3. Recall that a model MBean implements the DynamicMBean interface,

so it should be no surprise that model MBean metadata classes resemble their dynamic

MBean counterparts. In fact, as we will see, each of the model MBean metadata classes

(with the exception of ModelMBeanInfo, which is an interface) extends the corresponding

dynamic MBean metadata class.

There are five metadata classes of interest:


Each instance of this class describes one attribute of the MBean's management



Each instance of this class describes one of the MBean's public constructors and

may contain one or more MBeanParameterInfo instances (MBeanParameterInfo

was discussed in detail in the previous chapter).


Each instance of this class describes one of the operations on the MBean's

management interface and may contain one or more MBeanParameterInfo




Each instance of this class describes one group of notifications emitted by the



The top-level container of metadata. This class implements the ModelMBeanInfo

interface, which is how the agent level and management applications access the

metadata for a model MBean. Each MBean requires only one instance of this

class to completely describe its management interface.

As mentioned earlier, each of these metadata classes (with the exception of

ModelMBeanInfo) extends its dynamic MBean counterpart. These relationships are

shown in Figure 4-1 in UML notation.

Figure 4-1. UML diagram showing inheritance of model MBean metadata classes from

dynamic MBean metadata classes

As shown in Figure 4-2, the relationships between model MBean metadata classes are

similar to those between dynamic MBean metadata classes.

Figure 4-2. UML diagram showing the relationships between ModelMBeanInfoSupport and

the other model MBean metadata classes


As with dynamic MBeans, the aggregation mechanism used in MBeanInfoSupport for

each MBean feature is an array. As we saw in Figure 4-1, all of the model MBean

metadata classes extend their dynamic MBean counterparts and are able to take

advantage of the basic structure contained in them. We will discuss each of the model

MBean classes below. MBeanParameterInfo is discussed at length in the previous

chapter, so we will not cover it here.

Recall from our discussion of the DescriptorSupport class and the Descriptor

interface that it does not matter whether the descriptor fields are created in a String

array and passed to the DescriptorSupport constructor or created with the setField()

method of Descriptor. Both approaches will be used in the examples throughout the rest

of this chapter to demonstrate that they are equally valid. ModelMBeanAttributeInfo

All but one of the essential properties that must be set for a model MBean attribute are

the same as those that must be set for a dynamic MBean attribute, so they will not be

discussed here. The lone exception is the descriptor that must be set for a model MBean

attribute. Recall from the previous chapter that there are two constructors that are used to

set the essential properties for an MBeanAttributeInfo instance. One of these

constructors uses the Java reflection API, and the other explicitly sets all of the essential

properties. These same properties (in addition to the descriptor) exist on

ModelMBeanAttributeInfo, which inherits from MBeanAttributeInfo. Four

constructors are available to you on ModelMBeanAttributeInfo, as shown in Example


Example 4-2. The significant constructors of ModelMBeanAttributeInfo

// . . .

public class ModelMBeanAttributeInfo extends MBeanAttributeInfo

implements DescriptorAccess, Cloneable {

// . . .

public ModelMBeanAttributeInfo(String name,

String description,

Method getter,

Method setter)

throws javax.management.IntrospectionException {

// . . .


public ModelMBeanAttributeInfo(String name,

String description,

Method getter,

Method setter,

Descriptor descriptor)

throws javax.management.IntrospectionException {

// . . .


public ModelMBeanAttributeInfo(String name,

String type,

String description,

boolean isReadable,


Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Table?4-1. Predefined severity values and meanings

Tải bản đầy đủ ngay(0 tr)