Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 6299231
Votes 0
Synopsis Add support for named MBean Servers
Category jmx:classes
Reported Against
Release Fixed 7(b36)
State 10-Fix Delivered, request for enhancement
Priority: 4-Low
Related Bugs 5072268
Submit Date 20-JUL-2005
Description

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.

  xxxxx@xxxxx   2005-07-20 10:25:22 GMT
Work Around
N/A
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".
  xxxxx@xxxxx   2005-07-20 10:25:22 GMT
Comments
  
  Include a link with my name & email   


PLEASE NOTE: JDK6 is formerly known as Project Mustang