Hi Carsten and Georg, I was going to say that I still disagree, but being outnumbered I'd let it go if it's just about a single method that I don't like...and then I reviewed the org.apache.sling.hc.api package once again and it's worse than I thought.
You guys both say you don't want metadata in APIs...and the HealthCheckResult interface that you added has these two methods (which make sense BTW): String getHealthCheckName(); List<String> getHealthCheckTags(); So a HC is not brave enough to have this in its API, but a Result needs them? This clearly demonstrates that we need a HealthCheckMetadata interface that provides those values. On top of that, the Result throws UnsupportedException on these methods...how ugly is that, why can't it provide these values from the HealthCheck that was used to create it? To me this smells of implementation-driven APIs, we are used to better design in Sling. What do others think? -Bertrand [1] https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/healthcheck/core/src/main/java/org/apache/sling/hc/api
