Jolokia

Jolokia is an open source, completely free and easy-to-use software implemented in Java and designed from the offset to be used for accessing JMX with JSON over HTTP remotely. It's more like JMX on Capsaicin. It doesn't have a graphical user interface (GUI).

As a matter of fact, Jolokia is a JMX-HTTP bridge providing an alternative to JSR-160 connectors. It is simple, fast, polyglot, secure, firewall-friendly and includes various unique features like bulk-requests.

Features at a glance

Key features include support for processing as many JMX (Java Management Extensions) requests as possible in just one network roundtrip and support for wrapping multiple Jolokia requests in a JSON (JavaScript Object Notation) payload.

Support for running in agentless mode, JSON/HTTP proxy support for Jolokia requests, support for sending bulk requests into multiple JSR-160 requests, support for custom policies that include fine grained restrictions, as well as support for wildcards and allow/deny sections in custom policies.

In addition, the application supports parsing of requests and building of responses by using the json-simple JSON serialization library software, and support for balancing multiple use cases with state-of-the-art features, such as low startup times and bulk requests.

Jolokia is an easy to install software that can only be accessed via a supported web browser. It can be accessed on any platform by using a configurable, REST-like URL encoding feature. The software runs on multiple HTTP proxy hops.

Under the hood and supported OSes

Taking a look under the hood of Jolokia, we can notice that the Java programming language has been used to write the program, which means that it is platform-independent, supported on GNU/Linux, Mac OS X and Microsoft Windows operating systems.

For your convenience, it is available for download as both pre-built binaries and a source tarball. It has been successfully tested on both 32-bit and 64-bit computers.

What is new in this release:

• 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 ...

What is new in version 1.1.5:

• 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.

What is new in version 1.1.4:

• 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.

What is new in version 1.1.2:

• 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.

What is new in version 1.1.1:

• 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'.

Requirements:

• Java 2 Standard Edition Runtime Environment