Add Microprofile Health

[Thihup]

This change supports the deployment of MicroProfile Health 4.0 compatible applications, and modifies GF full profile to pass the MP Health 4.0.1 TCK by implementing the specification from scratch.

The MicroProfile Health uses the MicroProfile Config to check for two properties, so instead of requiring an explicit dependency,it handles the absence of the MP Config by returning a default value.

Currently this implementation does not add any default procedure.
Each application now contains four new endpoints: /health, /health/live, /health/ready and /health/started.

The TCK requires a single property (mp.health.disable-default-procedures) to be set (although currently unused by the implementation)

[arjantijms]

Wow, super cool! Just curious, how many of the TCK tests are passing at the moment?

Maybe the manifest.mf file can be generated? It usually is, but I didn't check yet if you're doing anything special. Just a quick glance.

[Thihup]

Tests passed/Failed/Skipped: | 27/1/0
The only test failing is the testEmptyReadinessWithConfig.

The main issue related to this failure is use of the Microprofile Config. As I'm creating a new MpConfigProviderResolver, it is not reading the microprofile-config.properties.

As I understand, the correct use should be ConfigProvider.getConfig(), but using it fails with No ConfigProviderResolver implementation found!. I couldn't understand why it was happening as I required the implementation (Import-Package: io.helidon.config.mp;).

Related to the manifest, I had to change it to allow the use of a higher CDI version. I followed the pattern of the microprofile-jwt-auth-api.

[Thihup]

Another issue: right now I'm registering the Servlet as the following http://localhost:8080/my-app/health, but the spec requires it to be http://localhost:8080/my-app/health.

[OndroMih]

@Thihup, regarding "As I understand, the correct use should be ConfigProvider.getConfig(), but using it fails with No ConfigProviderResolver implementation found!", this is probably related to classloading or the order in which MP Health and Config are initialized. Config in GF is initialized in https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/microprofile/config/src/main/java/org/glassfish/microprofile/config/ConfigDeployer.java. Maybe it happens after MP Health is initialized and thus Config is not yet available. If it's the case, we need to ensure that Health initializes after Config.

Alternatively, refactor ConfigDeployer.java to extract the initialization into a separate method that initializes MP Config if it's not initialized, and call the method directly from the MP Health initializer or via a CDI event triggered from the Health initializer. I prepared something like that in my local branch with experiments related to MP Config, which I only have locally and haven't prepared as a PR yet:

@Override
    public ApplicationContainer load(Container container, DeploymentContext deploymentContext) {
        initializeConfigProviders();
        return new ConfigApplicationContainer(deploymentContext);
    }

    /**
     * Initialise Config providers if they haven't been initialized
     */
    public void initializeConfigProviders() {
        if (!configProvidersInitialized) {
            final var resolver = new MpConfigProviderResolver();
            ConfigProviderResolver.setInstance(resolver);
            configProvidersInitialized = true;
        }
    }

And then ConfigDeployer could be injected into the Health initializer and call the initializeConfigProviders() method from there to ensure Config is initialized. Or, even better, fire an HK2 event from Health initializer and handle the event by calling the method.

[arjantijms]

Related to the manifest, I had to change it to allow the use of a higher CDI version. I followed the pattern of the microprofile-jwt-auth-api.

You are absolutely right. I missed it being in a patches folder.

(maybe for the future we can add some extension somewhere in OSGi so that we can more directly specify we allow higher versions, without patching the entire manifest)

[OndroMih]

Shouldn't this condition rather be reverted? We want /health servlet on the root context, not on application contexts.

[OndroMih]

I see there are now 2 issues with this:

1. a global /health servlet doesn't know about health checks in applications, it needs to use GlassFish-specific code to retrieve them
2. MP TCK uses URL injected by Arquillian to access the /health endpoint, and this URL is not root URL, it contains application context root

The point number 2 can be addressed via Arquillian extension, similar to the one that Payara uses in their MP TCK runner.

To address point number 1, I suggest the following:

1. Abstract the code in HealthServlet into a new class, e.g. HealthReporter. This class
   • would not depend on Servlet API
   • would search for HealthCheck CDI beans as now (in GlassFish, it would find global health checks defined in GlassFish if we define any global checks later)
   • would allow adding and removing HealthCheck beans also programmatically, via a method, e.g. addHealthCheck and removeHealthCheck
   • would have a method to produce a report that could be then used in a servlet, e.g. a method getHealth(). This method can return an instance of Output record, I would just rename Output to something like HealthOutput or HealthReport
2. Create a new maven module with GlassFish-specific functionality. This module would mainly do the following
   • register a servlet on the root /health URL - the HealthServlet and healthServletInitializer classes would be moved here
   • would create a instance of HealthReporter from step 1 and register it globally, e.g. in an HK2 singleton service
   • on application deployment, would register all healthchecks in the application with the HealthReporter instance, e.g. via CDI extension like https://github.com/payara/Payara/blob/bd99ec60a2827ebef982b38ae8edfaf94e7363de/appserver/payara-appserver-modules/microprofile/healthcheck/src/main/java/fish/payara/microprofile/healthcheck/cdi/extension/HealthCDIExtension.java
   • on application undeployment, for example listening on Deployment.APPLICATION_UNLOADED like here, would unregister all healthchecks previously registered by that application