2013/7/30 Bertrand Delacretaz <[email protected]> > 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 > > I think there isn't necessarily a 1:1 mapping between a check and an expression, e.g. if you have a check for "are all bundles active" this is very hard to express as an expression. And for a consumer / invoker of this check, this is irrelevant whether the check is done through an expression or java code or what ever it is.
I also would avoid the name "rule" for this - it's a check :) I agree that name and description can be added as service properties to the registration of that check service. We need some result, I'm not sure whether restricting this to a boolean is flexible enough. For example if you have a check for available free memory, just returning a boolean might not be enough. Maybe we also want to support additional information like "this looks wrong ,please check here and there" 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. > > I don't think we can restrict the input to JMX information - and I also would try to separate the concerns and delegating registration of a check as an MBean to someone else. Please note, I'm not talking about how to implement a check - this can be done through the scripts you already have - right now I'm just talking about the consumer API of such a check. Regards Carsten > 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 > -- Carsten Ziegeler [email protected]
