Health API, JAX-RS and CDI bindings

[Heiko Braun]

I did a review of the health API that we (mostly) carried over from Wildfly Swarm. It has to main application level bindings, one using JAX-RS:

@GET
@Health
@Path("/myHealthCheck")
public HealthStatus checkHealth() {
   return HealthStatus.named("myCheck").up();
}

the other one using CDI:

public class MyHealthCheck implements HealthCheckProcedure {
    @Override
    public HealthStatus execute() {
        return HealthStatus.named("mCheck").up();
    }
}

The initial idea was to keep both option for implementing health check procedures, but I am tempted to drop the JAX-RS approach. The Microprofile 1.0, which I assume to be the baseline dependency set, supports CDI out-of-the-box and thus I don't see a reason to carry on with two approaches. 

Thoughts?

[Ken Finnigan]

There may be benefits to supporting both approaches, as different implementations of the spec may choose one or the other, or even both.

Ken

[Emily Jiang]

Heiko,

Can you list the use cases for JAX-RS and CDI? How do they work? In this way, if CDI approach can achieve all JAX-RS can get, it is fine to focus CDI part. I am guess the key is to return a HealthStatus object.

Emily

[Emily Jiang]

The issue mentioned in this thread needs to be sorted asap, as we would like to try out this spec. I have also some queries on this spec. Please can we have a hangout to discuss this? Heiko, Here is the doodle page to collect your availability. Heiko, please attend the meeting.

Thanks
Emily

[Werner Keil]

I also see benefit in both.

Based on https://github.com/eclipse/microprofile-samples which I just upgraded to use the 1.0.0 BOM I will show a quick demo tomorrow at DWX with Ivar on how to add a

@Path("/health")
to the JAX-RS example Antonio started. It probably makes even more sense for the Conference example, but that was a bit too complex and cumbersome to set up for DWX, so I'll leave that for later, but in a distribute scenario one could pretty well imagine the status of "speakers" or other services made available that way.

If it is not too early on a week day I'd be happy to join a hangout, as well.

Werner

[Emily Jiang]

Thank you for your input, Werner! The hang out will be on Tuesday 2-3pm GMT time. The Microprofile calendar has the details. Heiko and I will be there. Hope you can make it! 

Emily

[Heiko Braun]

I'd say keep it simple and drop JAX-RS for now: https://github.com/eclipse/microprofile-health/issues/13

If we find good arguments for introducing a second programming model besides (or excluding) CDI then we can still revisit it.

[Emily Jiang]

Further to the previous efficient hangout, all attendees agreed to get together more frequently, bi-weekly. The frequent Health check hangout will be on the same time next week and then occurs bi-weekly. The MicroProfile calendar has the details. 

I also created a health wiki page to hold all the info.

Emily

[Werner Keil]

It's a little early I'm afraid. Even though it's UK time and it's about an hour later in Germany.

Keeping JAX-RS out of the API despite it being a core dependency of MicroProfile seems OK. Those actuator endpoints for Spring Boot https://github.com/spring-projects/spring-boot/tree/master/spring-boot-actuator are also rather implementation specific and come as extension to the Spring Boot core (there is not such a strong separation of concerns there as in what is the API and what is implementation ;-)

Werner