The exact scope of ValidatorFactory in Java EE (with and without CDI) is a bit unclear. Let's try and improve this.
In an ideal world, there should be one ValidatorFactory instance per application.
This is what the Bean Validation integration chapter describes. The wording is a bit unclear unfortunately
build and bootstrap the ValidatorFactory instance for an application.
This is inconsistent with the Java EE umbrella specification which states that:
we have one ValidatorFactory per module (WAR, EJB, etc)
there is no per-application validation deployment descriptor
The reason the Java EE spec got worded that way to make the rules simple on what META-INF/validation.xml file is to be considered. If two different modules have two different validation.xml files, things are unpredictable. So we chose to follow the same logic followed by JPA and its persistence.xml file. The benefits of that approach is that EJBs written "in isolation" from one another (with different validation.xml for example) will work as expected.
proposed to introduce an EAR level META-INF/validation.xml to define an app level ValidatorFactory. I like the idea. We would then have a clear app level factory and we can decide to either:
raise an exception at deployment time if other validation.xml are present in modules
have a different ValidatorFactory instance for modules that override validation.xml
force the app level validation.xml to have precedence
I am not sure if such global / per-module construct exists today in Java EE. We probably should model it similarly.
In CDI, the reference implementation makes ValidatorFactory application scoped. This breaks the Java EE spec wording and does not implement the per-module logic. The initial step, I think is to update the Bean Validation specification to clarify that in Java EE, we should follow the per module isolation.