Please note that the specifications and other information contained herein are not final and are subject to change. The information is being made available to you solely for purpose of evaluation.
Java™ Platform
Standard Ed. 8

DRAFT ea-b92


Provides the definition of the monitor classes.

See: Description

Package Description

Provides the definition of the monitor classes. A Monitor is an MBean that periodically observes the value of an attribute in one or more other MBeans. If the attribute meets a certain condition, the Monitor emits a MonitorNotification. When the monitor MBean periodically calls getAttribute to retrieve the value of the attribute being monitored it does so within the access control context of the Monitor.start() caller.

The value being monitored can be a simple value contained within a complex type. For example, the MemoryMXBean defined in has an attribute HeapMemoryUsage of type MemoryUsage. To monitor the amount of used memory, described by the used property of MemoryUsage, you could monitor "HeapMemoryUsage.used". That string would be the argument to setObservedAttribute.

The rules used to interpret an ObservedAttribute like "HeapMemoryUsage.used" are as follows. Suppose the string is A.e (so A would be "HeapMemoryUsage" and e would be "used" in the example).

First the value of the attribute A is obtained. Call it v. A value x is extracted from v as follows:

The third rule means for example that if the attribute HeapMemoryUsage is a MemoryUsage, monitoring "HeapMemoryUsage.used" will obtain the observed value by calling MemoryUsage.getUsed().

If the ObservedAttribute contains more than one period, for example "ConnectionPool.connectionStats.length", then the above rules are applied iteratively. Here, v would initially be the value of the attribute ConnectionPool, and x would be derived by applying the above rules with e equal to "connectionStats". Then v would be set to this x and a new x derived by applying the rules again with e equal to "length".

Although it is recommended that attribute names be valid Java identifiers, it is possible for an attribute to be called HeapMemoryUsage.used. This means that an ObservedAttribute that is HeapMemoryUsage.used could mean that the value to observe is either an attribute of that name, or the property used within an attribute called HeapMemoryUsage. So for compatibility reasons, when the ObservedAttribute contains a period (.), the monitor will check whether an attribute exists whose name is the full ObservedAttribute string (HeapMemoryUsage.used in the example). It does this by calling getMBeanInfo for the observed MBean and looking for a contained MBeanAttributeInfo with the given name. If one is found, then that is what is monitored. If more than one MBean is being observed, the behavior is unspecified if some of them have a HeapMemoryUsage.used attribute and others do not. An implementation may therefore call getMBeanInfo on just one of the MBeans in this case. The behavior is also unspecified if the result of the check changes while the monitor is active.

The exact behavior of monitors is detailed in the JMX Specification. What follows is a summary.

There are three kinds of Monitors:

See Also:
Java Platform documentation on JMX technology, in particular the JMX Specification, version 1.4(pdf).
Java™ Platform
Standard Ed. 8

DRAFT ea-b92

Submit a bug or feature
For further API reference and developer documentation, see Java SE Documentation. That documentation contains more detailed, developer-targeted descriptions, with conceptual overviews, definitions of terms, workarounds, and working code examples.
Copyright © 1993, 2013, Oracle and/or its affiliates. All rights reserved.

DRAFT ea-b92 - all specs in one place