The bean validation specification mentions the following
Clients call Configuration.buildValidatorFactory() to retrieve the initialized ValidatorFactory instance. It is legal to invoke buildValidatorFactory() several times, e.g. in order to retrieve several ValidatorFactory instances with a slightly different configuration (see Using Configuration to create several validator factories).
to indicate that a Configuration can be used to create several ValidatorFactories, but hibernate validation violates this aspect when it comes to MessageInterpolator.
I've attached a small maven project to implicate the issue. One can use
on the attached project to test the different versions (5.4.3.Final, 6.0.19.Final, 6.1.4.Final, and 7.0.0.Alpha1 respectively)
My investigation as to a possible RCA found that this is likely a regression from the change introduced in HV-1131, at HV-1131 code change, which equates to once getMessageInterpolator() is invoked, the first return is locked-in and all future invocations will always return the same value, even if messageInterpolator() is utilized.
As a workaround to have hibernate respect the bean validation specification, one must reflect on the Configuration and set the messageInterpolator field to null before doing any operation that performs getMessageInterpolator(), such as buildValidatorFactory() (which to honestly state is a rather dirty workaround)
I also cannot state that such a workaround will work long-term (such as with the module system of Java 9+)
Good catch. I'm working on a patch.
I see you went at great length to validate it on a lot of versions. How critical is this for you?
I would backport it up to 6.0.x but we haven't released a 5.4 in a while (last one was in Feb 2019) and I'm not sure it's worth releasing one. WDYT?
could you have a look at this PR: https://github.com/hibernate/hibernate-validator/pull/1086 ?
It includes your test and what is, I think, a proper fix. I also fixed an issue that could happen if the external class loader is changed.
The proposed fix looks sufficient.
As for backporting, only back to 6.0.x should be sufficient I think. 5.x is old enough to probably be left as “shelved”.
Thanks for the very detailed report. Will be fixed in next release train.