After review within the JMX and serviceability teams and feedback from Quality Engineers and the JSR 255 Expert Group, a number of changes are proposed to the MXBean specification as integrated into b40 of Mustang.
* MBeanServerInvocationHandler acquires getters to retrieve the
parameters that were supplied to the constructor:
Specified: MBeanServerInvocationHandler javadoc.
* A new method in javax.management.JMX tests whether a Class is an
public boolean isMXBeanInterface(Class<?> interfaceClass);
Specified: javax.management.JMX javadoc.
* The class javax.management.StandardMBean implements the
MBeanRegistration interface. When it is used to construct an
MXBean, this allows it to track the name under which the MXBean is
registered, in order to handle inter-MXBean references correctly.
In the existing implementation, this was done by a back door between
the MBean Server and this class, but that isn't available to a
replacement MBean Server substituted via the MBeanServerBuilder
Existing subclasses of StandardMBean that already implement
MBeanRegistration cannot be MXBeans since user MXBeans didn't exist
in Tiger. The spec recommends that new code that subclasses
StandardMBean and implements MBeanRegistration insert the
appropriate super.preRegister etc calls.
Specified: StandardMBean javadoc.
* Standard MBeans and MXBeans have a new Descriptor field "mxbean"
with value "true" or "false" as appropriate. This field is also
present in every instance of the StandardMBean class.
Specified: Descriptor javadoc.
* A number of minor changes are made to the MXBean mapping rules
describing how to reconstruct an customer from a CompositeData:
- A clearer separation is made between the conditions that must hold
for a given rule to apply, and the conditions that mean that the
customer is not reconstructible. If one of the second set of
conditions is not met, later rules are not tried.
- The order of the rules is changed. If a class has a constructor
with a @PropertyNames annotation, then that is preferred even if
the class also has a zero-arg constructor and a setter for every
- If more than one constructor has a @PropertyNames annotation, then
the constructor to use must be unambiguous regardless of what
items are present in any CompositeData. Previously some cases of
ambiguity were only noticed when a given CompositeData instance
was being translated.
Specified: javax.management.MXBean javadoc, section "Reconstructing
an instance of Java type J from a CompositeData".
* For compatibility with the existing java.lang.management
specification, when a primitive type such as int appears in a
parameter or return value of a method in an MXBean interface, the
corresponding MBeanParameterInfo, MBeanAttributeInfo, or
MBeanOperationInfo must return "int" from its getType() or
getReturnType() method. This means that it cannot be an
OpenMBeanParameterInfo etc, which in turn means that the overall
MBeanInfo cannot be an OpenMBeanInfo. The information about
OpenTypes is still available through the "openType" field of the
Descriptor for each MBeanParameterInfo etc.
The specification does not require or forbid using an
OpenMBeanParameterInfo etc when primitive types are not involved.
Specified: javax.management.MXBean javadoc, section "MBeanInfo
contents for an MXBean".
* For compatibility with the existing java.lang.management behaviour,
a problem in translating from Open Types or Open Data into Java Types
or Java Data is signaled with a java.io.InvalidObjectException. Given
the documented meaning of this exception, we continue to use the more
appropriate exception OpenDataException for a problem in translating
Java Types or Java Data to Open Types or Open Data.
Specified: javax.management.MXBean javadoc, section "Exceptions".
xxxxx@xxxxx 2005-06-01 14:18:22 GMT
* As for @PropertyNames, items can be missing in the CompositeData from which we are reconstructing a Java class in the case where it comes from a no-arg constructor plus setters. The setters for the missing items are not called.
* Specify that the MBeanInfo for an MXBean contains an MBeanNotificationInfo that is derived with NotificationBroadcaster.getNotificationInfo() at the time the MXBean is registered. If the MXBean does not implement NotificationBroadcaster, then the array is empty.
* Specify that the MBeanInfo for an MXBean contains an MBeanConstructorInfo containing the publicly-visible constructors of the MXBean. MXBean type mappings do not apply to constructor parameters.
xxxxx@xxxxx 2005-06-03 13:22:30 GMT