The main focus of Jolokia is to allow easy access to JMX MBeans from everywhere. MBeans can be provided by the JVM itself, by an application server or an application itself, where each MBean is registered at a specific MBeanServer. Multiple MBeanServers can co-exist in a single JVM. The so called PlatformMBeanServer is always present and is created by the JVM during startup. Especially application servers often create additional MBeanServers for various purposes. When accessing an MBean remotely via JSR-160, the MBeanServer holding the requested MBean must be known before. Jolokia instead merges all MBeanServers it can find to give a single view on all MBeans. The merging algorithm is described in MBeanServer merging.
For application specific MBeans, Jolokia provides an own, so called Jolokia MBeanServer which is treated specially by the Jolokia agent. The Jolokia MBeanServer and its features are explained in Jolokia MBeanServer.
Developing application specific MBeans is easy, especially if Standard MBeans are used. However, for Spring users there is even a easier, more declarative way for turning POJOs into MBeans. On top of this Jolokia provides an easy, declarative way for firing up a Jolokia JVM agent merely by including some Jolokia specific Spring configuration. This is described in Spring Support.
The Jolokia MBeanServer can be easily created and used with a locator:
MBeanServer jolokiaServer = JolokiaMBeanServerUtil.getJolokiaMBeanServer();
javax.management.MBeanServerFactory.newMBeanServer() is called, so it’s not returned when
This server is treated specially by a Jolokia Agent:
Every MBean registered at the Jolokia MBeanServer will never show up remotely via JSR-160. The Jolokia MBeanServer is never exposed over JSR-160.
Each Jolokia MBeanServer registered MBean will shadow any MBean with the same ObjectName in any other MBeanServer present. See below for more details.
The Jolokia MBeanServer is also responsible for managing so called JSON MBeans. These are MBeans annotated with
@JsonMBeanon the class level. JSON MBean are explained in @JsonMBean
Jolokia tries hard to detect as many MBeanServer as available
in a JVM. Beside the always present
application servers create own MBeanServer which not always
can be found with standard mechanisms. Therefore Jolokia comes
with so called
ServerDetectors for many
known brands of applications server. These server detectors
know how to find MBeanServer by application server specific
The set of available of MBeanServers is detected during startup and kept, except for the Jolokia MBeanServer which can kick in and out at any time. For Jolokia operations, all these MBeanServers are tried according the order given below.
MBeanServeris queried first, if available.
MBeanServeras detected by the server detectors a queried in turn.
All MBeanServers returned by
MBeanServerFactory.findMBeanServer(null)(which should return all the
MBeanServerFactory.createMBeanServer(), but not the ones created by
javax.management.MBeanServerFactory.newMBeanServer()) are called if not already tried previously.
ManagementFactory.getPlatformMBeanServer()is used (also, if not found in a former step).
All MBeans contained in all detected MBeanServers are merged
to give a single view on the set of available MBeans.
For MBeans registered with the same name at different
MBeanServers, MBeans registered in later MBeanServers are not
visible. These hidden MBeans will never be called on
exec operations. Also, for
list operations only the meta data of the
visible MBeans is returned.
This hiding mechanism is used by
@JsonMBean to provide a different view of
an MBean for JSR-160 connectors (see below).
JMX 1.4 introduced
which allow for nearly arbitrary data to be translated into so
called _OpenData which are accessible via JMX. For example,
arbitrary Java Beans are translated into a
structure with property names as keys and their values in
Jolokia provides an annotation
for marking an MBean as a JSON MBean. Such an MBean, if
registered at the Jolokia MBeanServer
creates a proxy on the PlatformMBeanServer
where every complex value gets translated into plain strings in
JSON format. This is true for attributes, operation return
values and arguments. That way, a JSR-160 based console (like
jconsole) can easily access complex data
type exposed by custom MBeans. Json MBeans work for Java 6 and
JsonMBean and MXBean are quite similar as both do a translation from complex data types to a standard format (OpenType for MXBeans, JSON strings for JsonMBean). However, there are also differences:
MXBeans are a standard mechanism which are available on every JVM since 1.5.
Serialization of complex Java Beans is more powerful with JsonMBeans, e.g. Jolokia can detect self (or cyclic) object references. MXBeans will cause an error in this case.
JsonMBeans must be added to the Jolokia MBeanServer to work. MXBeans work with the PlatformMBeanServer, too.
JsonMBean work also with JMX support libraries which use
ModelMBean's under the hood. E.g. Spring JMX uses a ModelMBean for
@JsonMBeancan be easily added, whereas
@MXBeanwouldn’t work here.
The Jolokia MBeanServer and the
@JsonMBean annotation are contained in the