New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Bean Validation 1.1 (JSR-349) [SPR-8199] #12848
Comments
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. |
Jan Goyvaerts commented Is there any hope for https://jira.springsource.org/browse/SPR-10384 ? :-) |
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 relevant commit : 0d01222 Anyway thanks for the work :) |
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 |
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.
Yes that was our current plan. However the way the Anyway thanks for your input on the matter. Cheers, |
Chris Beams opened SPR-8199 and commented
Bean Validation 1.1 (building on our BV 1.0 support in Spring 3.0)
Issue Links:
Referenced from: commits e0c56a1, 0d01222, 23bf5f5, cf93d38, 2a53a2d
15 votes, 21 watchers
The text was updated successfully, but these errors were encountered: