Jolokia is a JMX-HTTP bridge giving an alternative to JSR-160 connectors. It is an agent based approach with support for many platforms. In addition to basic JMX operations it enhances JMX remoting with unique features like bulk requests and fine grained security policies.
Beside bug fixes as described in the changelog, this minor release brings some small features:
That's it for now. Enjoy it !
We are getting closer. I'm happy to announce that the first milestone release 2.0.0-M1 is out and available from Maven central. Of course, it is highly experimental. The main new features are JMX notification support (pull and SSE mode) and refactorings leading to an internal modularization (which you will see when looking into WAR agent).
More information can be found on my Blog. Soon there will be also demo and screencast showing the new features.
Jolokia 1.3.2 is still the latest stable version and will receive minor updates in the future, too.
It was quite calm around Jolokia this summer and not much happened in Jolokia-land. Not many bugs arrived, too, which I take as a good sign :)
Now let's start a next round with some revamped TLS support for https connections. Version 1.3.2 introduces a handful of new options for advanced configuration of the JVM agent's TLS connector:
In addition to the keystore (option keystore) the CA and the server cert as well as the server cert's key can be provided as PEM files with the options caCert, serverCert and serverKey, respectively.
Client cert validation has also be enhanced. In addition to validating the CA signature of a client cert, one can now also check that the extended key usage block of the cert was created for client usage (option extendedClientCheck). Also, one or more principals can be configured with clientPrincipal which are also compared againt the subject within a client certificate.
For simple use cases where no server validation is required, Jolokia is now able to create self-signed server certificates on the fly. This happens if neither a keystore nor a server PEM cert is provided. So, the easiest way to enable https is simply to add protocol=https. Of course, the client needs to disable cert validation then and it is recommended to use basic-authentication to authenticate the connection.
That's it for now mostly, but see the changelog for some other minor additions. Progress on Jolokia 2.0 continues slowly, won't tell much here until I have a M1 release. No promises either :)
This minor release introduces one single new feature: A delegating authentication provider for the JVM agent. This can be switched on with configuration options and allow to delegate the authentication decision to an external service so that an easy SSO e.g. via OAuth2 is possible.
For example, if you are an OpenShift user and want to participate in OpenShift's OAuth2 SSO, then you can specify the following startup parameters, assuming that you OpenShift API server is running as openshift:8443:
java -javaagent:jolokia.jar=\ authMode=delegate,\ authUrl=https://openshift:8443/osapi/v1beta3/users/~,\ authPrincipalSpec=json:metadata/name,\ authIgnoreCerts=true\ ...
More about this can be found in the reference manual. Note, that the parameter authenticationClass has been renamed to authClass for consistencies sake. Please raise an issue if this doesn't work for you.
After quite some winter sleep Jolokia is back with a fresh release. This is mostly a bug fix release with some new features:
There is one important change in the default behaviour of the WAR agent: Up to 1.2.3 Jolokia truncates any collection in the response value at a threshold of 1000 elements by default. This limit can be overwritten permanently in the configuration or per request as query parameter (maxCollectionSize). However, it turned out that this limit was not large enough. So the new default behaviour is to have no limit at all. As said, if you need it you always can set a hard limit in the agent's configuration.
But the biggest news is probably something complete different: I'm super happy to announce that I (roland) joined Red Hat since May, where I will able to continue to work on Jolokia with an even higher intensity. Before looking into the future, acknowledgements go to my former employer ConSol. Without the support donated by ConSol Jolokia would probably never has been grown from the original personal pet project to a full featured, production ready JMX remote access solution as it is today. Thank you !
What are the next steps ? Jolokia 2.0 (code name: "Duke Nukem Forever") is not so far away, all changes from 1.x has been already merged up to the 2.0 branch. A release candidate should be available soon, however I can't give any estimates yet. But what I can say: Jolokia is alive and kicking more than ever!
Meh, that was a busy summer. Apologies for the delay and breaking the usual one-release-per-month cycle.
Nevertheless there are some nice goodies in this release:
If you want to get a quick introduction into Jolokia and a peek preview to Jolokia 2.0 come to my "Tools in Action" session at Devoxx 2014 in Antwerp.
Last announcement for now: I started a blog at https://ro14nd.de about various technical topics like Jolokia, Docker or other stuff.
Let's welcome Jolokia's next minor release which is not so minor as it might seems.
The biggest new feature with the most impact is path wildcard support. You probably know pattern read requests which allow for fetching multiple patterns by using patterns for MBean names and attributes (not to be confused with bulk requests). When using pattern read requests, the value in the returned JSON structure is not a single return value for an attribute but a more complex structure containing the full MBean names and attributes which are matched by the pattern. Of course, it is not easy to use a path to navigate on this structure, the path has to know the full MBean name (well, why using a pattern then ?). That's the main reason why path access was not supported for pattern read requests up to release 1.2.1
Starting with 1.2.2 it is possible to use "*" wildcards in patterns, which match a complete 'level' in the JSON object. This makes it easy to fetch all same-named attributes on arbitrary MBeans and extract only parts of their values. In fact, it is not so easy explain wildcard pathes, but here is a try (another try can be found in the reference manual):
You see, wildcard path handling is somewhat complex. For pattern read request they make quite some sense, for all other requests, I couldn't find good use cases yet. Please open an issue if any suspicious behaviour during path-wildcard using occurs.
Finally, I would also like to mention a new GitHub project jolokia-extra which holds additional goodies. One design goal of Jolokia is to keep it focused. That's not so easy as there are tons of ideas out there, all backed by a particular use case. And they all want to get into the game. Beside that someone has to implement that (hint: still looking for contributions ;-), I opened a new playground for all that stuff which might not be of general interest but are still pearls. That's what jolokia-extra is for.
The beginning makes a 1.5 year old pull request from Marcin Płonka (Thanks a lot and sorry for the long, long delay, BTW). It's all about simplifying access to JSR-77 enabled JEE-Servers. You should know that JSR 77: J2EE Management was a cool attempt to standardize naming and JMX exposed metrics for JEE. Unfortunately it was abandoned, but still lives in quite a bunch of JEE servers. Not at its full beauty, but still valuable enough to be supported. Astonishingly, WebSphere, even the latest 8.5 versions, has the best support for it. Using JSR-77 conform MBeans with plain Jolokia returns unnecessarily complex JSON structures which are hard to parse and understand. jolokia-extra adds a set of simplifier for make the usage with JSR-77 simpler (but add an extra of 50k to the agent). I recommend to have a look at it, especially if you are working with WebSphere.
In the future, it might be the case, that some lesser used additions (Spring and Spring Roo integration, JBoss Forge support, ...) will go into jolokia-extra as well.
Enough blubber, enjoy this release. And just in case, if anybody is wondering about 2.0 (BTW, is there anyone out there carrying about this next generation JMX transcended super-hero ?), just drop a note with twitter (@jolokia_jmx) or mail ([email protected]).
This minor release fixes some bugs and brings some smaller features:
And finally there is an important addition to the configuration of Jolokia's access policy. You might know, that you can configure CORS so the agent allows access only from certain origins. CORS is used by browsers for cross origin sharing and is a pure client side check. I.e. the browser asks the server and if the server says "no" the browser forbids any Ajax request to this server from any script. However, this still allows non-Ajax requests from any origin. To restrict this, too, a new configuration directive <strict-checking> has been added to the <cors> section which, if given, will do also a server-side check of a Origin: header when provided by the browser. If a security policy is used, it is highly recommended to set this flag (which for compatibility reason is switched off by default). And yes, it is of course highly recommended to use a jolokia-access.xml policy in production (and not only for servers exposed to the bad internet directly). This is especially important if you can access Jolokia agents directly via a browser which is also used for internet access (hint: CSRF).
No news about 2.0 ? Yes, indeed. The giant is still sleeping, "Jolokia forever", you know. But the pressure rises, for some conferences I have some CFPs out which hopefully will lead to some nice CDD sessions ("conference driven development", yeah).
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 220.127.116.11, 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 ...
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.
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.
That's it and I hope you enjoy this release. I know, I'm late with 2.0, but as things happens, I have too much to do in 'real life' (i.e. feeding my family ;-). But I still hope to get it out this year, and yes, the 2.0 branch is growing (slowly).
So please stay tuned ....
In order to ease waiting for 2.0, Jolokia version 1.1.2 has been released. 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.
This last feature release before work on 2.0.0 starts brings some small goodies.
Links to the corresponding GitHub issues and the bugs fixed in this release can be found in the change report.
This is the last feature release in the 1.x series. Work has already started on exciting new features for Jolokia 2.0. E.g. JMX notification support is coming, an initial pull model has been already implemented (on branch notification). There are even more ideas and some refactorings will happening along with some modest changes in the module structure. So, please stay tuned ...
It took some time, but it was worth it. Along with the usual bug fix parade, several new features has been added to Jolokia.
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>
More details can be found here in the reference manual.
The new jolokia-jmx module provides 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:
The details can be found here.
Several new processing options enter the scene. These can be given either as global configuration parameters or as query parameters:
That's it for now, all changes are summarized as always in the change report.
Some other, more organizational stuff for now:
And finally a very hot recommendation: Please have a look at hawt.io a super cool HTML5 console which uses Jolokia for backend communication exclusively. Most of the new ideas included in this Jolokia release were inspired by discussions with James Strachan, one of the driving forces behind hawt. Thanks for that ;-)
Some other tidbits:
Jolokia 1.0.5 has been released. Beside minor improvements and bug fixes, one great new feature has been introduced: As already mentioned Jolokia has now support for Cubism, a fine time series charting library based on d3.js. Cubism provides support for an innovative charting type, the horizon charts:
Jolokia uses also a Travis build in addition to our own CI Server. (Did I mentioned already, that we have a quite I high Sonar score ?). Travis is a quite nice supplement to Github, and brings CI testing to a higher level.
That's it for now. The next months of my open-source work will be spent now on Ají, Jolokia's new fancy sister. Sorry for pushing thinks like notifications down the Jonlokia back-log, but it's not forgotten.