* A platform MXBean is a managed bean that @@ -158,10 +158,10 @@ * * * - * - * + * + * *
A Java virtual machine implementation may add its platform extension to * the management interface by defining platform-dependent * interfaces that extend the standard management interfaces to include @@ -193,46 +193,46 @@ * for (com.sun.management.GarbageCollectorMXBean gc : mxbeans) { * // Get the standard attribute "CollectionCount" * String count = mxbean.getCollectionCount(); - * + * * // Get the platform-specific attribute "LastGcInfo" * GcInfo gcinfo = gc.getLastGcInfo(); * ... * } * * - * + * *
* 2) Access the Oracle-specific MXBean interface via MBeanServer
* through proxy
- *
+ *
*
* MBeanServerConnection mbs;
- *
+ *
* // Connect to a running JVM (or itself) and get MBeanServerConnection
* // that has the JVM MXBeans registered in it
* ...
- *
+ *
* List<com.sun.management.GarbageCollectorMXBean> mxbeans =
* ManagementFactory.getPlatformMXBeans(mbs, com.sun.management.GarbageCollectorMXBean.class);
- *
+ *
* for (com.sun.management.GarbageCollectorMXBean gc : mxbeans) {
* // Get the standard attribute "CollectionCount"
* String count = mxbean.getCollectionCount();
- *
+ *
* // Get the platform-specific attribute "LastGcInfo"
* GcInfo gcinfo = gc.getLastGcInfo();
* ...
* }
* Unless otherwise noted, passing a null argument to a constructor
* or method in any class or interface in this package will cause a {@link
* java.lang.NullPointerException NullPointerException} to be thrown.
- *
+ *
*
The java.lang.management API is thread-safe. - * + * * @see javax.management JMX Specification - * + * * @author Mandy Chung * @since 1.5 */ diff --git a/src/java.management/share/classes/javax/management/modelmbean/package-info.java b/src/java.management/share/classes/javax/management/modelmbean/package-info.java index 5e48117a437fc..65a4d0c3438c9 100644 --- a/src/java.management/share/classes/javax/management/modelmbean/package-info.java +++ b/src/java.management/share/classes/javax/management/modelmbean/package-info.java @@ -33,7 +33,7 @@ * reused many times with different management interfaces and * managed resources, and it can provide common functionality * such as persistence and caching.
- * + * *A Model MBean implements the {@link * javax.management.modelmbean.ModelMBean ModelMBean} interface. * It is a {@link javax.management.DynamicMBean DynamicMBean} @@ -41,7 +41,7 @@ * getMBeanInfo} method returns an object implementing {@link * javax.management.modelmbean.ModelMBeanInfo * ModelMBeanInfo}.
- * + * *Every MBean has an {@link javax.management.MBeanInfo
* MBeanInfo} with information about the MBean itself, and its
* attributes, operations, constructors, and notifications. A
@@ -51,12 +51,12 @@
* Usually, Descriptors are instances of {@link
* javax.management.modelmbean.DescriptorSupport
* DescriptorSupport}.
The class {@link * javax.management.modelmbean.RequiredModelMBean * RequiredModelMBean} provides a standard Model MBean * implementation.
- * + * *The following example shows a Model MBean being used to make
* the get method of a HashMap
* available for management through an MBean server. No other
@@ -64,21 +64,21 @@
* nothing special about HashMap here. Public
* methods from any public class can be exposed for management in
* the same way.
* import java.lang.reflect.Method;
* import java.util.HashMap;
* import javax.management.*;
* import javax.management.modelmbean.*;
- *
+ *
* // ...
- *
+ *
* MBeanServer mbs = MBeanServerFactory.createMBeanServer();
* // The MBean Server
- *
+ *
* HashMap map = new HashMap();
* // The resource that will be managed
- *
+ *
* // Construct the management interface for the Model MBean
* Method getMethod = HashMap.class.getMethod("get", new Class[] {Object.class});
* ModelMBeanOperationInfo getInfo =
@@ -90,31 +90,31 @@
* null, // no constructors
* new ModelMBeanOperationInfo[] {getInfo},
* null); // no notifications
- *
+ *
* // Make the Model MBean and link it to the resource
* ModelMBean mmb = new RequiredModelMBean(mmbi);
* mmb.setManagedResource(map, "ObjectReference");
- *
+ *
* // Register the Model MBean in the MBean Server
* ObjectName mapName = new ObjectName(":type=Map,name=whatever");
* mbs.registerMBean(mmb, mapName);
- *
+ *
* // Resource can evolve independently of the MBean
* map.put("key", "value");
- *
+ *
* // Can access the "get" method through the MBean Server
* mbs.invoke(mapName, "get", new Object[] {"key"}, new String[] {Object.class.getName()});
* // returns "value"
*
- *
+ *
* 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 @@ -47,37 +47,37 @@ * 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 @@ -86,7 +86,7 @@ * {@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 @@ -107,16 +107,16 @@ * 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:
- * + * *A {@link javax.management.monitor.CounterMonitor * CounterMonitor} observes attributes of integer * type. The attributes are assumed to be non-negative, and @@ -125,59 +125,59 @@ * observed attribute has an associated threshold * value. A notification is sent when the attribute exceeds * its threshold.
- * + * *An offset value can be specified. When an * observed value exceeds its threshold, the threshold is * incremented by the offset, or by a multiple of the offset * sufficient to make the threshold greater than the new * observed value.
- * + * *A CounterMonitor can operate in
* difference mode. In this mode, the value
* compared against the threshold is the difference between
* two successive observations of an attribute.
A {@link javax.management.monitor.GaugeMonitor * GaugeMonitor} observes attributes of numerical type. Each * observed attribute has an associated high * threshold and low threshold.
- * + * *When an observed attribute crosses the high threshold, if * the notify high flag is true, then a notification * is sent. Subsequent crossings of the high threshold value * will not trigger further notifications until the gauge value * becomes less than or equal to the low threshold.
- * + * *When an observed attribute crosses the low threshold, if * the notify low flag is true, then a notification * is sent. Subsequent crossings of the low threshold value * will not trigger further notifications until the gauge * value becomes greater than or equal to the high * threshold.
- * + * *Typically, only one of the notify high and notify low * flags is set. The other threshold is used to provide a * hysteresis mechanism to avoid the repeated * triggering of notifications when an attribute makes small * oscillations around the threshold value.
- * + * *A GaugeMonitor can operate in difference
* mode. In this mode, the value compared against the
* high and low thresholds is the difference between two
* successive observations of an attribute.
A {@link javax.management.monitor.StringMonitor
* StringMonitor} observes attributes of type
* String. A notification is sent when an
* observed attribute becomes equal and/or not equal to a
* given string.
A relation type defines a relationship between MBeans. * It contains roles that the MBeans play in the * relationship. Usually there are at least two roles in a * relation type.
- * + * *A relation is a named instance of a relation type, * where specific MBeans appear in the roles, represented by * their {@link javax.management.ObjectName ObjectName}s.
- * + * *For example, suppose there are Module MBeans,
* representing modules within an application. A
* DependsOn relation type could express the
@@ -47,12 +47,12 @@
* started or stopped. The DependsOn relation type
* would have two roles, dependent and
* dependedOn.
Every role is typed, meaning that an MBean that
* appears in that role must be an instance of the role's type.
* In the DependsOn example, both roles would be of
* type Module.
Every role has a cardinality, which provides lower
* and upper bounds on the number of MBeans that can appear in
* that role in a given relation instance. Usually, the lower
@@ -65,7 +65,7 @@
* others, but any given relation instance links exactly one
* dependent module with exactly one
* dependedOn module.
A relation type can be created explicitly, as an object * implementing the {@link javax.management.relation.RelationType * RelationType} interface, typically a {@link @@ -74,7 +74,7 @@ * implicitly using the Relation Service's {@link * javax.management.relation.RelationServiceMBean#createRelationType(String, * RoleInfo[]) createRelationType} method.
- * + * *A relation instance can be created explicitly, as an object * implementing the {@link javax.management.relation.Relation * Relation} interface, typically a {@link @@ -85,56 +85,56 @@ * implicitly using the Relation Service's {@link * javax.management.relation.RelationServiceMBean#createRelation(String, * String, RoleList) createRelation} method.
- * + * *The DependsOn example might be coded as follows.
* import java.util.*;
* import javax.management.*;
* import javax.management.relation.*;
- *
+ *
* // ...
* MBeanServer mbs = ...;
- *
+ *
* // Create the Relation Service MBean
* ObjectName relSvcName = new ObjectName(":type=RelationService");
* RelationService relSvcObject = new RelationService(true);
* mbs.registerMBean(relSvcObject, relSvcName);
- *
+ *
* // Create an MBean proxy for easier access to the Relation Service
* RelationServiceMBean relSvc =
* MBeanServerInvocationHandler.newProxyInstance(mbs, relSvcName,
* RelationServiceMBean.class,
* false);
- *
+ *
* // Define the DependsOn relation type
* RoleInfo[] dependsOnRoles = {
* new RoleInfo("dependent", Module.class.getName()),
* new RoleInfo("dependedOn", Module.class.getName())
* };
* relSvc.createRelationType("DependsOn", dependsOnRoles);
- *
+ *
* // Now define a relation instance "moduleA DependsOn moduleB"
- *
+ *
* ObjectName moduleA = new ObjectName(":type=Module,name=A");
* ObjectName moduleB = new ObjectName(":type=Module,name=B");
- *
+ *
* Role dependent = new Role("dependent", Collections.singletonList(moduleA));
* Role dependedOn = new Role("dependedOn", Collections.singletonList(moduleB));
* Role[] roleArray = {dependent, dependedOn};
* RoleList roles = new RoleList(Arrays.asList(roleArray));
* relSvc.createRelation("A-DependsOn-B", "DependsOn", roles);
- *
+ *
* // Query the Relation Service to find what modules moduleA depends on
* Map<ObjectName,List<String>> dependentAMap =
* relSvc.findAssociatedMBeans(moduleA, "DependsOn", "dependent");
* Set<ObjectName> dependentASet = dependentAMap.keySet();
* // Set of ObjectName containing moduleB
*
- *
+ *
* @see
* JMX Specification, version 1.4
- *
+ *
* @since 1.5
*/
package javax.management.relation;
diff --git a/src/java.management/share/classes/javax/management/remote/package-info.java b/src/java.management/share/classes/javax/management/remote/package-info.java
index c7bb778bc08bc..3f47f0035dce3 100644
--- a/src/java.management/share/classes/javax/management/remote/package-info.java
+++ b/src/java.management/share/classes/javax/management/remote/package-info.java
@@ -27,11 +27,11 @@
* Interfaces for remote access to * JMX MBean servers. * This package defines the essential interfaces for making a JMX - * MBean server manageable remotely. The specification of this - * functionality is completed by Part III of the + * MBean server manageable remotely. The specification of this + * functionality is completed by Part III of the * * JMX Specification, version 1.4
- * + * *The JMX specification defines the notion of connectors. * A connector is attached to a JMX API MBean server and makes it * accessible to remote Java clients. The client end of a @@ -39,58 +39,58 @@ * server, specifically the {@link * javax.management.MBeanServerConnection MBeanServerConnection} * interface.
- * + * *A connector makes an MBean server remotely accessible through - * a given protocol. The JMX Remote API allows the use of different + * a given protocol. The JMX Remote API allows the use of different * type of connectors: - * + * *
Note: the optional packages implementing * the optional part of the JMX Remote API - * are not included in the Java SE Platform - * but are available from the JMX Remote API + * are not included in the Java SE Platform + * but are available from the JMX Remote API * * Reference Implementation.
- * - * + * + * *Typically, a connector server has an address, represented by the * class {@link javax.management.remote.JMXServiceURL * JMXServiceURL}. An address for the RMI Connector can look * like this:
- * + * ** service:jmx:rmi:///jndi/rmi://myhost:1099/myname *- * + * *
In this JMXServiceURL, the first rmi:
- * specifies the RMI connector, while the second rmi:
- * specifies the RMI registry into which the RMI connector server
+ * specifies the RMI connector, while the second rmi:
+ * specifies the RMI registry into which the RMI connector server
* has stored its stub.
- *
+ *
*
The example above shows only one form of address.
* An address for the RMI Connector can take several forms,
* as detailed in the documentation for the package
* javax.management.remote.rmi.
A connector server is created by constructing an instance of * a subclass of {@link * javax.management.remote.JMXConnectorServer @@ -99,27 +99,27 @@ * javax.management.remote.JMXConnectorServerFactory#newJMXConnectorServer(JMXServiceURL, * java.util.Map, javax.management.MBeanServer) * JMXConnectorServerFactory.newJMXConnectorServer}.
- * + * *Typically, a connector server is associated with an MBean * server either by registering it in that MBean server, or by * supplying the MBean server as a parameter when creating the * connector server.
- * + * *A connector client is usually created by supplying the
- * JMXServiceURL of the connector server to connect to
+ * JMXServiceURL of the connector server to connect to
* to the {@link
* javax.management.remote.JMXConnectorFactory#connect(JMXServiceURL)
* JMXConnectorFactory.connect} method.
For more specialized uses, a connector client can be created * by directly instantiating a class that implements the {@link * javax.management.remote.JMXConnector JMXConnector} interface, * for example the class RMIConnector.
- * + * *When creating a connector client or server, it is possible to
* supply an object of type {@link java.util.Map Map} that defines
* additional parameters. Each entry in this Map has a key that is
@@ -127,9 +127,9 @@
* that key. The standard keys defined by the JMX Remote API all
* begin with the string "jmx.remote.". The document
* JMX Remote API lists these standard keys.
Every connection opened by a connector server has a string * identifier, called its connection id. This identifier * appears in the {@link @@ -141,32 +141,32 @@ * returned by the client's {@link * javax.management.remote.JMXConnector#getConnectionId() * getConnectionId()} method.
- * + * *As an example, a connection ID can look something like this:
- * + * ** rmi://192.18.1.9 username 1 *- * + * *
The formal grammar for connection ids that follow this - * convention is as follows (using the grammar notation from section 2.4 of + * convention is as follows (using the grammar notation from section 2.4 of * The Java Language Specification):
** ConnectionId: * Protocol : ClientAddressopt Space ClientIdopt Space ArbitraryText - * + * * ClientAddress: * // HostAddress ClientPortopt - * + * * ClientPort * : HostPort *- * + * *
The Protocol is a protocol that would
* be recognized by {@link
* javax.management.remote.JMXConnectorFactory
* JMXConnectorFactory}.
The ClientAddress is the
* address and port of the connecting client, if these can be
* determined, otherwise nothing. The
@@ -175,23 +175,23 @@
* form. Numeric IPv6 addresses are enclosed in square brackets
* []. The HostPort is the
* decimal port number that the client is connecting from.
The ClientId is the identity of the
* client entity, typically a string returned by {@link
* javax.management.remote.JMXPrincipal#getName()
* JMXPrincipal.getName()}. This string must not contain
* spaces.
The ArbitraryText is any additional
* text that the connector server adds when creating the client id.
* At a minimum, it must be enough to distinguish this connection
* ID from the ID of any other connection currently opened by this
* connector server.
A listener for a Timer MBean can itself be an MBean, using * the method {@link * javax.management.MBeanServer#addNotificationListener(ObjectName, * ObjectName, NotificationFilter, Object)}. In this way, a * management application can create an MBean representing a task, * then schedule that task using a Timer MBean.
- * + * * @since 1.5 */ package javax.management.timer;