Agents

Clients

Project Documentation

It is fast, simple, polyglot and has unique features.
It's JMX on Capsaicin.

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.

News

Polished with 1.3.5

2016-10-04

Here comes a minor update with some smaller goodies:

Support of JSON streaming also for the AgentServlet which is included in the WAR and OSGi Agent (in addition
to the JVM agent which got this support in the last release). This leads to much less temporary heap memory
consumption when serializing the internal JSON objects to character data in the HTTP response. You still
need to be careful when doing large operations like list since there is still a full in-memory
representation of the data sent.

Avoid an NPE in the Websphere detector and added detection of a Payara server

Summer fun with Jolokia 1.3.4

It has beed taken a bit, but just right now befire the summerbreak 1.3.4 is here with
some nice new features:

SSL support for the J4pClient.

JSON response streaming to reduce memory activity. This is enabled by default but can
be switched off by setting the config option "streaming" to false.

Allow a basic auth as alternative to client cert authentication when both a user and
client certifcates are used.

A "quiet" and a java.util.logging LogHandler which can be directly used.

In parallel 2.0 takes comes into shape. The current version 2.0.0-M3 is available and already
used with success in some production setups. In addition to the new features like notification support
or new extension hooks, it is fully backwards comptabile to 1.x, except that some default values will
be changed. However, an upgrade will be trivial. If you are curious, I'm going to present the new 2.0
features at JavaZone in September.

That's it for now, enjoy your summer break ;-)

Jolokia 1.3.3

2016-02-16

Beside bug fixes as described in the changelog, this minor
release brings some small features:

Custom restrictors for tuning access control can be added to the JVM and WAR agents (which already
is supported by the OSGi agent for quite some time)

Global configuration option allowErrorDetails can be used when starting the agent to avoid
exposure of stack traces and exception messages globally.

Configuration allowDnsReverseLookup can be set to false in order to avoid
reverse DNS lookup for doing security host checks. That also implies that if switched off only
plain IP adressess can be used in a jolokia-access.xml policy file.

The password for opening a JVM agent's keystore can now be encrypted, too. You can use the
java -jar jolokia-agent.jar encrypt CLI to encrypt a password which then can be used in the
agent's configuration.

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

2016-01-07

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

I would be more than happy if you would try out the JAR and
WAR agent which are supposed to be drop in replacements for Jolokia 1.3.2.

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.

TLS updates for the JVM agent

2015-10-5

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
:)

Delegating Authentication with Jolokia 1.3.1

2015-05-28

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:

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.

Jolokia 1.3.0

2015-05-07

After quite some winter sleep Jolokia is back with a fresh
release. This is mostly a bug fix release with some new features:

A simple MBeanPlugin hook for registering own MBeans with the agent

Support for OSGi's ConfigAdmin Service

New possibility to hook into the deserialization process for responses in the Java client

Proxy can be specified for the Java client

Constructor based deserialization of Strings

Support for Mule 3.6.1

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 ? Jolokia2.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!

Autumn edition 1.2.3

2014-11-08

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:

SSL handling of the JVM agent has been fixed and
improved. Authentication with client certificates works
now and you have much more influence of the SSL
setup. Kudos to Neven Radovanović for
providing a patch.

The Mule agent has been updated to support Mule
3.5. Thanks to Fei Wong Reed
for the pull request.

The configuration option "policyLocation" has now system
property and environment expansions.

Quite a bunch of bugs has been fixed. Please refer to the
changes report for all
changes.

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.

Knock, knock: Let's welcome 1.2.2

2014-06-14

Let's welcome Jolokia's next minor release which is not so
minor as it might seems.

Custom authenticator support for the Java client. The
standard authenticator allows preemptive authentication now
as well.

Support for "*" wildcard in paths. See below.

Finally an update to json-simple-1.1.1 which is mavenized,
but still has its issues and not much traction to fix
it. No problem we have a good workaround and it is still
rock solid.

Bug fixes. Yep.

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):

If using a literal path, then everything works as expected:
The value the path points to is returned. Mostly this is a
scalar value because that is what paths was introduced for.

If the path contains a single "*" as a part, then when
coming to this level everything is included. A
path containing a wildcard cannot be a scalar anymore, but
is a JSON object or array. The remaining path parts are
included as described above to each element at this level.

A path can contain multiple wildcards, but wildcards can
be used only on its own. If a "*" is used as part of a
path part (like 'current*'), it's taken literally (which
most of the time doesn't make much sense). This might
change in the future.

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]).

1.2.1 is in the house

The Java client library has been updated to the latest Apache HTTP components 4.x.
If you are forced to still use Apache HTTP Client 3.x, you still can use the Java Client Lib from
Jolokia 1.2.0 which will work with a Jolokia agent 1.2.1 nicely.

Bug fix for JBoss 4.2.3 (yeah, seems still to be used)

Cleaned up logging for discovery requests

Placeholders can be used when specifying the agent URL which will be used in discovery responses.
That way you can configure the URL flexibly from you server configuration.

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

Find your agents with 1.2.0

2014-02-24

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

Tiny 1.1.5

2013-11-08

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.

Next week is Devoxx time and as last year (and the years before) you have the change to meet me in
Antwerp. Ping me or look for the guy with the Jolokia hoodie ;-)

Step by step ... 1.1.4

2013-09-27

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

BTW, the slides to my talk for the small but very fine JayDay 2013 are online, too.
These are "implemented" in JavaScript including live demos, where the JavaScript can be directly inserted
in the browser (tested with Chrome & Firefox). For the sample code, simply push the blue buttons at the
bottom of a demo slide.

Small fixes with 1.1.3

2013-07-30

No big news in Jolokia land, but some bug fixes come with 1.1.3. Especially some issues
with the JavaScript client's
basic authentication and cross origin requests has been fixed. Otherwise I'm busy with 2.0 (and tons
of other stuff ...). You can have a sneak preview of Jolokia 2.0 on this branch
including basic notification support and quite some refactoring with respect to the service architecture.

So please stay tuned ....

Stopover on the road to 2.0: Jolokia 1.1.2 released

2013-05-28

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.

In the meantime, you can also see Jolokia live at JayDay where I will give a talk about
Jolokia's JavaScript support. The forthcoming JMX notification support will presented, too. It is also
a good chance to have a cold bavarian beer with me ;-)

Some small goodies served by 1.1.1

2013-03-27

This last feature release before work on 2.0.0 starts brings
some small goodies.

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

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

1.1.0 with Spring support and @JsonMBean

2013-02-26

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:

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:

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 names

serializeExceptions adds a JSON representation of exceptions in an error case

includeStackTrace can switch on/off the sending of an lengthy stack trace in an error case

That's it for now, all changes are summarized as always in the change report.

Some other, more organizational stuff for now:

Bugtracking and feature requests switch over completely to Github.
Since I'm currently collecting features for 2.0, it's a good time for feature requests ;-). All ideas entered
at jolokia.idea.informer.com has been transformed into Github issues.

If you are close to Germany it might be of interest to you, that I'm giving a training on Jolokia and Jmx4Perl,
with focus on Java Monitoring with Nagios. This will happen at 16./17.04.2013 in Munich, details can be
found on our web site
(in german).

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 ;-)

1.0.6 cosmetics

2012-11-23

Although it has been quite calm in Jolokia land for some
months, there is quite some momentum around Jolokia. This
minor release brings some cosmetic changes, mostly for
tuning the ordering within MBeans names and some JavaScript
fixes. More on this in the changelog.

I'm going to talk about Jolokia at jayday 2012, a brand new, low cost
conference in Munich on 3th December 2012. Hopefully there will be some brand new stuff to show, too.

Some completely irrelevant stuff: Jolokia T-Shirts can be found in the Jolokia Shop
The shop was too easy to setup for not doing it ;-) And they look freaking hot ....

Cubism support in 1.0.5

2012-07-22

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:

A very cool live demo where a Jolokia JavaScript client
fetches live data from our servers and plot it with Cubism
can be found on this demo page.
The documentation can be found in the reference manual.

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.