We’re observing a behavioral change when upgrading from WildFly 30 to WildFly 37 regarding the context classloader used during initializing extensions.
In our case, this change prevents the Hibernate Validator CDI extension from finding validation.xml within the deployed WAR.

Environment:

• WildFly version: 37
• Previously working version: 30
• Deployment: EAR with a single WAR

Steps to Reproduce (see below)

Expected Behavior:

• During startup, when org.hibernate.validator.cdi.ValidationExtension is built,
  the validation.xml resource should be found from within the WAR file (as it was in WildFly 30).
• The validator system should initialize correctly.

Actual Behavior:

• In WildFly 37, the resource is not found because the
  Thread Context ClassLoader is now set to the EAR classloader,
  which does not (yet?) see resources within the WAR.
• This causes the validator system to fail initialization.

Relevant Reference:

• Configuration in ValidationExtension:
  https://github.com/hibernate/hibernate-validator/blob/d77cf435375fff425b2c1465c1bb8b7959b86754/cdi/src/main/java/org/hibernate/validator/cdi/ValidationExtension.java#L112
• Resource loading happens here:
  https://github.com/hibernate/hibernate-validator/blob/d77cf435375fff425b2c1465c1bb8b7959b86754/engine/src/main/java/org/hibernate/validator/internal/xml/config/ResourceLoaderHelper.java#L39
  • In WildFly 30, this call succeeded because the TCCL was the WAR classloader.
  • In WildFly 37, it uses the EAR classloader instead.

Additional Notes:

• We rely on CDI-aware ValidatorFactory creation since we use CDI-managed validators, message interpolators, etc.
• If this is an intentional classloading change, we’d appreciate guidance on how to restore the previous behavior via configuration.

Any help/hint/workaround apprecciated!