[
https://issues.apache.org/jira/browse/SLING-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756083#comment-13756083
]
Carsten Ziegeler commented on SLING-3034:
-----------------------------------------
I really would like to separate support for writing/creating health checks from
concrete checks and keep them in separate bundles
Now, I think we can argue a lot about the DefaultLoginsHealthCheck - as this is
configurable, an open system might be reconfigured and in this case this check
might be changed to check something different. And you don't notice this. The
same for the SlingRequestStatusHealthCheck - it's a long chain from the browser
until the request arives at Sling. While this check is a good first step, it
still gives you no guarantee what arives at the user, especially as it's not
using a real user.
Don't get me wrong, these checks have a value and serve a purpose - however,
just relying on them is simply not enough.
Maybe we should simply move CompositeHealthCheck, ScriptableHealthCheck and
JmxAttributeHealthCheck to the api bundle - as this is kind of an api
> Check contents of healtchecks bundle
> ------------------------------------
>
> Key: SLING-3034
> URL: https://issues.apache.org/jira/browse/SLING-3034
> Project: Sling
> Issue Type: Task
> Components: Health Check
> Reporter: Carsten Ziegeler
> Fix For: healthcheck-api 1.0.0
>
>
> The current healtchecks bundle seems to be a collection of completely
> different things. I think we should reduce this to the bare minimum as these
> services are API.
> I think the CompositeHealthCheck is fine, as well as the
> ScriptableHealthCheck and the JmxAttributeHealthCheck.
> But I think the DefaultLoginsHealthCheck and the
> SlingRequestStatusHealthCheck should rather be moved out. Checking this stuff
> might look nice, but it imho it doesn't really provide a huge value. If you
> want to check the status of a request than you have to go all the way, the
> client browser would go. Otherwise your server looks fine but still a user
> does not get anything.
> The OsgiScriptBinding looks like a sample to me, we should rather remove this
> for now. Bundle information should be availabel as jmx info anyway.
> All services are configuration factories (which is good) but set the name to
> "org.apache.sling.hc.{classname}". I think we should use the real package
> name here, I see no good reason to use some fake package name
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
