If I look at the use cases, we have either executing HCs based on tags or the JMX support which executes single HCs. For the jmx stuff we need to pass the service reference into the executor - for all other use cases, just providing the tags is sufficient.
So basically we have two options: a) keep the service reference in the signature of the HC b) merge the jmx implementation into the core While I like to keep things separate, I think it makes sense to move the jmx stuff into the core, this keeps the executor service interface cleaner. And the jmx name constant to register a HC as a JMX bean is defined in the core anyways. WDYT? Regards Carsten 2014/1/1 Georg Henzler <sl...@cq-eclipse-plugin.net> > > I updated the wiki page at https://cwiki.apache.org/ > confluence/display/SLING/Health+Checks+Executor+Design with API Variant > B: It is mostly in line with the current version in SVN with the two > changes I already suggested. Carsten, WDYT? > > > >> That might work...OTOH I want to have the execution timeout specified >> in the execute call, as being able to change it is very useful when >> troubleshooting things from the webconsole. >> > > I don't think it is that useful to be able to specify a timeout in the web > console HC plugin for the following reasons: > * Health check futures are never canceled, they always keep running until > they are finished even if the executor returns a timeout => it is possible > to set the log level of the HC to debug and check the log file even after > the web console returned a timeout > * If there is trouble, it is usually necessary to have a look at the > proper log files anyway (for instance, a HC result is currently not capable > of carrying an exception) > * If really a longer timeout is needed, it is always possible to configure > a higher timeout in the OSGi config of the HealthCheckExecutor (this is > always possible in DEV/TEST envs) > > -Georg > > -- Carsten Ziegeler cziege...@apache.org
