Computed indicators must be rendered to the application administrator. jMonit uses the Visitor pattern to expose the monitor (and its aggregators) datas.

An Aggregator MAY implement the org.jmonit.reporting.Visitable interface. In such case, it is reponsible to compute a Map representation of its state and pass it to the visitor. Some aggregators may not be visitable, and in such case are ignored. This can be used for example to create an aggregator that stores application state on shutdown, but has no data to report.

The Visitor pattern can be used by custom application code to build a report on the monitoring state, by simply binding a org.jmonit.reporting.Visitor implementation to the adequate formatting methods. jMonit uses a second level of abstraction via the Renderer interface. This one is used by the RestServlet to provide web-oriented rendering.

The RestServlet accepts REST style URIs. The request path is composed as :

Here are some examples :
  1. /monitors : all monitors, but only name and tags are returned
  2. /monitors/tag/web : all monitors tagged as "web"
  3. /monitors/tag/web/Statistics : all monitors tagged as "web" AND supporting the "Statistics" feature. The feature datas are also returned
  4. /monitors/tag/web/Statistics+Concurrency : all monitors tagged as "web" AND supporting both the "Statistics" and "Concurrency" features.

The data formatting depends on the request "accept" header. It also considers the request path extension. Based on this, a renderer instance is used. For example, request to /monitors/Statistics with accept header set to "application/json" will use the JsonRenderer. Based on this, we can render the monitored datas in many formats, like XML, CSV, PDF...

jMonit provides a web UI built over the REST+json facility. It uses the prototype js library to parse the JSON result and render datas in a grid. Point your browser to http://myserver/myapp/jMonit/performances.html to see it in action.