microprofile-health-35 Provide different types of health check

[antoinesd]

First version of the pull request for #35.
HealthCheckResponse description will probably need to be change to take Readiness into account.

[derekm]

Existing @Health checks cannot be assumed to be valid @Liveness checks.

[rdebusscher]

Mention within spec this phrase (from initial request)

The readiness probe will return FAIL when the application is initializing itself.

This is important when

• The developer didn't define any readiness check himself and just want the service to be identified as ready as soon it is fully deployed
• In case the startup is in 2 phases, startup server and then deployment of the app) the readiness endpoint doesn't signal UP in the brief moment between server is started and before the app is deployed and readiness checks are picked up.

[mkouba]

Well, I still find the @Health qualifier useless. I think that for /health endpoint all the health check producedures should be invoked, i.e. the impl should use @Inject @Any Instance<HealthCheck> to obtain all procedures. For /health/live the impl should use @Inject @Liveness Instance<HealthCheck> and for /health/ready the impl should use @Inject @Readyness Instance<HealthCheck>.

I would also recommend to add a new annotation to specify custom health checks groups, something like @HealthCheckGroup("checksA") (but find a better name ;-). @Named is probably not appropriate as it has side effects (named beans are accessible in EL etc.). This way it would be possible to select only specific checks for /health/{groupName} endpoints, using @Inject @Any Instance<HealthCheck> and instance.select(HealthCheckGroup.Literal.of("checksA")).

[xstefank]

@mkouba I really like your idea in the second paragraph but this PR probably isn't the right place to track it. Can you create an issue for it please?

[mkouba]

@xstefank I've added a comment to #81...

[Ladicek]

I'd avoid using terms like "MP-HC". This is AsciiDoc -- if "MicroProfile Health Check" is too long to write all the time, use a variable :-)

[antoinesd]

I agree @Ladicek. But for clarity I suggest that we manage that in another ticket / PR

[xstefank]

one small mistake, can be fixed in another PR. Thanks!

[Emily-Jiang]

One more comment: please increase the package-info version from 1.0 to 1.1 since new APIs were added.

[Emily-Jiang]

Please update package-info.java. Sorry, I missed this in my last review.

[antoinesd]

@Emily-Jiang are you sure it should be 1.1 and not 2.0 to follow spec version?

[antoinesd]

I merge with required version modification.