[ https://issues.redhat.com/browse/WFLY-12835?page=com.atlassian.jira.plugi... ] Jeff Mesnil commented on WFLY-12835: ------------------------------------ I still think this is a feature request. MicroProfile does not specify anything related to EAR deployments so it's up to us (WildFly) to decide what is supported or not. It used to work in WildFly 16 by chance but the fix for WFLY-12811 highlighted that injecting Config property in a health check in a WAR deployment was not working. This use case is covered by MicroProfile so I changed the behaviour. As Charles is mentioning in his PR, the tricky part is not really MP Health but MP Config. When a EAR is having a health check in a subdeployment, where the MP Config property values come from? In the current codebase, each deployment have their own instance of Config that is bound to the deployment's module class loader. This does not align with EAR class loader mechanism as the WAR deployment will not use Config Source provided by a library JAR in the EAR. I'm fine with supporting EAR with the following caveats: * MicroProfile Health Checks that uses injected config properties MUST provide the property values in the same sub deployment (i.e. providing a JAR library to provide config property values to multiple subdeployments is still not supported) * MicroProfile Health Checks names must be unique across subdeployments -- This message was sent by Atlassian Jira (v7.13.8#713008)