[
https://issues.apache.org/jira/browse/SLING-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13872086#comment-13872086
]
Bertrand Delacretaz commented on SLING-3302:
--------------------------------------------
Ok, I would agree with a utility class that collects a result's messages and
selects all the ones with the highest level, a ResultSummarizer maybe. But if
there are several CRITICAL messages for example you need to keep all of them,
there's no way to tell which one is more relevant.
This is a presentation concern, I don't think it belongs in the API.
> Improve Health Check Result to provide simple message and exception if
> applicable
> ---------------------------------------------------------------------------------
>
> Key: SLING-3302
> URL: https://issues.apache.org/jira/browse/SLING-3302
> Project: Sling
> Issue Type: Improvement
> Components: Health Check
> Reporter: Georg Henzler
> Attachments:
> SLING-3302-health-check-result-with-message-and-exception.patch
>
>
> For use case B) and C) as listed in
> https://cwiki.apache.org/confluence/display/SLING/Health+Checks+Executor+Design
> it would be nice to be able to provide a tabular result listing with the
> following columns :
> | Name | Tags | Status | Message | Exception | Execution Time |
> I would propose to add the following methods to the
> org.apache.sling.hc.api.Result:
> String getMessage(); // see 1)
> Exception getException(): // see 2)
> 1) Obviously we have the result log for more detailed information (and it
> should be possible to show it in the web console if a tick box is set), but
> it would be nice to have a simple message (this is in line with constructor
> Result(final Status s, final String explanation)). The method could be easily
> implemented by either
> - taking the one log message that is there (for the case the above
> constructor was used)
> - taking the last log message with the worst status (e.g. CRITICAL).
> 2) This would mean adding a property exception and adding two constructor
> variants (having 4 constructors in total). The benefit should be obvious: If
> things go wrong in a HC a simple message plus the exception that was returned
> by some underlying framework stack (could be SOAP for instance) is very
> valuable to the technical observer.
> NOTES:
> * This change would not cause existing code to break as it only adds
> constructors/methods.
> * This improvement is orthogonal/independent from the HC executor
> (SLING-3278)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
