Jolokia Changelog

New in version 1.2.0

February 25th, 2014
  • New year, new release. Ok, it's not the BIG 2.0 which I already somewhat promised. Anyways, another big feature jumped on the 1.x train in the last minute. It is now possible to find agents in your network by sending an UDP packet to the multicast group 239.192.48.84, port 24884. Agents having this discovery mechanism enabled will respond with their meta data including the access URL. This is especially useful for clients who want to provide access to agents without much configuration. I.e. the excellent hawt.io will probably use it one way or the other. In fact, it was hawt.io which put me on track for this nice little feature ;-)
  • Discovery is enabled by default for the JVM agent, but not for the WAR agent. It can be easily enabled for the WAR agent by using servlet init parameters, system properties or environment variables. All the nifty details can be found in the reference manual.
  • The protocol for the discovery mechanism is also specified in the reference manual. One of the first clients supporting this discovery mode is Jmx4Perl in its newest version. The Jolokia Java client will follow in one of the next minor releases.
  • But you don't need client support for multicast requests if you know already the URL for one agent. Each agent registers a MBean jolokia:type=Discovery which perform the multicast discovery request for you if you trigger the operation lookupAgents. The returned value contains the agent information and is described here.
  • This feature has been tested in various environments, but since low level networking can be, well, "painful", I would ask you to open an issue in case of any problems.
  • Although it has been quiet some time with respect to the shiny new Jolokia 2.0, I'm quite close to a first milestone. All planned features has been implemented in an initial version, what's missing is to finish the heavy refactoring and modularisation of the Jolokia core. More on this later, please stay tuned ...

New in version 1.1.5 (November 9th, 2013)

  • This is by far the smallest release ever: A single char has been added on top of 1.1.4 fixing a silly bug when using Glassfish with the AMX system. So, no need to update if you are not using Glassfish.

New in version 1.1.4 (October 5th, 2013)

  • Some bug fixes and two new features has been included for the autumn release:
  • A new configuration parameter "authenticatorClass" can be used for the JVM agent to specify an alternate authentication handler in addition to the default one (which simply checks for user and password).
  • With the configuration parameter "logHandlerClass" an alternative log handler can be specified. This can be used for the WAR and JVM agent in order to tweak Jolokia's logging behaviour. For the OSGi agent you already could use a LogService for customizing logging.

New in version 1.1.2 (May 30th, 2013)

  • It contains some minor bug fixes as explained in the changelog. Depending on the bug reports and pull request dropping in there might be even a 1.1.3 release before 2.0 will be finished.

New in version 1.1.1 (March 28th, 2013)

  • BigDecimal and BigInteger can now be used for operation arguments and return values.
  • A new processing parameter ifModifiedSince has been introduced. This parameter can be used with a timestamp for fetching the list of available MBeans only when there has been some changes in the MBean registration on any observed MBeanServer since that time. If there has been no changes an answer with status code "302" (Not modified) is returned. This feature is also supported for "search" requests. In a future version of Jolokia, there will be also custom support for own "read" and "exec" request so that expensive operations can be called conditionally.
  • 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.
  • The Expires: header of a Jolokia response has now a valid date as value (instead of '-1') which points to one hour in the past. This change should help clients which do not ignore according to RFC-2616 invalid date syntax and treat them as 'already expired'.