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:

  MBeanServerConnection getMBeanServerConnection();
  ObjectName getObjectName();
  boolean isMXBean();

  Specified: MBeanServerInvocationHandler javadoc.

* A new method in javax.management.JMX tests whether a Class is an
  MXBean interface:

  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
  mechanism.

  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 object 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
    object 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
    getter.

  - 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".
###@###.### 2005-06-01 14:18:22 GMT

Further changes:

* 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.
###@###.### 2005-06-03 13:22:30 GMT