Ok, agreed :) Sounds like a good compromise - however :) I think we should make Result a class with getter and setter methods; this allows for better extensibility (we don't need to change any implementation if we add new methods/features) and also makes the healt check service implementation easier.
Carsten 2013/8/12 Bertrand Delacretaz <[email protected]> > 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 > -- Carsten Ziegeler [email protected]
