JDK-6675526 : Define an Annotation to name registered MBeans
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: sparc
  • Submitted: 2008-03-14
  • Updated: 2017-05-16
  • Resolved: 2011-04-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b43Fixed
Related Reports
Relates :  
JDK-6323980 - Annotations to simplify MBean development
Relates :  
JDK-6778909 - Add @Description annotations to built-in MBean interfaces
Description
It can be useful to define an Annotation that allow to express how an MBean is named once registered inside an MBeanServer. In the context where MBean are Singleton, the interest is obvious.
More logic is needed when dealing with multiple instances of the same type.

Having a default naming pattern that follows the best practices seems an interestering feature.

Deriving names from MBean attributes is also a possibility to investigate. See also bug id 6323980 for a suggested fix.
Comments
EVALUATION The simplest way of specifying the variables is to say that they come from attributes. This might seem redundant, because those attributes will be visible in the MBean, even though you already know what value they must have from the MBean's name. But in practice you might not in fact know, because you might just have a proxy. We've encountered this exact situation with the java.lang.management MBeans, where for example the MemoryPoolMXBean has a Name attribute that is the same as the name key in its ObjectName. If you call ManagementFactory.getMemoryPoolMXBeans, how do you find the ObjectName by which a remote client would access a given memory pool? The answer is that you can build it based on the value of getName() for any particular MemoryPoolMXBean object. By the way, the DMTF's CIM has a similar notion. A property in the CIM schema can have a [key] qualifier, which signifies that it is part of its object's name. One option is to do something similar to CIM, for example with an @ObjectNameKey annotation that you can put on the relevant attribute(s). But there would then need to be another annotation to fill in the fixed parts of the ObjectName. For example, MemoryPoolMXBeans are called something like java.lang:type=MemoryPool,name=Code Cache. If we put an @ObjectNameKey annotation on the getName() method that would take care of the variable part, but we would still need to put "java.lang:type=MemoryPool" somewhere. Instead we're proposing a single annotation that you put on the MBean interface. For example, the MemoryPoolMXBean interface could be annotated with @ObjectNameTemplate("java.lang:type=MemoryPool,name={Name}"). If you register an instance of MemoryPoolMXBean with a null ObjectName, it will compute an ObjectName based on this template and the value of the Name attribute. Of course, naming attributes should be immutable, though we probably won't try to enforce that. So for example if the Name attribute has the value "Code Cache" then the computed ObjectName will be "java.lang:type=MemoryPool,name=Code Cache". If you want to quote a value using ObjectName.quote then quote it in the template, like @ObjectNameTemplate("java.lang:type=MemoryPool,name=\"{Name}\""), which might yield 'java.lang:type=MemoryPool,name="Code Cache"'. We also propose to allow {attributes} to be interpolated elsewhere in the ObjectName, for example @ObjectNameTemplate("{Domain}:type=Foo") or @ObjectNameTemplate("{ObjectName}"), although we don't expect that to be common. For MBeans that can't be annotated, the ObjectName template can also be provided in the MBeanInfo, through a new "objectNameTemplate" field in the Descriptor. The @ObjectNameTemplate annotation in fact just arranges for this field to be filled in, and the logic to compute the ObjectName works regardless of where the template came from.
17-11-2008
SUGGESTED FIX @Documented @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.TYPE) public @interface ObjectNameTemplate { public String value() default ""; }
14-03-2008