Hi Carsten,
On Tue, Jul 30, 2013 at 9:18 AM, Carsten Ziegeler <[email protected]> wrote:
> ...after looking into the current HC API I'm wondering if we shouldn't the API
> differently: what we need is the ability to execute checks, get a result
> and it would be nice to have the result available via JMX....
Yes - the current prototype has mostly been improvised as the ideas
came up, and since adding scripted rules yesterday (see [1] for an
example) I think we could reduce the whole thing to something like:
A Rule has a name, description, an expression and a verify() method
that returns true or false.
The expression is a snippet of ecmascript code, for example
jmx.attribute("java.lang:type=ClassLoading", "LoadedClassCount") > 100
&& hc.osgi.frameworkStartLevel > 1
Where jmx is an ecmascript context object that provides access to any
JMX attribute, and hc is another context object that provides
simplified names for common JMX MBeans. In this example
hc.osgi.frameworkStartLevel maps to JMX ObjectName =
"osgi.core:type=framework,version=1.5" attributeName
="FrameworkStartLevel". This mapping is defined in an OSGi
configuration of the hc context object.
Rules can be executed via JMX as in the current prototype, with one
MBean per rule, see "JMX access to Health Check Rules results" at
http://sling.apache.org/documentation/bundles/sling-health-check-tool.html
I think we can restrict the whole thing to using JMX MBeans as input,
which promotes creating more MBeans instead of inventing our own
management objects. If needed we can easily provide extension points
to add more ecmascript context objects besides jmx and hc, but I'd
start with just those to try and keep things simple.
WDYT?
-Bertrand
[1]
https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/healthcheck/sling-demo/src/main/resources/SLING-CONTENT/apps/hc/demo/ecma-jmx-and.json
