Bug ID: JDK-6299231 Add support for named MBean Servers

Versions (Unresolved/Resolved/Fixed)

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 b36Fixed

From ###@###.###:

A named MBeanServer is an MBeanServer that has a name, and can be
searched using that name. Duplicate names are not allowed.

MBeanServerFactory.createNamedMBeanServer(String name, String domain)
MBeanServerFactory.findNamedMBeanServer(String name)
MBeanServerBuilder.newMBeanServer(String name, String domain,
MBeanServer outer, MBeanServerDelegate delegate)

may be added, since they're addition to existing classes (not
interfaces).

About asking the name to an MBeanServer, there may be these choices:

1. Add getName() to MBeanServer interface
2. Add getName() to MBeanServerDelegateMBean interface and
implementation
3. Subclass MBeanServerDelegateMBean adding getName()
4. Add and register a new MBean, similar to the delegate, in the
JMImplementation domain.

Most of the mechanism may be hidden by
MBeanServerFactory.findNamedMBeanServer(String name), though JSR 255 may
be explicit in defining it (for example by mandating one of the above
choices).

This proposal will allow clients to easily distinguish MBeanServers in
case multiple ones are created in a single JVM, and a human user of a
management console to better understand the scope of the MBeanServer.

For example, running Tomcat in J2SE 5 will result in 2 MBeanServer
created, the platform's and Tomcat's.
Programmatically, the only way to distinguish them is to perform some
wild guess on the registered MBeans (yes, one can compare the results of
MBeanServerFactory.findMBeanServer(null) with
ManagementFactory.getPlatformMBeanServer(), but it's not general).
If both are registered with a name, say "platform" and "tomcat", the job
will be much easier.

###@###.### 2005-07-20 10:25:22 GMT

EVALUATION This seems like an excellent idea to me. Today you can achieve something a bit like this by abusing the default domain parameter. If we had thought to specify that the Platform MBeanServer's default domain was something specific, others might have followed suit. But the code to find a specific MBeanServer would have been clunky and possibly open to spoofing. Presumably createNamedMBeanServer would fail if there was already an MBeanServer of that name. I would suggest that the way to find the name of an MBeanServer should be a static method in MBeanServerFactory. I.e. public class MBeanServerFactory { public static String getMBeanServerName(MBeanServer mbs); } If the argument was not created by createNamedMBeanServer, the method returns null (or throws an exception). The implication is that MBeanServerBuilder does not need to acquire any new methods. This seems preferable to requiring an MBeanServer or MBeanServerDelegate implementation to track naming, and also ensures there cannot be problems if such an implementation accidentally or deliberately returns different names at different times. A named MBeanServer will appear in the list returned by MBeanServerFactory.findMBeanServer(null), along with any anonymous MBeanServers. When you call MBeanServerFactory.releaseMBeanServer with a named MBeanServer, you remove the name. We would probably want to create a new MBeanServerPermission name, e.g. "createNamedMBeanServer". This permission would imply MBeanServerPermission("createMBeanServer"), which in turn implies MBeanServerPermission("newMBeanServer"). We should also establish a convention for MBeanServer naming, probably based on the Java package name convention. The Platform MBeanServer would be called something like "java.lang.management.Platform". ###@###.### 2005-07-20 10:25:22 GMT

20-07-2005