[RT] Fluent API for HealthCheckExecutor

2013-12-19 Thread Bertrand Delacretaz 
Hi,

I thought a bit more about the SLING-3278 HealthCheckExecutor service,
and a fluent interface might be useful:

interface HealthCheckExecutor {
 /** Select all HealthChecks for execution */
 HealthCheckContext all();

 /** Select a single HealthCheck for execution */
 HealthCheckContext for(HealthCheck hc);

 /** Select HealthChecks by tag for execution */
HealthCheckContext forTags(String ...tags);
}

/** Context holds execution options and triggers the actual execution */
interface HealthCheckContext {
  void withTimeout(int timeout, TimeUnits units);
  void clearCache();
  AggregatedResult getResult();
  ListResult getAllResults();
}

Which allows for writing things like

  executor.all().getAllResults();
  executor.for(hc).getResult();

  executor
.forTags(foo, -bar)
.withTimeout(5, TimeUnit.SECONDS)
.getResult();

  // Clear cache before execution
  executor.forTags(security).clearCache().getAllResults();

  // Clear all cached Results
  executor.all().clearCache();

AggregatedResult extends Result with a ListResult getResults()
method. Its status is the highest of the aggregated statuses, and its
log is the concatenation of all individual logs.

WDYT?
-Bertrand

Re: [RT] Fluent API for HealthCheckExecutor

2013-12-19 Thread Georg Henzler 


Hi,

although in general I like fluent APIs, in this case IMHO there is not 
really a point in creating one. The HealthCheckExecutor is only to be 
used by JMX and the web console (and maybe at some point by some 
servlet), but not as part of a normal implementation project. However, I 
think projects will implement their own health checks, but rarely have 
the need to execute them in a custom fashion if JMX and the web console 
are configurable in a flexible way. It is really like Servlets: You 
implement the interface and make them known to the container, but you 
don't ever run them yourself from java (as the container does this for 
you).


-Georg

Am 19.12.2013 11:21, schrieb Bertrand Delacretaz:

Hi,

I thought a bit more about the SLING-3278 HealthCheckExecutor 
service,

and a fluent interface might be useful:

interface HealthCheckExecutor {
 /** Select all HealthChecks for execution */
 HealthCheckContext all();

 /** Select a single HealthCheck for execution */
 HealthCheckContext for(HealthCheck hc);

 /** Select HealthChecks by tag for execution */
HealthCheckContext forTags(String ...tags);
}

/** Context holds execution options and triggers the actual execution 
*/

interface HealthCheckContext {
  void withTimeout(int timeout, TimeUnits units);
  void clearCache();
  AggregatedResult getResult();
  ListResult getAllResults();
}

Which allows for writing things like

  executor.all().getAllResults();
  executor.for(hc).getResult();

  executor
.forTags(foo, -bar)
.withTimeout(5, TimeUnit.SECONDS)
.getResult();

  // Clear cache before execution
  executor.forTags(security).clearCache().getAllResults();

  // Clear all cached Results
  executor.all().clearCache();

AggregatedResult extends Result with a ListResult getResults()
method. Its status is the highest of the aggregated statuses, and its
log is the concatenation of all individual logs.

WDYT?
-Bertrand

Re: [RT] Fluent API for HealthCheckExecutor

2013-12-19 Thread Bertrand Delacretaz 
On Thursday, December 19, 2013, Georg Henzler wrote:

 ...The HealthCheckExecutor is only to be used by JMX and the
 web console (and maybe at some point by some servlet), but not as part of
a
 normal implementation project...

That's a very limiting view.

If you have spellchecking services for example, it might be a good idea to
expose their status to your content authors...something like
executor.forTags(spellchecker).getResult()

-Bertrand

Re: [RT] Fluent API for HealthCheckExecutor

2013-12-19 Thread Georg Henzler 


You have a good example here - I'm not sure though if you would really 
call the health check before a spell check or if it is not better to 
have good exception handling for the actual call of the spell checker if 
things go wrong. What if the health check returns green and 20ms later 
the service is away... the exception handling for the actual call of the 
the spell check still has to be in place for this case! (making the call 
to the health check beforehand really obsolete)


But let's say we want to use a health check to show a result for a tag 
to the author: You still can do so with the API of the current patch of 
SLING-3278:

Result result = executor.runForTags(spellchecker);

The fluent API would allow to specify timeouts or clearing the cache 
per execution. I think it's better to configure TTLs and HC timeouts 
once (either per check or a default globally). For instance, if you have 
the spellcheck service health check: Does it really make sense to use a 
different timeout for a message to the author than for the web console 
used by a admin guy? The timeout is mainly influenced by typical 
response times of the service, not by whom is looking at the result.


-Georg

Am 19.12.2013 19:24, schrieb Bertrand Delacretaz:

On Thursday, December 19, 2013, Georg Henzler wrote:


...The HealthCheckExecutor is only to be used by JMX and the
web console (and maybe at some point by some servlet), but not as 
part of

a

normal implementation project...


That's a very limiting view.

If you have spellchecking services for example, it might be a good 
idea to

expose their status to your content authors...something like
executor.forTags(spellchecker).getResult()

-Bertrand