In a comment on my last entry,
One thing that struck me about MXBeans is that they are really fusion of standard MBeans and OpenMBeans, since they only use standard types. However they don't actually conform to OpenMBean conventions.
Why was the decision taken not to make MXBeans OpenMBeans? (i.e. return an OpenMBeanInfo from getMBeanInfo())
Therein lies a tale!
MXBeans really are OpenMBeans. But as you note they don't return OpenMBeanInfo. However, in Mustang, all the same information that would have been in the OpenMBeanInfo is present via Descriptors.
MBeanInfo mbi = mbeanServer.getMBeanInfo(objectName); MBeanAttributeInfo mbai = mbi.getAttributes(); OpenMBeanAttributeInfo ombai = (OpenMBeanAttributeInfo) mbai; OpenType ot = ombai.getOpenType();
...you can use...
MBeanInfo mbi = mbeanServer.getMBeanInfo(objectName); MBeanAttributeInfo mbai = mbi.getAttributes(); Descriptor d = mbai.getDescriptor(); OpenType ot = (OpenType) d.getFieldValue("openType");
This fusion of OpenMBeanInfo functionality into plain MBeanInfo means that you can have OpenModelMBeans and other strange beasts.
Nevertheless, we did originally plan for MXBeans to return OpenMBeanInfo. The reason they don't is subtle.
In the original incarnation of MXBeans, in java.lang.management, we wanted to use the type
long in the ThreadMXBean. But OpenTypes didn't support arrays of primitive types - they would only have supported
Long, substantially less efficient. So we avoided using OpenMBeanInfo in Tiger with the intent of fixing this problem in Mustang.
It now is possible to have an array of primitive type as an OpenType, so we could now describe the ThreadMXBean with an OpenMBeanInfo. However, there are some interoperability concerns that we didn't foresee.
Suppose you have a Tiger client, say jconsole running on Tiger, talking to a Mustang server. Since
long didn't exist as an OpenType in Tiger, if we sent an
OpenMBeanParameterInfo with type
long to a Tiger, it will see it as if its type were
Long. Suppose it lets the user call a method like
If jconsole saw an
OpenMBeanParameterInfo for a
Long then it would expect the signature array in
MBeanServerConnection.invoke to contain
"[Ljava.lang.Long;". But since the parameter is really a
long, it should be
"[J". If you pass the wrong signature, the method invocation will fail.
We could have envisaged various hacks to work around this problem, but we decided it would be simpler to continue to use
MBeanParameterInfo rather than
OpenMBeanParameterInfo, with the Descriptor containing the OpenType. In the example at hand, we'll have an
ArrayType.getPrimitiveArrayType(long.class). On Tiger, there's no such OpenType, but there's no Descriptor in
MBeanParameterInfo either so the inconsistency evaporates. The Tiger client sees just the
MBeanParameterInfo.getType(), which is
"[J" as required.
For what it's worth, our implementation does use an
OpenMBeanParameterInfo when it doesn't contradict the constraints I mentioned. In particular, if your attribute or parameter is a
CompositeData then even a Tiger client will be able to see the corresponding