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 enviroment optimized for HTTP communication should be used. These are either servlet container or JEE server hosting the WAR agent or an OSGi runtime with an OSGi HttpService (which in turn is typically based on an embedded serlvet container like Tomcat or Jetty). The two other agents, the Mule and JVM agents are not that well suited for this job.
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.