Clarify the scope of ValidatorFactory in a Java EE deployment

Description

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.

Environment

None

Status

Assignee

Unassigned

Reporter

Emmanuel Bernard

Labels

None

Worked in

None

Feedback Requested

None

Feedback Requested By

None

backPortable

None

Community Help Wanted

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

backportReEvaluate

None

Fix versions

Priority

Major