[
https://issues.apache.org/jira/browse/SLING-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13872078#comment-13872078
]
Georg Henzler commented on SLING-3302:
--------------------------------------
If I have a CRITICAL message, I don't think the INFO messages that precede the
CRITICAL event provide any additional value. In most cases those INFO messages
will always be the same, no matter if the check fails or not. (thus showing
those messages ist just cluttering the UI). Obviously the proposed logic in
getMessage() can always be placed somewhere outside (e.g. in the webconsole) to
achieve the same result, but I just think it would be neat to have it as
shortcut in the API itself.
> 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)
