[
https://issues.apache.org/jira/browse/SLING-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13872120#comment-13872120
]
Georg Henzler commented on SLING-3302:
--------------------------------------
getMessage() was just a suggestion, if you both prefer to handle the concern in
the web console, I'm fine with it.
Regarding getException(): Do you agree that it would provide value? If yes, the
question would be if each ResultLog.Entry should have an exception attached or
just the Result itself (my patch uses the latter). If you think several
CRITICAL entries can happen regularly, it's probably cleaner to allow one
(optional) exception per ResultLog.Entry.
> 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)
