Welcome to 2016 - the year Jolokia 2.0 will see the light of day

January 6, 2016

I hope you all had a good start into 2016 and have charged all your batteries during the time of stillness.

Jolokia had a good start, too. During the holiday season I took the opportunity to continue to work on version 2.0 which now takes on form. If you have followed the history of Jolokia you know that work on 2.0 started early 2013 but advanced quite slowly for multiple reasons.

Now its time to go out on a limb with announcing Jolokia 2.0 for 2016. A bit of pressure sometimes really helps ;-)

Here’s are the major themes for Jolokia 2.0:

  • Jolokia 2.0 will be backwards compatible on the protocol level. This is a design goal. There might be some changes in default values, however this should be easy to fix. Any such change will be announced prominently (like artefact renaming). So, all your clients will be usable with 2.0 with minor changes.
  • JMX Notification support is here. Yeah, this was quite some work. The extensions to the Jolokia 2.0 protocol are able to push notifications in various ways. Currently the agents supports two modes:

    • Pull mode will collect JMX notification on the server (agent) side and can be fetched by a client with an HTTP request, which typically happens periodically. This introduces some latencies but is the most robust way to transmit notifications to a client.
    • SSE mode uses Server Sent Events for pushing JMX notifications immediately with very low latency. This is the preferred mode if a client supports this (Internet Explorer does not).

    The notification support is nearly complete on the agent side, and the Jolokia JavaScript client already supports both modes. In the future more mode like WebSockets or Web-Hooks should be easy to add. The next post will give a demo about the notification support.

  • Namespaces extend Jolokia beyond JMX which means you can access other entities than JMX MBeans with the very same protocol. This feature is still in the conceptual state but one can easily imagine to access

    • Spring Beans
    • CDI Objects
    • JNDI Directories
    • Zookeeper Directories
    • ….

    the same was as JMX. The namespace is selected as part of the (MBean) name. More on this in this design document. Since this feature would extend the usage pattern of Jolokia quite a bit, I’m not 100% sure whether to include it into 2.0 since it feels a bit against my Unix based education (“do one thing and do it well”).

  • With the addition of even more features, modularization becomes even more important. Jolokia was and is always picky about its footprint, which is currently 430k for the WAR agent with all features included. Jolokia 2.0 introduces various internal services which can be picked and chosen by repackaging the agent. Or the agent can be extended with own functionality, too. A way for easily packaging and creating agents will be provided either by a Web-UI or by a CLI tool (or both).

In addition there are also some non-functional changes to polish Jolokia a bit:

  • Non-agent based addition like client libraries, integration tests, JBoss Forge support are extracted into extra GitHub repositories. All this will happen within the GitHub organization jolokia-org. The first project here is the JavaScript client which already moved to a dedicated jolokia-client-javascript repository.
  • The website will get a face-lift.
  • Documentation will switch from Docbook to a Markdown or AsciiDoc based format.

Finally some stuff will get dropped. This happens because of limited resources (Jolokia, to be frankly, still doesn’t have a big community, so that most of the work is done by a single person. ‘would like to change that, though) and because I think these feature never took off:

  • Mule agent. I never got much feedback from the Mule community so I’m really not sure whether this agent is really used or needed. Jolokia 1.x will continue to support the Mule agent, however there will be no stock Jolokia 2.0 Mule agent. Said that, you are always free to adopt Jolokia 2.0 to the Mule management platform. Considering the extra code needed included in Jolokia 1.3 for Mule support this should be fairly trivial. I’m happy to support anyone doing the port. Also, there is always the alternative to use the JVM agent for attaching Jolokia to Mule, which is the preferred way for 2.0 to monitor Mule with Jolokia.
  • Spring Roo Support will be dropped for much the same reasons. I never received an issue on the Jolokia Spring Roo support, which is a clear sign that nobody is using it. It might popup as an extra project.

So, what’s the roadmap ? Here’s the plan:

  • Milestone 2.0.0-M1 is here. You find the JVM and WAR agents in Maven central.
  • Every month, a new milestone will be released.
  • Final release is aligned to Red Hat Summit / DevNation. July 1st.

Isn’t this a nice new year’s resolution ? ;-)

In the next post I will demo JMX notifications and how you can use them in your JavaScript projects.