Git Product home page Git Product logo

jolokia's Introduction

Jolokia - JMX on Capsaicin

Maven Central Build Status Coverage Technical Debt

Jolokia is a fresh way to access JMX MBeans remotely. It is different from JSR-160 connectors in that it is an agent-based approach which uses JSON over HTTP for its communication in a REST-stylish way.

Multiple agents are provided for different environments:

  • WAR Agent for deployment as web application in a Java EE Server.
  • OSGi Agent for deployment in an OSGi container. This agent is packaged as a bundle and comes in two flavors (minimal, all-in-one).
  • JVM+ Agent which can be used with any Oracle/Sun JVM, Version 11 or later and which is able to attach to a running Java process dynamically.

Features

The agent approach as several advantages:

  • Firewall friendly

    Since all communication is over HTTP, proxying through firewalls becomes mostly a none-issue (in contrast to RMI communication, which is the default mode for JSR-160)

  • Polyglot

    No Java installation is required on the client side. E.g. Jmx4Perl provides a rich Perl client library and Perl based tools for accessing the agents.

  • Simple Setup

    The Setup is done by a simple agent deployment. In contrast, exporting JMX via JSR-160 can be remarkable complicated (see these blog posts for setting up Weblogic and JBoss for native remote JMX exposure setup)

Additionally, the agents provide extra features not available with JSR-160 connectors:

  • Bulk requests

    In contrast to JSR-160 remoting, Jolokia can process many JMX requests with a single round trip. A single HTTP POST request puts those requests in its JSON payload which gets dispatched on the agent side. These bulk requests can increase performance drastically, especially for monitoring solutions. The Nagios plugin check_jmx4perl uses bulk requests for its multi-check feature.

  • Fine grained security

    In addition to standard HTTP security (SSL, HTTP-Authentication) Jolokia supports a custom policy with fine grained restrictions based on multiple properties like the client's IP address or subnet, and the MBean names, attributes, and operations. The policy is defined in an XML format with support for allow/deny sections and wildcards.

  • Proxy mode

    Jolokia can operate in an agentless mode where the only requirement on the target platform is the standard JSR-160 export of its MBeanServer. A proxy listens on the front side for Jolokia requests via JSON/HTTP and propagates these to the target server through remote JSR-160 JMX calls. Bulk requests get dispatched into multiple JSR-160 requests on the proxy transparently.

Resources

Even more information on Jolokia can be found at www.jolokia.org, including a complete reference manual.

Contributions

Contributions in form of pull requests are highly appreciated. All your work must be donated under the Apache Public License, too. Please sign-off your work before doing a pull request. The sign-off is a simple line at the end of the patch description, which certifies that you wrote it or otherwise have the right to pass it on as an open-source patch. The rules are very simple: if you can certify the below (from developercertificate.org):

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
660 York Street, Suite 102,
San Francisco, CA 94110 USA

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

Then you just add a line to every git commit message:

Signed-off-by: Max Morlock <[email protected]>

Using your real name (sorry, no pseudonyms or anonymous contributions.)

If you set your user.name and user.email git configs, you can sign your commit automatically with git commit -s.

If you fix some documentation (typos, formatting, ...) you are not required to sign-off. It is possible to sign your commits in retrospective, too if you forgot it the first time.

jolokia's People

Contributors

a1exsh avatar apupier avatar arnabbiswas1 avatar bcubk avatar chirino avatar coheigea avatar dependabot[bot] avatar elmiko avatar elnkwelch avatar georgy avatar gnufied avatar gregbowyer avatar grgrzybek avatar jc-roman avatar jp30566347 avatar jstrachan avatar khaing211 avatar nevenr avatar ogis-nakagawa avatar pgier avatar qtc-de avatar rhuss avatar robstryker avatar rraez avatar ryandgoulding avatar sgbeal avatar shisheng-1 avatar skarsaune avatar tadayosi avatar tempredirect avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

jolokia's Issues

support raw rather than canonical ObjectNames being returned

when turning JMX object names into a tree, the order of the a=x,b=y becomes very important. Some JMX trees use various of these (e.g. try browsing things like Apache ActiveMQ or Camel in jconsole).

AFAIK jolokia only returns canonical (i.e. sorted) object names; I'd like to be able to return 'raw' object names in their normal order.

I'm nooding the code to see how to do this; if I get anywhere i'll try submit a patch if that helps. I thought I'd raise this issue now in case anyone spotted a way todo it before I do a deep dive of the code :)

My current guess is it might be nice to add a query parameter to allow raw object names to be used (so using ObjectName.toString() instead of ObjectName.getCanonicalName()

malformed javadoc in AgentServlet

The Javadoc for the AgentServlet class contains a link. The url is in quote marks that are opened but not closed. The closing > for the html is also missing.

VirtualMachineHandlerTest Fails In Some Cases

If the OS where the test is running has a combination of 32 and 64 bit management enabled JVMs, this test fails because it attempts to connect every located VM.

Example Stack Trace:

org.jolokia.jvmagent.jdk6.client.VirtualMachineHandlerTest:listAndAttach

InvocationTarget class com.sun.tools.attach.VirtualMachine
org.jolokia.jvmagent.jdk6.client.VirtualMachineHandler.attachVirtualMachine(VirtualMachineHandler.java:69)
at org.jolokia.jvmagent.jdk6.client.VirtualMachineHandlerTest.listAndAttach(VirtualMachineHandlerTest.java:67)
30 lines not shown

Caused by null
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jolokia.jvmagent.jdk6.client.VirtualMachineHandler.attachVirtualMachine(VirtualMachineHandler.java:65)
at org.jolokia.jvmagent.jdk6.client.VirtualMachineHandlerTest.listAndAttach(VirtualMachineHandlerTest.java:67)
30 lines not shown

Caused by Unable to attach to 32-bit process running under WOW64
sun.tools.attach.WindowsVirtualMachine.openProcess(Native Method)
at sun.tools.attach.WindowsVirtualMachine.(WindowsVirtualMachine.java:38)
at sun.tools.attach.WindowsAttachProvider.attachVirtualMachine(WindowsAttachProvider.java:52)
at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:195)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jolokia.jvmagent.jdk6.client.VirtualMachineHandler.attachVirtualMachine(VirtualMachineHandler.java:65)
at org.jolokia.jvmagent.jdk6.client.VirtualMachineHandlerTest.listAndAttach(VirtualMachineHandlerTest.java:67)
30 lines not shown

JsonSerializationTest.complexSerialization() Fails On Windows

The issue occurs because a java.io.File is serialized with an explicit Unix type forward slash separator. The deserialized name is [cleverly] converted to the Windows backslash separator so the compare fails.

Stack Trace:

org.jolokia.client.request.JsonSerializationTest:complexSerialization

expected: but was:<\tmp>
org.testng.Assert.fail(Assert.java:89)
at org.testng.Assert.failNotEquals(Assert.java:443)
at org.testng.Assert.assertEquals(Assert.java:113)
at org.testng.Assert.assertEquals(Assert.java:123)
at org.jolokia.client.request.JsonSerializationTest.complexSerialization(JsonSerializationTest.java:101)
30 lines not shown

Improve support for different backends other than JMX

Jolokia supports currently support two different so called RequestDispatcher:

  • A LocalRequestDispatcher for directly querying the local JMX subsystem. This dispatcher is always present
  • A Jsr160RequestDispatcher which is used as proxy to another remote JSR-160 exposed JVM instance. This dispatcher is optional and kicks in when a target section is present in the initial JSON request.

RequestDispatchers can be configured with the configuration variable dispatcherClasses and must provide a three argument constructor to get a reference to its context (see the implementations above for examples). The dispatcher are given as a comma separated list in this configuration variable and must be creatable by the Jolokia agent.

However this mechanism is somewhat rusty:

  • There should be support for automatic lookup via OSGi services (whiteboard pattern)
  • The API for the dispatcher is not really polished (and was up to now only somewhat internal)
  • Maybe the incoming request should have a dedicated field for selecting the dispatcher (instead of letting the dispatcher examing the requests)

More on this later, have to leave now ...

Provide a way to set request options when using "register"

Found out that when you use register() to continuously poll a bean you can't specify options such as canonicalNaming, just success and error callbacks. It'd be nice if it was possible to specify the same set of options to register() that can be set when calling request()

java.lang.reflect.InvocationTargetException activemq

OS: Ubuntu 11.04
java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.2) (6b22-1.10.2-0ubuntu1~11.04.1)
OpenJDK Client VM (build 20.0-b11, mixed mode, sharing)

ActiveMQ 5.5.0

jamesg@blofeld:~$ ps ax | grep java
8609 pts/0 S+ 0:00 grep java
19046 ? Sl 5:27 /usr/bin/java -Xms256M -Xmx256M -Dorg.apache.activemq.UseDedicatedTaskRunner=true -Djava.util.logging.config.file=logging.properties -Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.password.file=/opt/activemq/conf/jmx.password -Dcom.sun.management.jmxremote.access.file=/opt/activemq/conf/jmx.access -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=10.0.0.29 -Dactivemq.classpath=/opt/activemq/conf; -Dactivemq.home=/opt/activemq -Dactivemq.base=/opt/activemq -jar /opt/activemq/bin/run.jar start

jamesg@blofeld:~$ sudo java -jar jolokia-jvm-1.0.0-agent.jar --host 10.0.0.29 --agentContext /jolokia/ list
19046 /opt/activemq/bin/run.jar start
10067 jolokia-jvm-1.0.0-agent.jar --host 10.0.0.29 --agentContext /jolokia/ list

jamesg@blofeld:~$ sudo java -jar jolokia-jvm-1.0.0-agent.jar --host 10.0.0.29 --agentContext /jolokia/ start 19046
InvocationTarget class com.sun.tools.attach.VirtualMachine: java.lang.reflect.InvocationTargetException

Any ideas?

Wrong object name assigned in Config.java

Roland,

I think I may found the bug we were talking about on my pull request. On Config.java:

public ObjectName preRegister(MBeanServer server, ObjectName name) throws MalformedObjectNameException {
    return new ObjectName(objectName);
}

It probably should be new ObjectName(name) instead.

connector to graphite / statsd etc

This one came up in the vertx community discussion around JMX and metrics etc
https://groups.google.com/forum/?fromgroups=#!topic/vertx/dqeE42_A-_Q

In the past I've used jmxtrans so that we can poll for jmx attributes and write them to one of a few different outputs (e.g. graphite / statsd). Most of these stat collectors take strings or JSON these days; so a connector is usually a pretty simple class.

e.g. here's the jmxtrans code to write attributes to graphite
https://github.com/jmxtrans/jmxtrans/blob/master/src/com/googlecode/jmxtrans/model/output/GraphiteWriter.java#L105

So given jolokia already has awesome URIs / JSON APIs to JMX and hides all the JMX crap :) - it would be pretty easy to configure in jolokia's XML config (or maybe via REST JSON calls on an mbean or something), to have a timer which polls a number of JMX attributes on a number of mbeans (using wildcards as jolokia already supports) then outputting them to an output source like graphite / statsd.

We could just reuse code from jmxtrans; but given how simple it is; just the odd class or two might do it. What some folks struggle with is figuring out which servers are running & where. So it might be nice if over jolokia HTTP/REST we could configure the servers at runtime. e.g. a JVM ships with sets of JMX attributes it would poll and report to graphite/statsd - then at runtime someone POSTs some JSON to define the running servers & then it starts firing requests. Or folks hard code it in the jolokia XML.

Given the proxying and REST/JSON of jolokia & its container agnostic easy integration with all JVMs; it could end up being a handy way to either push stats somewhere or to pull remote stats from remote JVMs (maybe which don't have jolokia inside them) and then write to graphite/statsd etc?

NPE on J4pClient.execute

Hello,
When running the following code, I'm getting a NullPointerException
request = new J4pReadRequest(jmxName, "MetricsTimestampsAndData");
J4pReadResponse resp = j4pClient.execute(request);

org.jolokia.client.exception.J4pRemoteException: java.lang.NullPointerException
at org.jolokia.client.J4pClient.validate(J4pClient.java:197) ~[jolokia-client-java-0.80.jar:na]
at org.jolokia.client.J4pClient.execute(J4pClient.java:88) ~[jolokia-client-java-0.80.jar:na]
at org.jolokia.client.J4pClient.execute(J4pClient.java:66) ~[jolokia-client-java-0.80.jar:na]

Thanks,
Ludovic

The build is creating manifests with test dependancies

I just build the agent using 'mvn clean install' and the osgi build produces a bundle with the following in its manifest.

Import-Package: ......,org.easymock,......,org.testng,org.testng.annotations,.......

Chris.

OSGi deployment on Glassfish 3.1.1 causes an exception

Deployment of the jolokia-osgi-1.0.2.jar bundle to glassfish 3.1.1 causes an exception to be logged.

javax.management.InstanceAlreadyExistsException: jolokia:type=ServerHandler
    at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
    at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
    at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
    at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
    at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
    at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:512)
    at com.sun.enterprise.v3.admin.DynamicInterceptor.registerMBean(DynamicInterceptor.java:472)
    at org.jolokia.detector.ServerHandle.registerMBeanAtServer(ServerHandle.java:144)
    at org.jolokia.backend.MBeanServerHandler.registerMBean(MBeanServerHandler.java:151)
    at org.jolokia.backend.MBeanServerHandler.init(MBeanServerHandler.java:59)
    at org.jolokia.backend.LocalRequestDispatcher.init(LocalRequestDispatcher.java:99)
    at org.jolokia.backend.BackendManager.initStores(BackendManager.java:225)
    at org.jolokia.backend.BackendManager.<init>(BackendManager.java:110)
    at org.jolokia.http.AgentServlet.init(AgentServlet.java:152)
    at org.jolokia.osgi.servlet.JolokiaServlet.init(JolokiaServlet.java:91)
    at org.glassfish.osgihttp.OSGiServletWrapper.initializeServlet(OSGiServletWrapper.java:89)
    at org.glassfish.osgihttp.GlassFishHttpService.registerServlet(GlassFishHttpService.java:103)
    at org.glassfish.osgihttp.HttpServiceWrapper.registerServlet(HttpServiceWrapper.java:93)
    at org.jolokia.osgi.JolokiaActivator$HttpServiceCustomizer.addingService(JolokiaActivator.java:170)
    at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896)
    at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)
    at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184)
    at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:339)
    at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:273)
    at org.jolokia.osgi.JolokiaActivator.start(JolokiaActivator.java:77)
    at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783)

This can be recreated by simply getting the standard GF 3.1.1 zip file and dropping the bundle into glassfish/domains/domain1/autodeploy

Having debugged the issue a couple of times I have figured out that this is caused by GF having more than one HttpService, by default there is a admin virtual server and the default service. The ServiceTracker gets a call back for each of these matching HttpService implementations, the first of course works and initialises the AgentServlet corrently the second fails to expose the backing store beans.

Possible solutions:

  1. Maintain singletons for the backing stores and ensure they are only exposed just once
  2. Maintain different backing stores for each AgentServlet and have some sort of extra key on the object name to make them unique

As an additional feature, it might be a good idea to provide a configuration option to allow binding to just one of the services, i.e. allow the OSGi service filter to be customisable.

Jolokia config initialization

In current version 1.0.6 there is a ServerConfig class, which I use as follows:

String agentArgs = "host=" + host + ",port=" + port;
ServerConfig config = new ServerConfig(agentArgs);
JolokiaServer jolokiaServer = new JolokiaServer(config, false);

In version 1.1.0-Snapshot there is JolokiaServerConfig instead of ServerConfig with some 'init...' methods, but they are marked as 'protected', or 'private'. Can you give me some advice how to initialize JolokiaServer configuration please?

maven build failure

[ERROR] Failed to execute goal com.devspan.mojo.javascript:javascript-maven-plugin:0.9.3:war-package (default) on project jolokia-client-javascript-test-app: Failed to unpack javascript dependencies: Failed to extract javascript artifact to /Users/jolokia/client/javascript/test-app/target/jolokia-client-javascript-test-app-0.91-SNAPSHOT/scripts/lib: The source must not be a directory.

websocket support for real time JMX views

it would be handy if under the covers of the JavaScript client it could detect if some websocket implementation was available on the server, and if so use that instead of polling; otherwise fall back to polling.

e.g. for watching a bunch of JMX attributes, the server side could use JMX notifications and fire them over websockets (if the client + server support them).

this is more of a long term idea really ;) - its mostly just an optimisation since we've polling anyway though

serializeException functionality issue

Hi,
I am testing new serialize exception functionality included in 1.1.0-snapshot version. It works fine when I am trying it for example with curl like this:

curl http://<host>/jolokia/write/<object-name>/<variable>/<value>?serializeException=true

However, I don't know how to programmatically set this functionality on. I think it would be nice if org.jolokia.client.request.J4pQueryParameter enum would contains SERIALIZE_EXCEPTION constant (similarly like ConfigKey enum). Then I think it will be possible to perform call like this:

Map<J4pQueryParameter,String> pProcessingOptions = new HashMap<J4pQueryParameter,String>();
pProcessingOptions.put(J4pQueryParameter.SERIALIZE_EXCEPTION, "true");

J4pClient j4pClient = new J4pClient(jolokiaUrl);
J4pExecRequest execReq = new J4pExecRequest(objectName, operationName);
j4pClient.execute(execReq, "POST", pProcessingOptions);

Glassfish detector fails to boot AMX

In certain circumstances, the Glassfish-Detector fails to bootAmx. This can happen during startup, when the first Jolokia Request is served by the agent before the AMX-Support MBean is registered. In this case, the bootAmx hook fails in the agent but is never tries again.

Detect the Jetty packaging of Eclipse Virgo.

We now have a third packaging of Virgo based on Jetty, so in the org.jolokia.osgi.detector.VirgoDetector class could something like this be added to replace line 36.

String type;
if(getBundleVersion("org.eclipse.gemini.web.core") != null){
type = "tomcat";
} else if(getBundleVersion("org.eclipse.jetty.osgi.boot") != null ){
type = "jetty";
} else {
type = "kernel";
}

Notice that calling the first one tomcat instead of gemini would be better. We have renamed our generic web server release the tomcat release.
Thanks.

Support for OpenTypes for write or exec arguments

We have an API build on top of MXBeans so there's quite a few occurrences of operations with CompositeData arguments. It's nice that jolokia allows you to read CompositeData attributes and return values, but it looks like you can't write them or pass them as arguments to operations.

I think it would be pretty cool to have this ability, and it shouldn't be much different than converting to JSON objects while reusing the existing simple converters recursively for the simple types inside the CompositeData.

error building site pages

Hi Roland!

i don't know if this is a bug in the pom/mvn setup or on my local machine:

mvn site:site

runs for about 3 minutes and generates several pages, but then dies with:

[INFO] Generating "Project Team" report.
[WARNING] Deprecated API called - not org.apache.maven.doxia.sink.Sink instance and no SinkFactory available. Please update this plugin.
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] 1
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.ArrayIndexOutOfBoundsException: 1
at org.apache.maven.doxia.module.xhtml.XhtmlSink.tableCell(XhtmlSink.java:791)
at org.apache.maven.doxia.module.xhtml.XhtmlSink.tableHeaderCell(XhtmlSink.java:777)
at org.apache.maven.reporting.AbstractMavenReportRenderer.tableHeaderCell(AbstractMavenReportRenderer.java:267)
at org.apache.maven.reporting.AbstractMavenReportRenderer.tableHeader(AbstractMavenReportRenderer.java:356)
at org.apache.maven.report.projectinfo.TeamListReport$TeamListRenderer.renderBody(TeamListReport.java:160)
at org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
at org.apache.maven.report.projectinfo.TeamListReport.executeReport(TeamListReport.java:58)
at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:144)
at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139)
at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:303)
at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:133)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:100)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

Ideas?

Extend Jolokia Roo-Addon

The Jolokia Roo-Addon (under tools/roo-addon) currently only add the WAR agent to a web.xml for Web projects. Now with the new Spring support in place this add-on can be extended:

  • Allow the addition of <jolokia:agent> to the application context, along with all possible configuration options (or at least the most importan)
  • Allow the addition of @JsonMBean to JMX exposed classes.
  • Add a possibility to add the Jolokia MBeanServer to <context:mbean-export>

Change default behaviours

For 2.0.0, some default behaviours should be changed, because it turned out, that these are the common use case:

  • canonicalNaming=false should be the default for listing MBeans since this is the best mode when presenting lists in a tree fashion within an UI
  • POST requests should be used by default for the JavaScript and Java Client since they are more robust.
  • maxDepth should be set to some 'reasonable' default. Not really sure about that because it might break some behaviour, however blind serialization of complex objects the whole way down has often serious side effects because of side effects in get-methods. Any opinion ?

Jolokia bundle generates error when it is stopped in Karaf

Hi,

When we stop the bundle or Apache Karaf server () , the following error is gerenated :

ERROR: Bundle org.jolokia.osgi [124] Error stopping mvn:org.jolokia/jolokia-osgi/1.0.4-SNAPSHOT (org.osgi.framework.BundleException: Activator stop error in bundle org.jolokia.osgi [124].)
java.lang.IllegalArgumentException: Alias [/jolokia] was never registered
at org.ops4j.pax.web.service.internal.HttpServiceStarted.unregister(HttpServiceStarted.java:200)
at org.ops4j.pax.web.service.internal.HttpServiceProxy.unregister(HttpServiceProxy.java:72)
at org.jolokia.osgi.JolokiaActivator$HttpServiceCustomizer.removedService(JolokiaActivator.java:207)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:922)
at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:351)
at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:403)
at org.jolokia.osgi.JolokiaActivator.stop(JolokiaActivator.java:99)
at org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:651)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2236)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1197)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:680)

We should improve the code to use OSGI Http Service to register the servlet. With Apache Karaf, as we use OPS4J Pax WEb, that helps a lot. Maybe we should create a specific bundle for Karaf/ServiceMix deployment

Regards,

Charles

would be nice for the JavaScript client to expose access to the current pending jobs (as a debugging/monitor aid)

even just a counter; but ideally with some information on the details of the jobs. I can imagine it could be quite easy to register a job handle and forget to cancel it down; so being able to dump the pending jobs (if nothing else to check your application is working correctly) would be really handy; to make sure applications are only querying valid requests.

So just some simple jolokia.jobs() function that returns some kind of object / array with some information on the jobs being run would be awesome

Improve Karaf support

While Karaf works perfectly with the current agents (osgi, osgi-bundle, jvm), the support can be improved:

  • Add a Jolokia Karaf feature
  • Add a dedicated Karaf detector

J4pClient does not support server failures

While having a J4pClient which sends periodic requests on a server, I restarted that server.
There was a 404 error, probably caused by a request sent during server restart, but then J4p failed with the message "Invalid use of SingleClientConnManager: connection still allocated.
Make sure to release the connection before allocating another one."

20:27:30.062 [main] ERROR c.b.metrics.harvest.HarvestMetrics - Error - cannot harvest metric
org.jolokia.client.exception.J4pException: 404 Not Found
at org.jolokia.client.J4pClient.extractJsonResponse(J4pClient.java:110) ~[jolokia-client-java-0.80.jar:na]
at org.jolokia.client.J4pClient.execute(J4pClient.java:83) ~[jolokia-client-java-0.80.jar:na]
at org.jolokia.client.J4pClient.execute(J4pClient.java:66) ~[jolokia-client-java-0.80.jar:na]
at com.b.metrics.harvest.HarvestMetrics.execute(HarvestMetrics.java:101) [classes/:na]
at com.b.metrics.harvest.HarvestMetrics.main(HarvestMetrics.java:281) [classes/:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.6.0_22]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) ~[na:1.6.0_22]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) ~[na:1.6.0_22]
at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_22]
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:115) [idea_rt.jar:na]
Harvesting com.b.metrics:type=GroupOfMetrics,name=ApplicationCollector
20:28:30.066 [main] ERROR c.b.metrics.harvest.HarvestMetrics - Error - cannot harvest metric
java.lang.IllegalStateException: Invalid use of SingleClientConnManager: connection still allocated.
Make sure to release the connection before allocating another one.
at org.apache.http.impl.conn.SingleClientConnManager.getConnection(SingleClientConnManager.java:199) ~[httpclient-4.0.1.jar:4.0.1]
at org.apache.http.impl.conn.SingleClientConnManager$1.getConnection(SingleClientConnManager.java:173) ~[httpclient-4.0.1.jar:4.0.1]
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:390) ~[httpclient-4.0.1.jar:4.0.1]
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641) ~[httpclient-4.0.1.jar:4.0.1]
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576) ~[httpclient-4.0.1.jar:4.0.1]
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554) ~[httpclient-4.0.1.jar:4.0.1]
at org.jolokia.client.J4pClient.execute(J4pClient.java:82) ~[jolokia-client-java-0.80.jar:na]
at org.jolokia.client.J4pClient.execute(J4pClient.java:66) ~[jolokia-client-java-0.80.jar:na]
at com.b.metrics.harvest.HarvestMetrics.execute(HarvestMetrics.java:101) [classes/:na]

"Expires:" Header should be set to the request date

Currently we set the expires header to '-1' which, according to RFC 2616 is a possible way to mark content as stale;

HTTP/1.1 clients and caches MUST treat other invalid date formats,
especially including the value "0", as in the past (i.e., "already
expired").

To mark a response as "already expired," an origin server sends an
Expires date that is equal to the Date header value. (See the rules
for expiration calculations in section 13.2.4.)

This works for most clients, however Spring Rest Support seems to have a problem with this. So we should probably switch to the recommendation to set the Expire-Header to the Date of the request (or, if this value is not easily available at the place where the response is generated, at least to "0").

Error on Winstone 0.9.10

[submitted by mail by Andrea Barbieri]

I am using the latest version of JMX4Perl (0.95) and when I host Jolokia in a Winstone Servlet container (0.9.10) I get for every jmx4perl request the following log entry:

[Winstone 2011/08/31 13:27:36] - Called getInputStream after getParameter ... error

I've found this old reference: http://dev.vaadin.com/ticket/543 for an application experiencing the same issues when using Winstone.

ConfigMBean and HistoryMBean Cleanup

In order to avoid clashes with multiple installations of an agent and the configuration/history MBean, these MBean should be updated/looked up all via JMX itself, registering the MBean if not present. This is important for clients using the in-memory HistoryStore, so that historical data is stored only in one place.

Currently, each agent creates an own instances, keeps an object reference for updating the MBean and expose the data via JMX. In case of two agent, two MBeans are registered, one with a (random) qualifier (which is not of much value, because the client needs a fixed name for accesing the history data).

This change implies, that udate methode (i.e. adding to the history store) must be exposed via JMX as well (and hence can potentially be misused).

provide a way to register JSON MBeans for jolokia only which are not visible in jconsole

Its lovely to use JSON for MBeans; nice tree structures can be used without hairy complex JMX specs!

The only downside is JSON MBeans (i.e. beans returning tree based POJO graphs of objects) is that they break when folks try to use them inside jconsole.

So it'd be awesome to be able to have a private "JSON MBeans" MBeanServer that jolokia knows about; so that they all appear in the jolokia connector as expected; but they are hidden from the standard JSR 160 connectors & jconsole etc.

One day we could expose proxies of the JSON MBeans which take Strings and return Strings (formatted as JSON) so they could be used by jconsole? Though need to figure out the mirroring/filtering correctly

An json-simple-1.1.jar BUG:

java.util.Date object in the JSONObject JSONObject.toJSONString () should return the quoted date string description, in fact, less the quotes, so JSON format is the wrong way.
For example:
JSONObject json = new JSONObject();
json.put("age", 18);
json.put("birthday", new java.util.Date());
System.out.println(json.toJSONString());
Output:
{"birthday":Wed Jun 27 14:08:16 GMT+08:00 2012,"age":18}
"birthday" key value less quotes.It should be output: {"birthday": "Wed Jun 27 14:08:16 GMT+08:00 2012","age":18}
The problem lies in: org.json.simple.toJSONString() Method The last line : return value.toString();
Should be changed: return """+escape(value.toString())+""";

one of Support method shouldn't broke all of mbean

Hi all,
I just export BasicSource of dbcp to a mbean with spring. But jolokia shows that there is an unsupportedOperationException - getLoginTimeOut() method. But in jconsole, it will show other attributes normally, the getLoginTimeOut() shows 'unsupported'.
So could jolokia just performs like jconsole, don't let some unsupported operation break the whole mbean. Thank you.

Build Error - java.lang.NoClassDefFoundError: aQute/lib/osgi/Resource

Hi,

The version of the maven-bundle-plugin is not correct and generates the following error :

[WARNING] The POM for org.apache.felix:maven-bundle-plugin:jar:2.3.5 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details
May 6, 2012 12:41:13 PM org.sonatype.guice.bean.reflect.Logs$JULSink warn
WARNING: Error injecting: org.apache.felix.bundleplugin.BundlePlugin
java.lang.NoClassDefFoundError: aQute/lib/osgi/Resource
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)

Version to be used should be 2.3.7 for the following pom files

modified: agent/osgi-bundle/pom.xml

modified: agent/osgi/pom.xml

modified: client/java/pom.xml

modified: it/core/pom.xml

Regards,

Charles

have a JVM jar which includes a little HTTP server by default without requiring the JVM agent stuff

I'd really like to be able to add a single maven dependency to a project to be able to include a nested jolokia agent without tinkering with the main.

e.g. add a single maven dependency to, say, the maven camel plugin; so when folks run...

mvn camel:run

there's and embedded web server included with jolokia inside (maybe with a default maven property used for the port it listens on).

Right now the java agent stuff is cool and minimal dependency; but would be nice to have a simple lightweight http server option.

e.g. maybe netty or jetty or something little?

so if one depended on, say, org.jolokia/jolokia-netty/1.0.6 - then it'd startup a little netty server without need for any java agent stuff?

I guess we'd need some way to startup the agent; just adding a classpath dependency isn't enough though...

InstanceNotFoundException can be avoided in MBeanServerExecutorLocal

We are using latest(1.1.0-SNAPSHOT) code from integration branch for jolokia-osgi module. It works properly but there is one minor issue.

The method "private MBeanServer lookupJolokiaMBeanServer()" uses InstanceNotFoundException thrown by MBeanServer to check if the "jolokia:type=MBeanServer" bean is already registered. Our problem is that we log all exceptions thrown by MBeanServer and the InstanceNotFoundException from lookupJolokiaMBeanServer is logged by our logger. We would like to avoid it.

There is a simple solution for this and insted of relying on InstanceNotFoundException the check in lookupJolokiaMBeanServer() can be performed by utilising MBeanServer.isRegistered(...) method.

The fix would be :

// Check, whether the Jolokia MBean Server is available. If not, register
// at the Platform MBeanServer delegate to get notified when it gets registered
private MBeanServer lookupJolokiaMBeanServer() {
    MBeanServer server = ManagementFactory.getPlatformMBeanServer();
    ObjectName holderMBeanName = null;
    try {
        holderMBeanName = new ObjectName("jolokia:type=MBeanServer");
        if(server.isRegistered(holderMBeanName))
            return (MBeanServer) server.getAttribute(holderMBeanName,"JolokiaMBeanServer");
        else {
            // Not yet available. Register for when it comes been available.
            MBeanServerNotificationFilter filter = new MBeanServerNotificationFilter();
            filter.enableObjectName(holderMBeanName);
            try {
                server.addNotificationListener(getMBeanServerDelegateName(), this, filter, null);
            } catch (InstanceNotFoundException e) {
                // Will not happen, since a delegate is always created during the creation
                // of an MBeanServer
                throw new IllegalStateException("Internal: Cannot lookup " +
                                                getMBeanServerDelegateName() + ": " + e,e);
            } catch (NoSuchFieldError error) {
                // Might happen e.g. on Java 1.5, which doesn't know about MBeanServerDelegate.DELEGATE_NAME ...
            }
            return null;
        }
    } catch (JMException e) {
        throw new IllegalStateException("Internal: Cannot get Jolokia MBeanServer via JMX lookup: " + e,e);
    }
}

Enum upstream serialization improvements

1.1.0 introduces finally Enum support for JSON serializations. Downstream works perfectly (as always), an Enum gets simply serialized to it String value.

For the other direction, Enum serialization works currently only when the Jolokia agent has direct access to the Enum class. I.e. the Enum class must be loadable by the Jolokia agent with one of the available classloaders. This e.g. true for all JDK provided enums (e.g. TimeUnit) or for application based enum, when the Jolokia agent is exposed from within an application.

However, we can do better:

  • For writing rw-attributes, on can read the old value before via JMX's getAttribute(), get access to the value's class classloader and load the Enum from here. I don't know whether this is intended this way (its probably even a security hole), but I tested that it works.
  • For setting inner values Jolokia could use the classloader from the outer object (currently it is always done by a Class.forName() lookup
  • For exec-operation, I unfortunately have no idea, how to get to the proper classloader.

A prototype has been implemented but since 1.1.0 is around the corner this stuff is postponed to the next release.

Jolokia Server does not shutdown properly

The problem is that the threads created by the Jolokia Server themselves as part of the Executor are not tagged as daemon threads. So when the cleanup threads tries to see if it shuts down, the threads that was created in the Executor will stop it from shutting down.

I made a change to use a threadfactory to make them all daemon threads to get around this. You can see it at https://github.com/senthilnest/jolokia. If it makes sense could you pull that?

Serializing exceptions in error responses

Add two new configuration options for tuning the error responses:

  • includeStacktrace = [never, always, runtime] to tune the inclusion of stacktraces in an error response. Currently this is 'always', but would be nice to avoid stacktraces all together or only include stacktraces for RuntimeExceptions
  • serializeException = [true, false] whether to include a JSON serialized version of the exception in the error response. Under the key error_value (similar to 'value' for proper return values ?)

See also the forum for details.

ConcurrentModificationException when reading JMS queue mBean on JBoss

ConcurrentModificationException is thrown for reading JMS queue mBean on JBoss. You can easily reproduce the issue with the following request (mBean should exist on every JBoss installation):

/read/jboss.messaging.destination:name=A,service=Queue

And the stacktrace:

{"error_type":"java.util.ConcurrentModificationException","error":"java.util.ConcurrentModificationException","status":500,"stacktrace":"java.util.ConcurrentModificationException\n\tat java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)\n\tat java.util.HashMap$ValueIterator.next(HashMap.java:822)\n\tat org.jolokia.converter.json.CollectionExtractor.extractObject(CollectionExtractor.java:65)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.callHandler(ObjectToJsonConverter.java:349)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.extractObject(ObjectToJsonConverter.java:181)\n\tat org.jolokia.converter.json.BeanExtractor.extractJsonifiedPropertyValue(BeanExtractor.java:169)\n\tat org.jolokia.converter.json.BeanExtractor.exctractJsonifiedValue(BeanExtractor.java:147)\n\tat org.jolokia.converter.json.BeanExtractor.extractObject(BeanExtractor.java:78)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.callHandler(ObjectToJsonConverter.java:349)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.extractObject(ObjectToJsonConverter.java:181)\n\tat org.jolokia.converter.json.ArrayExtractor.extractObject(ArrayExtractor.java:69)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.extractObject(ObjectToJsonConverter.java:179)\n\tat org.jolokia.converter.json.BeanExtractor.extractJsonifiedPropertyValue(BeanExtractor.java:169)\n\tat org.jolokia.converter.json.BeanExtractor.exctractJsonifiedValue(BeanExtractor.java:147)\n\tat org.jolokia.converter.json.BeanExtractor.extractObject(BeanExtractor.java:78)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.callHandler(ObjectToJsonConverter.java:349)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.extractObject(ObjectToJsonConverter.java:181)\n\tat org.jolokia.converter.json.MapExtractor.extractObject(MapExtractor.java:78)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.callHandler(ObjectToJsonConverter.java:349)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.extractObject(ObjectToJsonConverter.java:181)\n\tat org.jolokia.converter.json.BeanExtractor.extractJsonifiedPropertyValue(BeanExtractor.java:169)\n\tat org.jolokia.converter.json.BeanExtractor.exctractJsonifiedValue(BeanExtractor.java:147)\n\tat org.jolokia.converter.json.BeanExtractor.extractObject(BeanExtractor.java:78)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.callHandler(ObjectToJsonConverter.java:349)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.extractObject(ObjectToJsonConverter.java:181)\n\tat org.jolokia.converter.json.BeanExtractor.extractJsonifiedPropertyValue(BeanExtractor.java:169)\n\tat org.jolokia.converter.json.BeanExtractor.exctractJsonifiedValue(BeanExtractor.java:147)\n\tat org.jolokia.converter.json.BeanExtractor.extractObject(BeanExtractor.java:78)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.callHandler(ObjectToJsonConverter.java:349)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.extractObject(ObjectToJsonConverter.java:181)\n\tat org.jolokia.converter.json.BeanExtractor.extractJsonifiedPropertyValue(BeanExtractor.java:169)\n\tat org.jolokia.converter.json.BeanExtractor.exctractJsonifiedValue(BeanExtractor.java:147)\n\tat org.jolokia.converter.json.BeanExtractor.extractObject(BeanExtractor.java:78)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.callHandler(ObjectToJsonConverter.java:349)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.extractObject(ObjectToJsonConverter.java:181)\n\tat org.jolokia.converter.json.ListExtractor.extractObject(ListExtractor.java:71)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.callHandler(ObjectToJsonConverter.java:349)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.extractObject(ObjectToJsonConverter.java:181)\n\tat org.jolokia.converter.json.BeanExtractor.extractJsonifiedPropertyValue(BeanExtractor.java:169)\n\tat org.jolokia.converter.json.BeanExtractor.exctractJsonifiedValue(BeanExtractor.java:147)\n\tat org.jolokia.converter.json.BeanExtractor.extractObject(BeanExtractor.java:78)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.callHandler(ObjectToJsonConverter.java:349)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.extractObject(ObjectToJsonConverter.java:181)\n\tat org.jolokia.converter.json.BeanExtractor.extractJsonifiedPropertyValue(BeanExtractor.java:169)\n\tat org.jolokia.converter.json.BeanExtractor.exctractJsonifiedValue(BeanExtractor.java:147)\n\tat org.jolokia.converter.json.BeanExtractor.extractObject(BeanExtractor.java:78)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.callHandler(ObjectToJsonConverter.java:349)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.extractObject(ObjectToJsonConverter.java:181)\n\tat org.jolokia.converter.json.BeanExtractor.extractJsonifiedPropertyValue(BeanExtractor.java:169)\n\tat org.jolokia.converter.json.BeanExtractor.exctractJsonifiedValue(BeanExtractor.java:147)\n\tat org.jolokia.converter.json.BeanExtractor.extractObject(BeanExtractor.java:78)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.callHandler(ObjectToJsonConverter.java:349)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.extractObject(ObjectToJsonConverter.java:181)\n\tat org.jolokia.converter.json.MapExtractor.extractObject(MapExtractor.java:78)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.callHandler(ObjectToJsonConverter.java:349)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.extractObject(ObjectToJsonConverter.java:181)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.extractObjectWithContext(ObjectToJsonConverter.java:144)\n\tat org.jolokia.converter.json.ObjectToJsonConverter.convertToJson(ObjectToJsonConverter.java:116)\n\tat org.jolokia.backend.BackendManager.callRequestDispatcher(BackendManager.java:206)\n\tat org.jolokia.backend.BackendManager.handleRequest(BackendManager.java:175)\n\tat org.jolokia.http.HttpRequestHandler.executeRequest(HttpRequestHandler.java:148)\n\tat org.jolokia.http.HttpRequestHandler.handleGetRequest(HttpRequestHandler.java:78)\n\tat org.jolokia.http.AgentServlet$3.handleRequest(AgentServlet.java:269)\n\tat org.jolokia.http.AgentServlet.handle(AgentServlet.java:213)\n\tat org.jolokia.http.AgentServlet.doGet(AgentServlet.java:195)\n\tat javax.servlet.http.HttpServlet.service(HttpServlet.java:617)\n\tat javax.servlet.http.HttpServlet.service(HttpServlet.java:717)\n\tat

Thanks,
Marcin

Add support for custom MBean "ifModified" handling

Since the list operation on Jolokia is quite expensive (or can be quite expensive), adding a new query parameter ifModified (or so) should be added. This parameter has a handle which was returned from a previous list call (still to think how to integrate it into the handle into the response, probably an extra field 'handle' in the response itself). The Jolokia agent (or more specific, the ListHandler) listens for notifications about MBeans added or removed and increases the handle/counter internally.

For a request with ifModified parameter it

  • returns the requested list if the provided handle differs from the internal handle
  • returns an empty value with status code "304 Not Modified" if the list hasn't changed.

The same could be implemented for search, too, however this request shouldn't as expensive as list so it is probably not needed here.

Drop Java 1.5 support for Jolokia 2.x

In order to keeps things as simple as possible (and because of the fact of limited resources), Java 1.5 support will be dropped for Jolokia 2.x.

Java 1.5 users can still use the Jolokia 1.x series with the current feature set.

org.jolokia.detectorOptions ignored when using jolokia-osgi.jar on glassfish

I've installed jolokia-osgi-1.0.5.jar on my glassfish 3.1.2.2 server and was able to access /osgi/jolokia url. But requests to any amx:pp= like beans are not working because amx bean not loaded by default (and I didn't find any way to configure glassfish to load it on startup). I've found this option org.jolokia.detectorOptions for configuring jlokia in the documentation and set it's like this in osgi.properties file:
org.jolokia.detectorOptions={ "glassfish" : { "bootAmx": true }}

But amx bean not started even after this. I did som investigation on issue. It figured out that this happens because lookupDetectors method of MBeanServerHandle class do not return GlassfishDetector, which in turn happens because META-INF/detectors-default file in jolokia-osgi-1.0.5.jar do not mention this detector. Is it a bug? If no, then how I can force amx bean to start by default?

IllegalStateException when requesting tomcat thread counts

I'm using the nodejs implementation jolokia-client found at https://github.com/jolira/jolokia-client.

Trying to get the Thread count from a Tomcat 7.0.14 I try to get the data from mBean
Catalina:name="http-apr-8080",type=ThreadPool

with properties
currentThreadsBusy and currentThreadCount

This leads to the following exception:

java.lang.IllegalStateException: Error while extracting ooBInline from org.apache.tomcat.util.net.SocketProperties@1e3556a
at org.jolokia.converter.json.BeanExtractor.extractBeanPropertyValue(BeanExtractor.java:242)
at org.jolokia.converter.json.BeanExtractor.extractJsonifiedPropertyValue(BeanExtractor.java:161)
at org.jolokia.converter.json.BeanExtractor.exctractJsonifiedValue(BeanExtractor.java:147)
at org.jolokia.converter.json.BeanExtractor.extractObject(BeanExtractor.java:78)
at org.jolokia.converter.json.ObjectToJsonConverter.callHandler(ObjectToJsonConverter.java:349)
at org.jolokia.converter.json.ObjectToJsonConverter.extractObject(ObjectToJsonConverter.java:181)
at org.jolokia.converter.json.MapExtractor.extractObject(MapExtractor.java:78)
at org.jolokia.converter.json.ObjectToJsonConverter.callHandler(ObjectToJsonConverter.java:349)
at org.jolokia.converter.json.ObjectToJsonConverter.extractObject(ObjectToJsonConverter.java:181)
at org.jolokia.converter.json.ObjectToJsonConverter.extractObjectWithContext(ObjectToJsonConverter.java:144)
at org.jolokia.converter.json.ObjectToJsonConverter.convertToJson(ObjectToJsonConverter.java:116)
at org.jolokia.backend.BackendManager.callRequestDispatcher(BackendManager.java:206)
at org.jolokia.backend.BackendManager.handleRequest(BackendManager.java:175)
at org.jolokia.http.HttpRequestHandler.executeRequest(HttpRequestHandler.java:148)
at org.jolokia.http.HttpRequestHandler.handlePostRequest(HttpRequestHandler.java:110)
at org.jolokia.http.AgentServlet$2.handleRequest(AgentServlet.java:259)
at org.jolokia.http.AgentServlet.handle(AgentServlet.java:213)a
at org.jolokia.http.AgentServlet.doPost(AgentServlet.java:202)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
at org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValve.java:210)
at org.apache.catalina.valves.RemoteAddrValve.invoke(RemoteAddrValve.java:85)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399)
at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:306)
at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:322)
at org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:1688)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)\nCaused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.jolokia.converter.json.BeanExtractor.extractBeanPropertyValue(BeanExtractor.java:237)
... 37 more
Caused by: java.lang.NullPointerException
at org.apache.tomcat.util.net.SocketProperties.getOoBInline(SocketProperties.java:235)
... 42 more

verifying via jconsole that the values are there and readable with this mBean name has left me in a dead end.

I'm not sure if the problem lies with jolokia, but I'm guessing that the nodejs client is not doing much other than a json request and printing the jolokia response, and the tomcat can expose it's data via jmx without problems.

JS: Allow the possibility for providing query options when using jolokia.register()

Currently it is not possible to provide processing options (transported via query options) when using j4p.register(...) in the JavaScript client. In this case, processing options can only be given to constructor of the Jolokia client. One could use individual client objects with different processing options, but this is an overhead which can be avoided when allowing processing options directly when registering jobs.

See also #61 for a former discussion with the same issue.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.