@deprecated An AMXProxy offers generic access to any AMX-compliant MBean, including the ability to navigateupwards 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 {@link org.glassfish.admin.amx.config.AMXConfigProxy} andits sub-interfaces.
Implementing handler— an AMXProxy is implemented by {@link 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, {@link #parent} returns an AMXProxy, but {@link #getParent} returns the value of the{@code Parent} attribute (an ObjectName).The same convention is followed for {@link #childrenSet}, etc / {@link #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 {@code 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 {@link #attributeNames} and {@link #attributesMap} can be used to genericallyobtain all available attributes, and of course {@link 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 {@link #child}, {@link #childrenSet}, {@link #childrenMap} methods.
Invoking operations generically— Use the {@link #invokeOp} methods to invoke an arbitraryoperation by name.
@see Extra
@see MetaGetters
@see org.glassfish.admin.amx.config.AMXConfigProxy