JDK-5072476 : RFE: support cascaded (federated) MBean Servers
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-07-09
  • Updated: 2017-05-16
  • Resolved: 2011-03-08
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.
7 b36Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Several implementations based on the JMX API include some support for "cascading" or "federation".  The idea is that one or more "subagents" can have some or all of their MBeans proxied into a "master agent", where "agent" means MBean Server.  The proxies may not have the same name as the proxied MBeans.

The proposal is to allow a "mount" operation, analogous to Unix filesystem mounting.  If subagent S has an MBean X called "com.example:type=Whatsit", and S is mounted with name "sub" in master agent M, then M will have a proxy MBean X' called "sub/com.example:type=Whatsit".  Accessing an attribute or operation on X' will cause the proxy to forward the access to X and return the result to the caller.  Where a parameter or return value in X is or contains an ObjectName such as "com.example:type=Thing", the proxy will do the appropriate mapping so that the ObjectName is seen by callers of X' as "sub/com.example:type=Thing".

The complete details of cascading will be considerably more complicated than described here. 

EVALUATION Cascading is a special case of a more general notion, that of constructing a hierarchy of MBeanServers. The idea is that within an MBeanServer mbs1, you can specify that another MBeanServer mbs2 appears as "mbs2//", for example. So if you do mbs1.getAttribute("mbs2//d:k=v", "Foo"), that ends up calling mbs2.getAttribute("d:k=v"). mbs2 can be any object that implements the MBeanServer interface. It can be a reference to a remote MBeanServer via a connector, which is the basis for building cascading. It can be an object that constructs the referenced MBeans on demand, which is the basis for Virtual MBeans (see CR 5108739). "mbs2//" is called a "namespace", and is created by registering an MBean of the class JMXNamespace (or a subclass), with the special ObjectName "mbs2//:type=JMXNamespace". The JMXNamespace MBean is given an instance of MBeanServer that is the MBeanServer that appears as "mbs2//...", mbs2 in the example. The characters "//" in the domain part of an ObjectName indicate a path in the hierarchy. Previously, mbs1.getAttribute("mbs2//d:k=v", "Foo") just looked for an MBean of that name in mbs1. Now, it looks for a namespace called "mbs2//" and does getAttribute("d:k=v", "Foo") within it. The meaning of * in an ObjectName is adjusted so that it does not match the separator "//". Therefore if you call mbs1.queryNames(new ObjectName("*:*"), null), you will not see the MBeans within mbs2, whose names begin with "mbs2//". On the other hand, if you call mbs1.queryNames(new ObjectName("mbs2//*:*"), null), you *will* see those MBeans, for example "mbs2//d:k=v". For further details, consult the documentation of package javax.management.namespaces in the documentation reachable from the JSR 255 pages at <http://jcp.org/en/jsr/detail?id=255>.

PUBLIC COMMENTS Support "mounting" one or more subagents into a master agent.