[
https://issues.apache.org/jira/browse/SLING-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13872100#comment-13872100
]
Bertrand Delacretaz commented on SLING-3302:
--------------------------------------------
bq. what about hiding the preceding messages and allowing to view all by
clicking on an entry?
The webconsole pretty much does this be hiding DEBUG messages by default. You
could hide DEBUG and INFO by default maybe, and get a pretty good summary which
doesn't risk losing anything with arbitrary selections.
> 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)
