Java6 supports the Attach API, which allows local injection of an Agent into a running Java6 capable JVM. The main drive behind it was the ability to attach monitoring utilities to applications on-the-fly, regardless of whether they were started with support. JConsole uses this API to start a local-only version of the out-of-the-box JMX management Agent in the JVM if it hasn't already been done so at application startup. With this done, JConsole can connect to the JVM via the new JMXConnectorServer directed at the JVM's Platform MBeanServer.
The broker uses the Platform MBeanServer to host its MBeans at present, as is considered standard practice in most cases, meaning that they are exposed by this additional JMXConnectorServer, which is not the same one started programmatically by the broker normally. You dont need to supply a username/password at this point in order to connect, but the ability is governed by operating system privileges, so eg under Linux you can only attach to the JVM if you are the user who started it. One issue that has come up though is that connections to this second ConnectorServer are not directed through the custom MBeanServerForwarder that is attached between the brokers primary ConnectorServer and the Platform MBeanServer. This means that the local connections are effectively admin level users and any additional checks and logging in the MBeanServerForwarder are bypassed. The effective admin-level rights isn't really an issue as OS user rights afford them that level of access anyway if they want it, but the ability to access the mbeans from two ConnectorServers has made life a little more difficult for the logging Martin has added. Tthe only way to stop that would be to move the Qpid MBeans into their own MBeanServer, which would mean JConsoles local ConnectorServer connections would be to the PlatformMBeanServer, allowing only the standard monitoring of memory, threads etc. 'Remote'(can still be same from the machine, aimed at localhost) JConsole connections would then be to the brokers own private MBeanServer, allowing only access to the Qpid MBeans, and resulting in the Memory, Threads etc tabs in JConsole being disabled (they would only ever be accessible to the user who loaded the JVM, unless the JVM was also started with the out-of-the-box agent running as well as our own). This is something that the broker configuration actually already supports, if management.platform-mbeanserver is added and set false in etc/config.xml (its not present, and defaults to true currently) this is exactly what happens. We could remove that ability and make it a fixed decision when the broker starts its ConnectorServer as to whether it should start its own MBeanServer as well. Is that something people think should be done? I don't think it is a security concern but it may be preferable to some(eg Martin J ) to only allow access to the Qpid MBeans through the main ConnectorServer we start ourselves. Robbie
