JDK-6323795 : Metadata repository for JMX API
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2005-09-14
  • Updated: 2010-07-29
  • Resolved: 2008-09-17
Related Reports
Relates :  
JDK-5108739 - Support virtual MBeans
Relates :  
JDK-5072268 - Suggested API changes for JMX 2.0
Description
It is currently possible to query the MBean Server to know the metadata of any MBean that is registered in it.  The metadata of an MBean is encapsulated in the MBeanInfo class and consists of the names, types, etc, of its attributes, operations, constructors, notifications; plus arbitrary extra information appended via the Descriptor mechanism.  However, there is no way to discover the metadata for an MBean class that does not happen to have any instances registered in the MBean Server, nor is there a simple way to discover relationships between MBean classes, for example inheritance.

The proposed enhancement is to have a Metadata Service that can be queried to discover information about the classes of MBeans that the MBean Server can handle, independently of whether there are any instances of those classes.  It should be able to return the MBeanInfo for any MBean class and to impose an inheritance hierarchy that can list all superclasses or all subclasses of a given class.  It might also have rules that allow one to determine the MBeanInfo for an MBean based on its name, for example if the name matches com.example.jmx.*:type=Foo,* then the MBeanInfo is Foo.  And/or, it might have a way to discover, given an MBean class, what current MBeans are instances of that class, or what ObjectName pattern would discover those instances.

The metadata information could be obtained using a new convention for finding it in jar files.  The jar files in question would typically be those present in the context class loader in place when the MBean Server was created, plus any loaders that have been added to the MBean Server's ClassLoaderRepository.  The information could be obtained via a list of Standard MBean or MXBean interfaces in the jar, or a list of classes implementing those interfaces, or serialized MBeanInfo objects, or XML; whatever choice is made, there will surely be tooling necessary to add the information to a jar file.

An important question that must be addressed is that of versioning.  While it is probably not necessary to support there being two completely incompatible versions of the same class, it should be possible to support there being more and less recent versions.  It is possible today for two MBeans to co-exist that are of different versions of the same class.

Some example uses of the metadata repository:

* A CIM-based model is mapped to JMX MBeans.  A CIM client expects to be able to query the model dynamically, independently of instances, and the repository supports that.  A client should also be able to discover what instances there are of CIM_ComputerSystem or any subclass of it.

* Some services, such as Monitors and the Relation Service, are designed to be usable by a remote client that creates instances of MBeans to act on its behalf.  A client can consult the metadata repository to know what services are available.  For example, a management console could have a "create MBean" operation that presents a drop-down list of remotely-creatable MBeans.

* An IDE could interrogate the repository as part of an "implement MBean" or "create MBean client" operation.

* Virtual MBeans (see 5108739) could use the repository to ensure that MBeanInfo objects are shared across instances, rather than implementing their own caches.  (Idea from ###@###.###.)
Comments
EVALUATION Closing this in the JMX category, though it is still an interesting idea that might be provided by some other project.
17-09-2008
EVALUATION We are not current planning to implement this in the JMX API 2.0 (so in Java SE 7).
24-01-2008
EVALUATION ###@###.### has noted that it may be possible to extract the necessary information from jar files without needing to add any specific information to them, just by scanning the classes in the jar files. This is theoretically impossible with full generality (for example you cannot know what MBeanInfo a DynamicMBean will return without executing its getMBeanInfo() method, and this method may return different results for difference instances), but it may be sufficient to define constraints that MBean classes must meet in order to be automatically visible in the metadata repository. Perhaps then the built-in logic for MBeans that respect those constraints could be supplemented by an API that users can call in order to use their own logic to get the information from jar files into the repository.
05-07-2006
EVALUATION Currently considered for Dolphin (Java SE 7).
14-09-2005