Two new Jolokia releases (1.1.0 and 1.1.1) in the past month add some nice new features.
## Spring support
A new module jolokia-spring has been added which makes integration of Jolokia in Spring applications even easier. Simply add the following line (along with the corresponding namespace) to you application context and agent will be fired up during startup:
<jolokia:agent>
<jolokia:config
autoStart="true"
host="0.0.0.0"
port="8778"
....
/>
</jolokia:agent>
Expect more spring support to come with Jolokia 2.0, for example an agent as a Spring MVC controller.
The new jolokia-jmx module provides also an own MBeanServer which never gets exposed via JSR-160 remoting. By registering your MBeans at the Jolokia MBeanServer you can make them exclusively available for Jolokia without worrying about JSR-160 access e.g. via jconsole. However, if you annotate your MBeans with @JsonMBean
and register it at the Jolokia MBeanServer your get automatic translation of complex data types to JSON even for JSR-160 connections:
Several new processing options enter the scene. These can be given either as global configuration parameters or as query parameters:
canonicalNaming
influences the order of key properties in object namesserializeException
adds a JSON representation of exceptions in an error caseincludeStackTrace
can switch on/off the sending of an lengthy stack trace in an error caseifModifiedSince
can be used to conditionally fetching the MBean list. Only when the set of registered MBeans has changed this request will return the full list.For the JVM agent, if a port of 0 is given, then an arbitrary free port will be selected and printed out on standard output as part of the Jolokia agent URL. If no host is given, the JVM agent will now bind to localhost and if host of “0.0.0.0” or “*” is provided, the agent will bind on all interfaces.
For the Java client an extra property errorValue
has been added which holds the JSON serialized exception if the processiong parameter serializeException
is active.
The JavaScript client’s jolokia.register() can now take an optional config
element for specifying processing parameters for a certain scheduler job. Also, the new option onlyIfModified
can be used so that the callback for list and search request is only called, if the set of registered MBean has changed. This is especially useful for web based client which want to refresh the MBean tree only if there are changes.
That’s it for now. Work on 2.0 has been already started, you can expect spectacular stuff like JMX notification support in various variants. This will take some time. So, please stay tuned …