Support Bean Validation 1.1 (JSR-349) [SPR-8199]

[spring-projects-issues]

Chris Beams opened SPR-8199 and commented

Bean Validation 1.1 (building on our BV 1.0 support in Spring 3.0)

---

Issue Links:

• Cannot configure validationMessageSource when using Hibernate 5 as validation implementation [SPR-10466] #15099 Cannot configure validationMessageSource when using Hibernate 5 as validation implementation

Referenced from: commits e0c56a1, 0d01222, 23bf5f5, cf93d38, 2a53a2d

15 votes, 21 watchers

[spring-projects-issues]

Juergen Hoeller commented

MethodValidationInterceptor autodetects Bean Validation 1.1's ExecutableValidator API now and uses it in favor of Hibernate Validator 4.2's native variant.
SpringConstraintValidatorFactory implements Bean Validation 1.1 "releaseInstance" method against new "destroyBean(Object)" method in AutowireCapableBeanFactory.
LocalValidatorFactoryBean adapts Spring-provided ParameterNameDiscoverer onto Bean Validation 1.1's ParameterNameProvider mechanism.
LocalValidatorFactoryBean reflectively adapts between the different ResourceBundleLocator SPI location in Hibernate Validator 4.2 versus 5.0.
LocalValidatorFactoryBean implements Bean Validation 1.1 "close" method.

[spring-projects-issues]

Jan Goyvaerts commented

Is there any hope for https://jira.springsource.org/browse/SPR-10384 ? :-)

[spring-projects-issues]

Brice Dutheil commented

That would be great if this development was backported to spring 3.x.

Also if that's of some interest, I found the ExecutableValidator useful, as the project I'm currently involved with uses CXF and we perform bean validation in a CXF Phase interceptor. So I wouldn't mind to reconsider the inclusion of forExecutables and getParameterNameDiscoverer

relevant commit : 0d01222

Anyway thanks for the work :)

[spring-projects-issues]

Juergen Hoeller commented

I'm afraid that there are no plans to backport this to Spring 3.x, since we're not considering any EE 7 level APIs there, and will effectively turn 3.2.x into maintenance mode as of May. Spring 3.2's regular Bean Validation 1.0 support should work even against a Bean Validation 1.1 provider at runtime - with the exception of method-level validation support which doesn't work at all there against Hibernate Validation 5.0, admittedly, since HV 5.0 dropped its old method validation API completely.

As for Spring 4.0's Bean Validation 1.1 support, with the introduction of getParameterNameDiscoverer on ValidatorFactory and forExecutables on Validator, we have a problem with Bean Validation 1.0 compatibility at runtime since both of those methods declare return types that are not available in the Bean Validation 1.0 API. After all, BV 1.0 is hard-coded into every EE 6 server out there, so we have to remain compatible with it: There is no way to override the version of the BV API in such an environment.

Now, with respect to "forExecutables", you could simply accept the LocalValidatorFactoryBean reference as a ValidatorFactory implementation and call "getValidator()" on it: This will return the provider's native Validator, with full support for "forExecutables". Or you could accept it as a Validator implementation and call "unwrap(Validator.class)" on it, which will expose the native Validator as well. This should even work with Spring Framework 3.2 against a Bean Validation 1.1 provider at runtime...

Juergen

[spring-projects-issues]

Brice Dutheil commented

Hi,

Fair enough, I understand you don't want to drop compatibility with JEE 6 containers. I didn't had that in mind as we are not really relying on JEE servers in the current architecture. Thanks for sharing the point.

Now, with respect to "forExecutables", you could simply accept the LocalValidatorFactoryBean reference as a ValidatorFactory implementation and call "getValidator()" on it: This will return the provider's native Validator, with full support for "forExecutables". Or you could accept it as a Validator implementation and call "unwrap(Validator.class)" on it, which will expose the native Validator as well. This should even work with Spring Framework 3.2 against a Bean Validation 1.1 provider at runtime...

Yes that was our current plan. However the way the LocalValidatorFactoryBean and SpringValidatorAdapter are designed, we can't add custom ParameterNameDiscoverer without rewriting the whole factory which is not impossible but a bit less convenient if we want to remain as standard as possible (regarding Spring as a de facto standard).

Anyway thanks for your input on the matter.

Cheers,
Brice