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 {@link javax.management.monitor.MonitorNotification MonitorNotification}. When the monitor MBean periodically calls {@link javax.management.MBeanServer#getAttribute getAttribute} to retrieve the value of the attribute being monitored it does so within the access control context of the {@link javax.management.monitor.Monitor#start} caller.

The value being monitored can be a simple value contained within a complex type. For example, the {@link java.lang.management.MemoryMXBean MemoryMXBean} defined in {@code java.lang.management} has an attribute {@code HeapMemoryUsage} of type {@link java.lang.management.MemoryUsage MemoryUsage}. To monitor the amount of used memory, described by the {@code used} property of {@code MemoryUsage}, you could monitor "{@code HeapMemoryUsage.used}". That string would be the argument to {@link javax.management.monitor.MonitorMBean#setObservedAttribute(String) setObservedAttribute}.

The rules used to interpret an {@code ObservedAttribute} like {@code "HeapMemoryUsage.used"} are as follows. Suppose the string is A.e (so A would be {@code "HeapMemoryUsage"} and e would be {@code "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 {@code HeapMemoryUsage} is a {@code MemoryUsage}, monitoring {@code "HeapMemoryUsage.used"} will obtain the observed value by calling {@code MemoryUsage.getUsed()}.

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

Although it is recommended that attribute names be valid Java identifiers, it is possible for an attribute to be called {@code HeapMemoryUsage.used}. This means that an {@code ObservedAttribute} that is {@code HeapMemoryUsage.used} could mean that the value to observe is either an attribute of that name, or the property {@code used} within an attribute called {@code HeapMemoryUsage}. So for compatibility reasons, when the {@code ObservedAttribute} contains a period ({@code .}), the monitor will check whether an attribute exists whose name is the full {@code ObservedAttribute} string ({@code HeapMemoryUsage.used} in the example). It does this by calling {@link javax.management.MBeanServer#getMBeanInfo(javax.management.ObjectName) getMBeanInfo} for the observed MBean and looking for a contained {@link javax.management.MBeanAttributeInfo 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 {@code HeapMemoryUsage.used} attribute and others do not. An implementation may therefore call {@code 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 JMX Specification, version 1.4 @since 1.5