This is a follow up after investigating a user's feedback via an issue logged to the EAP MicroProfile TS project

The MicroProfile Health specs state the following:

To disable all default vendor procedures users can specify a MicroProfile Config configuration property mp.health.disable-default-procedures to true

meaning that any way to provide such property is valid, and this includes the usage of a microprofile-config.properties resource in the application classpath.

BTW WildFly MicroProfile Health documentation describes the above use case, as well:

The MicroProfile Config property mp.health.disable-default-procedures is read at 2 different times:

...
2. When an application is deployed, to determine if WildFly should add a readiness check if the deployment does not provide any. At that time, setting this property in a microprofile-config.properties file in the deployment would be taken into account. (with the usual priority rules for MicroProfile Config properties).

It seems this behavior was changed by https://issues.redhat.com/browse/EAP7-1322 and given what above, this looks like a regression with respect to compliance with MicroProfile Health specs.

I've been looking for an explanation, and the closest information I've found is in WFWIP-352 but actually nothing that could resolve the fact that the current implementation doesn't allow for the use cases that the specs dictate.

BTW - the current settings in https://github.com/wildfly/wildfly/blob/main/testsuite/integration/microprofile-tck/health/src/test/resources/arquillian.xml#L13 is overriding the behavior of the Maven surefire plugin configuration, see https://github.com/wildfly/wildfly/blob/main/testsuite/integration/microprofile-tck/health/pom.xml#L95
That being said I am logging this as Critical because a workaround exist, but feel free to let me know if I am missing anything.

FYI mstefank, jmesnil1@redhat.com, mchoma@redhat.com