Uses of Package
org.glassfish.admin.amx.core

Packages that use org.glassfish.admin.amx.core

Package	Description
org.glassfish.admin.amx.base
org.glassfish.admin.amx.config	Generic AMX config MBean interfaces.
org.glassfish.admin.amx.core	Core AMX api and utilities.
org.glassfish.admin.amx.core.proxy
org.glassfish.admin.amx.impl.config
org.glassfish.admin.amx.impl.j2ee
org.glassfish.admin.amx.impl.mbean
org.glassfish.admin.amx.impl.util
org.glassfish.admin.amx.j2ee
org.glassfish.admin.amx.logging
org.glassfish.admin.amx.monitoring	Top-level monitoring interfaces.

Classes in org.glassfish.admin.amx.core used by org.glassfish.admin.amx.base

Class and Description
AMX_SPI Deprecated. MBean implementations can 'implements AMX_SPI', though it is only behavior via MBeanInfo and attributes that is actually required.
AMXMBeanMetadata Holds meta information useful in generating and/or supplementing the default MBeanInfo as well as other runtime fields or optimizations.
AMXProxy Deprecated. An AMXProxy offers generic access to any AMX-compliant MBean, including the ability to navigate upwards to the Parent MBean, find all children or those of a particular type or name, to get all metadata, atttributes, or to invoke any method. Various sub-interfaces offer additional functionality, such as explicit methods for getting children of a particular type, creating new children (eg configuration), attribute getter/setter methods, etc. The most notable sub-interface is AMXConfigProxy and its sub-interfaces. Implementing handler— an AMXProxy is implemented by AMXProxyHandler, but the handler should be considered private: do not use it as it is subject to change. Sub interfaces— the base AMXProxy interface can and should be extended for specific MBeans, but in most cases it will not be appropriate or convenient for MBean implementors to 'implement' the interface because it is for use by a proxy to the MBean, not the MBean itself. In particular, it makes no sense for an MBean to implement the proxy interface because the proxy interface demands the use of AMXProxy and sub-types, whereas the MBean must return ObjectName. Method name convention— a convention followed in AMXProxy is that convenience "getter" methods (non-remote methods implemented directly by the proxy itself) do not use the get prefix, in order to distinguish them from the usual getter pattern for real MBean attributes. For example, AMXProxy.parent() returns an AMXProxy, but AMX_SPI.getParent() returns the value of the Parent attribute (an ObjectName). The same convention is followed for AMXProxy.childrenSet(), etc / AMX_SPI.getChildren(). Not authoritative— proxy interfaces should not be considered authoritative, meaning that an underlying MBean implementation determines what the MBean actually provides, possibly ignoring the proxy interface (this is the case with config MBeans, which derive their metadata from the ConfigBean @Configured interface). Therefore, it is possible for the proxy interface to completely misrepresent the actual MBean functionality, should the interface get out of sync with the actual MBean. Only at runtime would errors between the interface and the MBean would emerge. Methods in sub-interfaces of AMXProxy— To mininimize issues with tracking implementation changes over time (eg addition or removal of attributes), sub-interfaces of AMXProxy might choose to omit getter/setter methods for attributes, and instead manifest the containment relationships (children), which form the core of usability of navigating the hierarchy. The methods AMXProxy.attributeNames() and AMXProxy.attributesMap() can be used to generically obtain all available attributes, and of course MetaGetters.mbeanInfo() provides extensive metadata. Auto-mapping of ObjectName— An AMXProxy automatically maps various ObjectName constructs to the equivalent AMXProxy(ies). For example, an MBean providing an Attribute named Item should declare it as an ObjectName, or for a plurality Items, declaring an ObjectName[]. Any of the following proxy methods (declared in a sub-interface of AMXProxy) will automatically convert the resulting ObjectName(s) into the corresponding AMXProxy or plurality of AMXProxy: AMXProxy getItem(); AMXProxy[] getItems(); Set<AMXProxy> getItems(); List<AMXProxy> getItems(); Map<String,AMXProxy> getItems(); The same approach is used in the generic AMXProxy.child(java.lang.String), AMXProxy.childrenSet(), AMXProxy.childrenMap(java.lang.String) methods. Invoking operations generically— Use the AMXProxy.invokeOp(java.lang.String) methods to invoke an arbitrary operation by name.

Classes in org.glassfish.admin.amx.core used by org.glassfish.admin.amx.config

Class and Description
AMX_SPI Deprecated. MBean implementations can 'implements AMX_SPI', though it is only behavior via MBeanInfo and attributes that is actually required.
AMXProxy Deprecated. An AMXProxy offers generic access to any AMX-compliant MBean, including the ability to navigate upwards to the Parent MBean, find all children or those of a particular type or name, to get all metadata, atttributes, or to invoke any method. Various sub-interfaces offer additional functionality, such as explicit methods for getting children of a particular type, creating new children (eg configuration), attribute getter/setter methods, etc. The most notable sub-interface is AMXConfigProxy and its sub-interfaces. Implementing handler— an AMXProxy is implemented by AMXProxyHandler, but the handler should be considered private: do not use it as it is subject to change. Sub interfaces— the base AMXProxy interface can and should be extended for specific MBeans, but in most cases it will not be appropriate or convenient for MBean implementors to 'implement' the interface because it is for use by a proxy to the MBean, not the MBean itself. In particular, it makes no sense for an MBean to implement the proxy interface because the proxy interface demands the use of AMXProxy and sub-types, whereas the MBean must return ObjectName. Method name convention— a convention followed in AMXProxy is that convenience "getter" methods (non-remote methods implemented directly by the proxy itself) do not use the get prefix, in order to distinguish them from the usual getter pattern for real MBean attributes. For example, AMXProxy.parent() returns an AMXProxy, but AMX_SPI.getParent() returns the value of the Parent attribute (an ObjectName). The same convention is followed for AMXProxy.childrenSet(), etc / AMX_SPI.getChildren(). Not authoritative— proxy interfaces should not be considered authoritative, meaning that an underlying MBean implementation determines what the MBean actually provides, possibly ignoring the proxy interface (this is the case with config MBeans, which derive their metadata from the ConfigBean @Configured interface). Therefore, it is possible for the proxy interface to completely misrepresent the actual MBean functionality, should the interface get out of sync with the actual MBean. Only at runtime would errors between the interface and the MBean would emerge. Methods in sub-interfaces of AMXProxy— To mininimize issues with tracking implementation changes over time (eg addition or removal of attributes), sub-interfaces of AMXProxy might choose to omit getter/setter methods for attributes, and instead manifest the containment relationships (children), which form the core of usability of navigating the hierarchy. The methods AMXProxy.attributeNames() and AMXProxy.attributesMap() can be used to generically obtain all available attributes, and of course MetaGetters.mbeanInfo() provides extensive metadata. Auto-mapping of ObjectName— An AMXProxy automatically maps various ObjectName constructs to the equivalent AMXProxy(ies). For example, an MBean providing an Attribute named Item should declare it as an ObjectName, or for a plurality Items, declaring an ObjectName[]. Any of the following proxy methods (declared in a sub-interface of AMXProxy) will automatically convert the resulting ObjectName(s) into the corresponding AMXProxy or plurality of AMXProxy: AMXProxy getItem(); AMXProxy[] getItems(); Set<AMXProxy> getItems(); List<AMXProxy> getItems(); Map<String,AMXProxy> getItems(); The same approach is used in the generic AMXProxy.child(java.lang.String), AMXProxy.childrenSet(), AMXProxy.childrenMap(java.lang.String) methods. Invoking operations generically— Use the AMXProxy.invokeOp(java.lang.String) methods to invoke an arbitrary operation by name.

Classes in org.glassfish.admin.amx.core used by org.glassfish.admin.amx.core

Class and Description
AMX_SPI Deprecated. MBean implementations can 'implements AMX_SPI', though it is only behavior via MBeanInfo and attributes that is actually required.
AMXProxy Deprecated. An AMXProxy offers generic access to any AMX-compliant MBean, including the ability to navigate upwards to the Parent MBean, find all children or those of a particular type or name, to get all metadata, atttributes, or to invoke any method. Various sub-interfaces offer additional functionality, such as explicit methods for getting children of a particular type, creating new children (eg configuration), attribute getter/setter methods, etc. The most notable sub-interface is AMXConfigProxy and its sub-interfaces. Implementing handler— an AMXProxy is implemented by AMXProxyHandler, but the handler should be considered private: do not use it as it is subject to change. Sub interfaces— the base AMXProxy interface can and should be extended for specific MBeans, but in most cases it will not be appropriate or convenient for MBean implementors to 'implement' the interface because it is for use by a proxy to the MBean, not the MBean itself. In particular, it makes no sense for an MBean to implement the proxy interface because the proxy interface demands the use of AMXProxy and sub-types, whereas the MBean must return ObjectName. Method name convention— a convention followed in AMXProxy is that convenience "getter" methods (non-remote methods implemented directly by the proxy itself) do not use the get prefix, in order to distinguish them from the usual getter pattern for real MBean attributes. For example, AMXProxy.parent() returns an AMXProxy, but AMX_SPI.getParent() returns the value of the Parent attribute (an ObjectName). The same convention is followed for AMXProxy.childrenSet(), etc / AMX_SPI.getChildren(). Not authoritative— proxy interfaces should not be considered authoritative, meaning that an underlying MBean implementation determines what the MBean actually provides, possibly ignoring the proxy interface (this is the case with config MBeans, which derive their metadata from the ConfigBean @Configured interface). Therefore, it is possible for the proxy interface to completely misrepresent the actual MBean functionality, should the interface get out of sync with the actual MBean. Only at runtime would errors between the interface and the MBean would emerge. Methods in sub-interfaces of AMXProxy— To mininimize issues with tracking implementation changes over time (eg addition or removal of attributes), sub-interfaces of AMXProxy might choose to omit getter/setter methods for attributes, and instead manifest the containment relationships (children), which form the core of usability of navigating the hierarchy. The methods AMXProxy.attributeNames() and AMXProxy.attributesMap() can be used to generically obtain all available attributes, and of course MetaGetters.mbeanInfo() provides extensive metadata. Auto-mapping of ObjectName— An AMXProxy automatically maps various ObjectName constructs to the equivalent AMXProxy(ies). For example, an MBean providing an Attribute named Item should declare it as an ObjectName, or for a plurality Items, declaring an ObjectName[]. Any of the following proxy methods (declared in a sub-interface of AMXProxy) will automatically convert the resulting ObjectName(s) into the corresponding AMXProxy or plurality of AMXProxy: AMXProxy getItem(); AMXProxy[] getItems(); Set<AMXProxy> getItems(); List<AMXProxy> getItems(); Map<String,AMXProxy> getItems(); The same approach is used in the generic AMXProxy.child(java.lang.String), AMXProxy.childrenSet(), AMXProxy.childrenMap(java.lang.String) methods. Invoking operations generically— Use the AMXProxy.invokeOp(java.lang.String) methods to invoke an arbitrary operation by name.
AMXValidator.ProblemList
AMXValidator.ValidationResult
Extra Deprecated. Extra information available about each AMXProxy. Most of these fields are for advanced use and/or direct use of JMX.
MetaGetters Deprecated. Convenience getters for Descriptor values and other metadata from the MBeanInfo. These operations do not make a trip to the server. See AMXProxy.extra().
PathnameParser.PathPart
StdAttributesAccess Deprecated. Direct access to JMX attributes and methods, These are "straight JMX" with no intervening processing whatsoever.

Classes in org.glassfish.admin.amx.core used by org.glassfish.admin.amx.core.proxy

Class and Description
AMX_SPI Deprecated. MBean implementations can 'implements AMX_SPI', though it is only behavior via MBeanInfo and attributes that is actually required.
AMXProxy Deprecated. An AMXProxy offers generic access to any AMX-compliant MBean, including the ability to navigate upwards to the Parent MBean, find all children or those of a particular type or name, to get all metadata, atttributes, or to invoke any method. Various sub-interfaces offer additional functionality, such as explicit methods for getting children of a particular type, creating new children (eg configuration), attribute getter/setter methods, etc. The most notable sub-interface is AMXConfigProxy and its sub-interfaces. Implementing handler— an AMXProxy is implemented by AMXProxyHandler, but the handler should be considered private: do not use it as it is subject to change. Sub interfaces— the base AMXProxy interface can and should be extended for specific MBeans, but in most cases it will not be appropriate or convenient for MBean implementors to 'implement' the interface because it is for use by a proxy to the MBean, not the MBean itself. In particular, it makes no sense for an MBean to implement the proxy interface because the proxy interface demands the use of AMXProxy and sub-types, whereas the MBean must return ObjectName. Method name convention— a convention followed in AMXProxy is that convenience "getter" methods (non-remote methods implemented directly by the proxy itself) do not use the get prefix, in order to distinguish them from the usual getter pattern for real MBean attributes. For example, AMXProxy.parent() returns an AMXProxy, but AMX_SPI.getParent() returns the value of the Parent attribute (an ObjectName). The same convention is followed for AMXProxy.childrenSet(), etc / AMX_SPI.getChildren(). Not authoritative— proxy interfaces should not be considered authoritative, meaning that an underlying MBean implementation determines what the MBean actually provides, possibly ignoring the proxy interface (this is the case with config MBeans, which derive their metadata from the ConfigBean @Configured interface). Therefore, it is possible for the proxy interface to completely misrepresent the actual MBean functionality, should the interface get out of sync with the actual MBean. Only at runtime would errors between the interface and the MBean would emerge. Methods in sub-interfaces of AMXProxy— To mininimize issues with tracking implementation changes over time (eg addition or removal of attributes), sub-interfaces of AMXProxy might choose to omit getter/setter methods for attributes, and instead manifest the containment relationships (children), which form the core of usability of navigating the hierarchy. The methods AMXProxy.attributeNames() and AMXProxy.attributesMap() can be used to generically obtain all available attributes, and of course MetaGetters.mbeanInfo() provides extensive metadata. Auto-mapping of ObjectName— An AMXProxy automatically maps various ObjectName constructs to the equivalent AMXProxy(ies). For example, an MBean providing an Attribute named Item should declare it as an ObjectName, or for a plurality Items, declaring an ObjectName[]. Any of the following proxy methods (declared in a sub-interface of AMXProxy) will automatically convert the resulting ObjectName(s) into the corresponding AMXProxy or plurality of AMXProxy: AMXProxy getItem(); AMXProxy[] getItems(); Set<AMXProxy> getItems(); List<AMXProxy> getItems(); Map<String,AMXProxy> getItems(); The same approach is used in the generic AMXProxy.child(java.lang.String), AMXProxy.childrenSet(), AMXProxy.childrenMap(java.lang.String) methods. Invoking operations generically— Use the AMXProxy.invokeOp(java.lang.String) methods to invoke an arbitrary operation by name.
Extra Deprecated. Extra information available about each AMXProxy. Most of these fields are for advanced use and/or direct use of JMX.
MetaGetters Deprecated. Convenience getters for Descriptor values and other metadata from the MBeanInfo. These operations do not make a trip to the server. See AMXProxy.extra().
StdAttributesAccess Deprecated. Direct access to JMX attributes and methods, These are "straight JMX" with no intervening processing whatsoever.

Classes in org.glassfish.admin.amx.core used by org.glassfish.admin.amx.impl.config

Class and Description
AMX_SPI Deprecated. MBean implementations can 'implements AMX_SPI', though it is only behavior via MBeanInfo and attributes that is actually required.
AMXProxy Deprecated. An AMXProxy offers generic access to any AMX-compliant MBean, including the ability to navigate upwards to the Parent MBean, find all children or those of a particular type or name, to get all metadata, atttributes, or to invoke any method. Various sub-interfaces offer additional functionality, such as explicit methods for getting children of a particular type, creating new children (eg configuration), attribute getter/setter methods, etc. The most notable sub-interface is AMXConfigProxy and its sub-interfaces. Implementing handler— an AMXProxy is implemented by AMXProxyHandler, but the handler should be considered private: do not use it as it is subject to change. Sub interfaces— the base AMXProxy interface can and should be extended for specific MBeans, but in most cases it will not be appropriate or convenient for MBean implementors to 'implement' the interface because it is for use by a proxy to the MBean, not the MBean itself. In particular, it makes no sense for an MBean to implement the proxy interface because the proxy interface demands the use of AMXProxy and sub-types, whereas the MBean must return ObjectName. Method name convention— a convention followed in AMXProxy is that convenience "getter" methods (non-remote methods implemented directly by the proxy itself) do not use the get prefix, in order to distinguish them from the usual getter pattern for real MBean attributes. For example, AMXProxy.parent() returns an AMXProxy, but AMX_SPI.getParent() returns the value of the Parent attribute (an ObjectName). The same convention is followed for AMXProxy.childrenSet(), etc / AMX_SPI.getChildren(). Not authoritative— proxy interfaces should not be considered authoritative, meaning that an underlying MBean implementation determines what the MBean actually provides, possibly ignoring the proxy interface (this is the case with config MBeans, which derive their metadata from the ConfigBean @Configured interface). Therefore, it is possible for the proxy interface to completely misrepresent the actual MBean functionality, should the interface get out of sync with the actual MBean. Only at runtime would errors between the interface and the MBean would emerge. Methods in sub-interfaces of AMXProxy— To mininimize issues with tracking implementation changes over time (eg addition or removal of attributes), sub-interfaces of AMXProxy might choose to omit getter/setter methods for attributes, and instead manifest the containment relationships (children), which form the core of usability of navigating the hierarchy. The methods AMXProxy.attributeNames() and AMXProxy.attributesMap() can be used to generically obtain all available attributes, and of course MetaGetters.mbeanInfo() provides extensive metadata. Auto-mapping of ObjectName— An AMXProxy automatically maps various ObjectName constructs to the equivalent AMXProxy(ies). For example, an MBean providing an Attribute named Item should declare it as an ObjectName, or for a plurality Items, declaring an ObjectName[]. Any of the following proxy methods (declared in a sub-interface of AMXProxy) will automatically convert the resulting ObjectName(s) into the corresponding AMXProxy or plurality of AMXProxy: AMXProxy getItem(); AMXProxy[] getItems(); Set<AMXProxy> getItems(); List<AMXProxy> getItems(); Map<String,AMXProxy> getItems(); The same approach is used in the generic AMXProxy.child(java.lang.String), AMXProxy.childrenSet(), AMXProxy.childrenMap(java.lang.String) methods. Invoking operations generically— Use the AMXProxy.invokeOp(java.lang.String) methods to invoke an arbitrary operation by name.

Classes in org.glassfish.admin.amx.core used by org.glassfish.admin.amx.impl.j2ee

Class and Description
AMX_SPI Deprecated. MBean implementations can 'implements AMX_SPI', though it is only behavior via MBeanInfo and attributes that is actually required.

Classes in org.glassfish.admin.amx.core used by org.glassfish.admin.amx.impl.mbean

Class and Description
AMX_SPI Deprecated. MBean implementations can 'implements AMX_SPI', though it is only behavior via MBeanInfo and attributes that is actually required.
AMXProxy Deprecated. An AMXProxy offers generic access to any AMX-compliant MBean, including the ability to navigate upwards to the Parent MBean, find all children or those of a particular type or name, to get all metadata, atttributes, or to invoke any method. Various sub-interfaces offer additional functionality, such as explicit methods for getting children of a particular type, creating new children (eg configuration), attribute getter/setter methods, etc. The most notable sub-interface is AMXConfigProxy and its sub-interfaces. Implementing handler— an AMXProxy is implemented by AMXProxyHandler, but the handler should be considered private: do not use it as it is subject to change. Sub interfaces— the base AMXProxy interface can and should be extended for specific MBeans, but in most cases it will not be appropriate or convenient for MBean implementors to 'implement' the interface because it is for use by a proxy to the MBean, not the MBean itself. In particular, it makes no sense for an MBean to implement the proxy interface because the proxy interface demands the use of AMXProxy and sub-types, whereas the MBean must return ObjectName. Method name convention— a convention followed in AMXProxy is that convenience "getter" methods (non-remote methods implemented directly by the proxy itself) do not use the get prefix, in order to distinguish them from the usual getter pattern for real MBean attributes. For example, AMXProxy.parent() returns an AMXProxy, but AMX_SPI.getParent() returns the value of the Parent attribute (an ObjectName). The same convention is followed for AMXProxy.childrenSet(), etc / AMX_SPI.getChildren(). Not authoritative— proxy interfaces should not be considered authoritative, meaning that an underlying MBean implementation determines what the MBean actually provides, possibly ignoring the proxy interface (this is the case with config MBeans, which derive their metadata from the ConfigBean @Configured interface). Therefore, it is possible for the proxy interface to completely misrepresent the actual MBean functionality, should the interface get out of sync with the actual MBean. Only at runtime would errors between the interface and the MBean would emerge. Methods in sub-interfaces of AMXProxy— To mininimize issues with tracking implementation changes over time (eg addition or removal of attributes), sub-interfaces of AMXProxy might choose to omit getter/setter methods for attributes, and instead manifest the containment relationships (children), which form the core of usability of navigating the hierarchy. The methods AMXProxy.attributeNames() and AMXProxy.attributesMap() can be used to generically obtain all available attributes, and of course MetaGetters.mbeanInfo() provides extensive metadata. Auto-mapping of ObjectName— An AMXProxy automatically maps various ObjectName constructs to the equivalent AMXProxy(ies). For example, an MBean providing an Attribute named Item should declare it as an ObjectName, or for a plurality Items, declaring an ObjectName[]. Any of the following proxy methods (declared in a sub-interface of AMXProxy) will automatically convert the resulting ObjectName(s) into the corresponding AMXProxy or plurality of AMXProxy: AMXProxy getItem(); AMXProxy[] getItems(); Set<AMXProxy> getItems(); List<AMXProxy> getItems(); Map<String,AMXProxy> getItems(); The same approach is used in the generic AMXProxy.child(java.lang.String), AMXProxy.childrenSet(), AMXProxy.childrenMap(java.lang.String) methods. Invoking operations generically— Use the AMXProxy.invokeOp(java.lang.String) methods to invoke an arbitrary operation by name.
AMXValidator.ProblemList

Classes in org.glassfish.admin.amx.core used by org.glassfish.admin.amx.impl.util

Class and Description
AMX_SPI Deprecated. MBean implementations can 'implements AMX_SPI', though it is only behavior via MBeanInfo and attributes that is actually required.
AMXProxy Deprecated. An AMXProxy offers generic access to any AMX-compliant MBean, including the ability to navigate upwards to the Parent MBean, find all children or those of a particular type or name, to get all metadata, atttributes, or to invoke any method. Various sub-interfaces offer additional functionality, such as explicit methods for getting children of a particular type, creating new children (eg configuration), attribute getter/setter methods, etc. The most notable sub-interface is AMXConfigProxy and its sub-interfaces. Implementing handler— an AMXProxy is implemented by AMXProxyHandler, but the handler should be considered private: do not use it as it is subject to change. Sub interfaces— the base AMXProxy interface can and should be extended for specific MBeans, but in most cases it will not be appropriate or convenient for MBean implementors to 'implement' the interface because it is for use by a proxy to the MBean, not the MBean itself. In particular, it makes no sense for an MBean to implement the proxy interface because the proxy interface demands the use of AMXProxy and sub-types, whereas the MBean must return ObjectName. Method name convention— a convention followed in AMXProxy is that convenience "getter" methods (non-remote methods implemented directly by the proxy itself) do not use the get prefix, in order to distinguish them from the usual getter pattern for real MBean attributes. For example, AMXProxy.parent() returns an AMXProxy, but AMX_SPI.getParent() returns the value of the Parent attribute (an ObjectName). The same convention is followed for AMXProxy.childrenSet(), etc / AMX_SPI.getChildren(). Not authoritative— proxy interfaces should not be considered authoritative, meaning that an underlying MBean implementation determines what the MBean actually provides, possibly ignoring the proxy interface (this is the case with config MBeans, which derive their metadata from the ConfigBean @Configured interface). Therefore, it is possible for the proxy interface to completely misrepresent the actual MBean functionality, should the interface get out of sync with the actual MBean. Only at runtime would errors between the interface and the MBean would emerge. Methods in sub-interfaces of AMXProxy— To mininimize issues with tracking implementation changes over time (eg addition or removal of attributes), sub-interfaces of AMXProxy might choose to omit getter/setter methods for attributes, and instead manifest the containment relationships (children), which form the core of usability of navigating the hierarchy. The methods AMXProxy.attributeNames() and AMXProxy.attributesMap() can be used to generically obtain all available attributes, and of course MetaGetters.mbeanInfo() provides extensive metadata. Auto-mapping of ObjectName— An AMXProxy automatically maps various ObjectName constructs to the equivalent AMXProxy(ies). For example, an MBean providing an Attribute named Item should declare it as an ObjectName, or for a plurality Items, declaring an ObjectName[]. Any of the following proxy methods (declared in a sub-interface of AMXProxy) will automatically convert the resulting ObjectName(s) into the corresponding AMXProxy or plurality of AMXProxy: AMXProxy getItem(); AMXProxy[] getItems(); Set<AMXProxy> getItems(); List<AMXProxy> getItems(); Map<String,AMXProxy> getItems(); The same approach is used in the generic AMXProxy.child(java.lang.String), AMXProxy.childrenSet(), AMXProxy.childrenMap(java.lang.String) methods. Invoking operations generically— Use the AMXProxy.invokeOp(java.lang.String) methods to invoke an arbitrary operation by name.

Classes in org.glassfish.admin.amx.core used by org.glassfish.admin.amx.j2ee

Class and Description
AMX_SPI Deprecated. MBean implementations can 'implements AMX_SPI', though it is only behavior via MBeanInfo and attributes that is actually required.
AMXMBeanMetadata Holds meta information useful in generating and/or supplementing the default MBeanInfo as well as other runtime fields or optimizations.
AMXProxy Deprecated. An AMXProxy offers generic access to any AMX-compliant MBean, including the ability to navigate upwards to the Parent MBean, find all children or those of a particular type or name, to get all metadata, atttributes, or to invoke any method. Various sub-interfaces offer additional functionality, such as explicit methods for getting children of a particular type, creating new children (eg configuration), attribute getter/setter methods, etc. The most notable sub-interface is AMXConfigProxy and its sub-interfaces. Implementing handler— an AMXProxy is implemented by AMXProxyHandler, but the handler should be considered private: do not use it as it is subject to change. Sub interfaces— the base AMXProxy interface can and should be extended for specific MBeans, but in most cases it will not be appropriate or convenient for MBean implementors to 'implement' the interface because it is for use by a proxy to the MBean, not the MBean itself. In particular, it makes no sense for an MBean to implement the proxy interface because the proxy interface demands the use of AMXProxy and sub-types, whereas the MBean must return ObjectName. Method name convention— a convention followed in AMXProxy is that convenience "getter" methods (non-remote methods implemented directly by the proxy itself) do not use the get prefix, in order to distinguish them from the usual getter pattern for real MBean attributes. For example, AMXProxy.parent() returns an AMXProxy, but AMX_SPI.getParent() returns the value of the Parent attribute (an ObjectName). The same convention is followed for AMXProxy.childrenSet(), etc / AMX_SPI.getChildren(). Not authoritative— proxy interfaces should not be considered authoritative, meaning that an underlying MBean implementation determines what the MBean actually provides, possibly ignoring the proxy interface (this is the case with config MBeans, which derive their metadata from the ConfigBean @Configured interface). Therefore, it is possible for the proxy interface to completely misrepresent the actual MBean functionality, should the interface get out of sync with the actual MBean. Only at runtime would errors between the interface and the MBean would emerge. Methods in sub-interfaces of AMXProxy— To mininimize issues with tracking implementation changes over time (eg addition or removal of attributes), sub-interfaces of AMXProxy might choose to omit getter/setter methods for attributes, and instead manifest the containment relationships (children), which form the core of usability of navigating the hierarchy. The methods AMXProxy.attributeNames() and AMXProxy.attributesMap() can be used to generically obtain all available attributes, and of course MetaGetters.mbeanInfo() provides extensive metadata. Auto-mapping of ObjectName— An AMXProxy automatically maps various ObjectName constructs to the equivalent AMXProxy(ies). For example, an MBean providing an Attribute named Item should declare it as an ObjectName, or for a plurality Items, declaring an ObjectName[]. Any of the following proxy methods (declared in a sub-interface of AMXProxy) will automatically convert the resulting ObjectName(s) into the corresponding AMXProxy or plurality of AMXProxy: AMXProxy getItem(); AMXProxy[] getItems(); Set<AMXProxy> getItems(); List<AMXProxy> getItems(); Map<String,AMXProxy> getItems(); The same approach is used in the generic AMXProxy.child(java.lang.String), AMXProxy.childrenSet(), AMXProxy.childrenMap(java.lang.String) methods. Invoking operations generically— Use the AMXProxy.invokeOp(java.lang.String) methods to invoke an arbitrary operation by name.

Classes in org.glassfish.admin.amx.core used by org.glassfish.admin.amx.logging

Class and Description
AMX_SPI Deprecated. MBean implementations can 'implements AMX_SPI', though it is only behavior via MBeanInfo and attributes that is actually required.
AMXMBeanMetadata Holds meta information useful in generating and/or supplementing the default MBeanInfo as well as other runtime fields or optimizations.
AMXProxy Deprecated. An AMXProxy offers generic access to any AMX-compliant MBean, including the ability to navigate upwards to the Parent MBean, find all children or those of a particular type or name, to get all metadata, atttributes, or to invoke any method. Various sub-interfaces offer additional functionality, such as explicit methods for getting children of a particular type, creating new children (eg configuration), attribute getter/setter methods, etc. The most notable sub-interface is AMXConfigProxy and its sub-interfaces. Implementing handler— an AMXProxy is implemented by AMXProxyHandler, but the handler should be considered private: do not use it as it is subject to change. Sub interfaces— the base AMXProxy interface can and should be extended for specific MBeans, but in most cases it will not be appropriate or convenient for MBean implementors to 'implement' the interface because it is for use by a proxy to the MBean, not the MBean itself. In particular, it makes no sense for an MBean to implement the proxy interface because the proxy interface demands the use of AMXProxy and sub-types, whereas the MBean must return ObjectName. Method name convention— a convention followed in AMXProxy is that convenience "getter" methods (non-remote methods implemented directly by the proxy itself) do not use the get prefix, in order to distinguish them from the usual getter pattern for real MBean attributes. For example, AMXProxy.parent() returns an AMXProxy, but AMX_SPI.getParent() returns the value of the Parent attribute (an ObjectName). The same convention is followed for AMXProxy.childrenSet(), etc / AMX_SPI.getChildren(). Not authoritative— proxy interfaces should not be considered authoritative, meaning that an underlying MBean implementation determines what the MBean actually provides, possibly ignoring the proxy interface (this is the case with config MBeans, which derive their metadata from the ConfigBean @Configured interface). Therefore, it is possible for the proxy interface to completely misrepresent the actual MBean functionality, should the interface get out of sync with the actual MBean. Only at runtime would errors between the interface and the MBean would emerge. Methods in sub-interfaces of AMXProxy— To mininimize issues with tracking implementation changes over time (eg addition or removal of attributes), sub-interfaces of AMXProxy might choose to omit getter/setter methods for attributes, and instead manifest the containment relationships (children), which form the core of usability of navigating the hierarchy. The methods AMXProxy.attributeNames() and AMXProxy.attributesMap() can be used to generically obtain all available attributes, and of course MetaGetters.mbeanInfo() provides extensive metadata. Auto-mapping of ObjectName— An AMXProxy automatically maps various ObjectName constructs to the equivalent AMXProxy(ies). For example, an MBean providing an Attribute named Item should declare it as an ObjectName, or for a plurality Items, declaring an ObjectName[]. Any of the following proxy methods (declared in a sub-interface of AMXProxy) will automatically convert the resulting ObjectName(s) into the corresponding AMXProxy or plurality of AMXProxy: AMXProxy getItem(); AMXProxy[] getItems(); Set<AMXProxy> getItems(); List<AMXProxy> getItems(); Map<String,AMXProxy> getItems(); The same approach is used in the generic AMXProxy.child(java.lang.String), AMXProxy.childrenSet(), AMXProxy.childrenMap(java.lang.String) methods. Invoking operations generically— Use the AMXProxy.invokeOp(java.lang.String) methods to invoke an arbitrary operation by name.

Classes in org.glassfish.admin.amx.core used by org.glassfish.admin.amx.monitoring

Class and Description
AMX_SPI Deprecated. MBean implementations can 'implements AMX_SPI', though it is only behavior via MBeanInfo and attributes that is actually required.
AMXMBeanMetadata Holds meta information useful in generating and/or supplementing the default MBeanInfo as well as other runtime fields or optimizations.
AMXProxy Deprecated. An AMXProxy offers generic access to any AMX-compliant MBean, including the ability to navigate upwards to the Parent MBean, find all children or those of a particular type or name, to get all metadata, atttributes, or to invoke any method. Various sub-interfaces offer additional functionality, such as explicit methods for getting children of a particular type, creating new children (eg configuration), attribute getter/setter methods, etc. The most notable sub-interface is AMXConfigProxy and its sub-interfaces. Implementing handler— an AMXProxy is implemented by AMXProxyHandler, but the handler should be considered private: do not use it as it is subject to change. Sub interfaces— the base AMXProxy interface can and should be extended for specific MBeans, but in most cases it will not be appropriate or convenient for MBean implementors to 'implement' the interface because it is for use by a proxy to the MBean, not the MBean itself. In particular, it makes no sense for an MBean to implement the proxy interface because the proxy interface demands the use of AMXProxy and sub-types, whereas the MBean must return ObjectName. Method name convention— a convention followed in AMXProxy is that convenience "getter" methods (non-remote methods implemented directly by the proxy itself) do not use the get prefix, in order to distinguish them from the usual getter pattern for real MBean attributes. For example, AMXProxy.parent() returns an AMXProxy, but AMX_SPI.getParent() returns the value of the Parent attribute (an ObjectName). The same convention is followed for AMXProxy.childrenSet(), etc / AMX_SPI.getChildren(). Not authoritative— proxy interfaces should not be considered authoritative, meaning that an underlying MBean implementation determines what the MBean actually provides, possibly ignoring the proxy interface (this is the case with config MBeans, which derive their metadata from the ConfigBean @Configured interface). Therefore, it is possible for the proxy interface to completely misrepresent the actual MBean functionality, should the interface get out of sync with the actual MBean. Only at runtime would errors between the interface and the MBean would emerge. Methods in sub-interfaces of AMXProxy— To mininimize issues with tracking implementation changes over time (eg addition or removal of attributes), sub-interfaces of AMXProxy might choose to omit getter/setter methods for attributes, and instead manifest the containment relationships (children), which form the core of usability of navigating the hierarchy. The methods AMXProxy.attributeNames() and AMXProxy.attributesMap() can be used to generically obtain all available attributes, and of course MetaGetters.mbeanInfo() provides extensive metadata. Auto-mapping of ObjectName— An AMXProxy automatically maps various ObjectName constructs to the equivalent AMXProxy(ies). For example, an MBean providing an Attribute named Item should declare it as an ObjectName, or for a plurality Items, declaring an ObjectName[]. Any of the following proxy methods (declared in a sub-interface of AMXProxy) will automatically convert the resulting ObjectName(s) into the corresponding AMXProxy or plurality of AMXProxy: AMXProxy getItem(); AMXProxy[] getItems(); Set<AMXProxy> getItems(); List<AMXProxy> getItems(); Map<String,AMXProxy> getItems(); The same approach is used in the generic AMXProxy.child(java.lang.String), AMXProxy.childrenSet(), AMXProxy.childrenMap(java.lang.String) methods. Invoking operations generically— Use the AMXProxy.invokeOp(java.lang.String) methods to invoke an arbitrary operation by name.