Using Jolokia in proxy mode enables for agentless operation on the target server. A dedicated agent deployment proxies by accepting Jolokia requests as input, translating them to JSR-160 requests for the target. This setup is described in Chapter 2, Architecture. As noted there, the real target is given within the original request, which must be sent as a POST request.
Agents of all types support the proxy mode. However, since one has usually the free choice of platform for a dedicated Jolokia proxy, an environment optimized for HTTP communication should be used. These are either servlet container or Java EE server hosting the WAR agent or an OSGi runtime with an OSGi HttpService (which in turn is typically based on an embedded servlet container like Tomcat or Jetty). The two other agents, the Mule and JVM agents are not that well suited for this job and do not contain the proxy.
Please note that the proxy mode is not switched on by default since version 1.5.0. You have to explicitly switch it on for the WAR or OSGI agent:
web.xmlto include the init option
dispatcherClasseswith a value
The first option requires you to repackage the
jolokia.war and add the following section to
<init-param> <description> Classnames (comma separated) of RequestDispatcher used in addition to the LocalRequestDispatcher </description> <param-name>dispatcherClasses</param-name> <param-value>org.jolokia.jsr160.Jsr160RequestDispatcher</param-value> </init-param>
The two other options by using a Java system property or an environment variable do not require a repackaging, so these are the recommended way.
Additionally you can configured a white list with patterns for all allowed JMX service URL in a Jolokia Request.
This white list is a plain text file which contains Patterns line by line. Lines starting with
# are ignored.
Pattern matching is performed case insensitive. This file can be configured in various ways:
web.xmlto include the init option
jsr160ProxyAllowedTargetswith a file path to the white list. This should be an absolute path or a relative path if you know where your Java EE server sets the current directory.
org.jolokia.jsr160ProxyAllowedTargetsto the path of the whitelist
JOLOKIA_JSR160_PROXY_ALLOWED_TARGETSto the path of the whitelist.
By default the following patterns are disallowed, but you can re-enable them when providing them in the whitelist:
# Disallow all JNDI lookups via LDAP service:jmx:rmi:///jndi/ldap:.*
In any case it is highly recommended to use a dedicated Java EE servlet server for the JSR-160 proxy which is secured by configuring the server authentication properly for this servlet. An unprotected Jolokia proxy can be tricked to execute local code by a malicious attacker. As said previously, the Jolokia proxy should be avoided if possible in favor of direct access over the Jolokia protocol.
The proxy mode has some limitations compared to the direct agent mode, so it is recommended to use a direct agent deployment if possible. The limitations are:
PlatformMBeanServer(which is always present). Each MBean is registered only in one MBeanServer. The choice of which
MBeanServerto use has to be given up front, usually as a part of the JMX Service URL. But even then (as it is the case for JBoss 5.1) you might run into problems when selecting the proper MBeanServer.
listmight fail in the proxy mode because of serialization issues. E.g. for JBoss it happens that certain MBeanInfo objects requested for the list operation are not serializable. This is a bug of JBoss, but I expect similar limitations for other application servers as well.
Listit is required that
json-simple.jar) are available on the classpath of the target JVM that receives the JSR-160 requests.