Some applications have very large numbers of managed objects.  As the JMX API stands today, these applications must therefore have very large numbers of MBeans, each of which corresponds to a Java object.  So the memory footprint can be significant.

Likewise, in some applications managed objects come and go very rapidly.  If they are to be reflected by MBeans, the MBeans must constantly be created and destroyed to reflect the current state.  This happens even during quiet periods when the MBeans are not being referenced.

A way to improve these two situations would be to support "virtual MBeans".  A virtual MBean does not correspond to a permanent Java object, but is called into existence when it is referenced and can disappear afterwards.

One way to allow virtual MBeans is via "MBean Server interceptors".  The idea here is that one or more objects implementing the MBeanServer interface can be inserted between the MBeanServer object that user code sees (as returned by ManagementFactory.newMBeanServer for instance) and the "real" MBeanServer that handles the Java objects corresponding to MBeans:

+--------+           +-------------------------+           +--------+
|User MBS|    -->    |Virtual files interceptor|    -->    |Real MBS|
+--------+           +-------------------------+           +--------+

In this picture, the "virtual files interceptor" (VFI) is an object that implements the MBeanServer interface and that handles virtual MBeans for a filesystem.  Every file in the filesystem is reflected by an MBean.  Suppose a method in the MBeanServer interface is called on the VFI.  Let's say the method is getAttribute(ObjectName name, String attr).  The VFI examines the ObjectName.  If the ObjectName specifies the "files" domain then the VFI will handle the method itself and return the value for the named attribute applied to the file whose name is in the rest of the ObjectName.  If, on the other hand, the ObjectName specifies a different domain then the VFI will simply call getAttribute on the next MBeanServer object in the chain.  In the picture, this is the "real MBean Server", so the behaviour will be the same as if there were no VFI.

In code, we could have something like this:

public VirtualFilesInterceptor implements MBeanServer {
    public VirtualFilesInterceptor(MBeanServer next) {
        this.next = next;
    }

    public Object getAttribute(ObjectName name, String attr) throws ... {
        if (name.getDomain().equals("files"))
            return getFileAttribute(name.getKeyProperty("filename"), attr);
        else
            return next.getAttribute(name, attr);
    }
    ...
}

Today, it is possible to achieve something like this by exploiting the ability to specify an MBeanServerBuilder, but it is not convenient.  It would be somewhat more convenient if there were static methods to set and get the current MBeanServerBuilder, but even then this would imply the same interceptors for every MBean Server created in a given JVM.

Other API possibilities include making a new MBeanServer2 interface that extends the existing MBeanServer and adding new methods such as setInterceptor and getInterceptor to it (adding methods to the existing MBeanServer interface would break existing source code that implements this interface); or specifying that every MBeanServer must contain a predefined MBean with a name like JMImplementation:type=InterceptorManager whose operations allow the interceptors to be configured.

Note that the idea of MBean Server Interceptors is not the same as the MBean interceptors used by certain app servers.  In that case, there can be a chain of objects between the MBeanServer object that a user sees and any individual MBean object.  The chain for one MBean object can be different from that for another MBean object.  But in every case the chain terminates with a real Java object, so this pattern does not address the problems of large numbers of MBeans or very volatile MBeans.