Hi Carsten,
On Fri, Aug 9, 2013 at 5:00 PM, Carsten Ziegeler <[email protected]> wrote:
> I've added some comments to the issue about the current api :) I think we
> should not relying on log messages as the communication between a HC and
> the result. The HC should create a proper result object, and the status
> should be a field in that object...
Ok - I agree that decoupling the results from the logging model gives
more flexibility and reduces the API's footprint.
However, having a mini-log as part of the result is very useful, and
being able to have several types of log messages helps make health
check results self-explaining.
So how about:
a) In the HealthCheck interface, change to "Result execute()", i.e.
drop the ResultLog.
b) change Result into an interface:
public interface Result {
Iterator<ResultLog> getResultLog();
Status getStatus();
}
Where Status is an enum (OK, WARN, CRITICAL, ERROR) and ResultLog is
public class ResultLog {
...
String getType();
String getMessage();
}
Using Strings for the log types (not "levels" as there's no notion of
higher/lower levels) to allow HealthChecks to invent their own types
if needed. Things like "HOWTOFIX", "PERFORMANCE" etc.
I think this provides a nice balance between rich logs and extensibility, WDYT?
-Bertrand
