Details

    • Last commented by a User:
      true

      Description

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

        Issue Links

          Activity

          Hide
          Juergen Hoeller added a comment -

          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.

          Show
          Juergen Hoeller added a comment - 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.
          Hide
          Jan Goyvaerts added a comment -
          Show
          Jan Goyvaerts added a comment - Is there any hope for https://jira.springsource.org/browse/SPR-10384 ?
          Hide
          Brice Dutheil added a comment -

          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 : https://github.com/SpringSource/spring-framework/commit/0d0122239d84ca27069350de19394273ea3aced3

          Anyway thanks for the work

          Show
          Brice Dutheil added a comment - 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 : https://github.com/SpringSource/spring-framework/commit/0d0122239d84ca27069350de19394273ea3aced3 Anyway thanks for the work
          Hide
          Juergen Hoeller added a comment -

          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

          Show
          Juergen Hoeller added a comment - 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
          Hide
          Brice Dutheil added a comment -

          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

          Show
          Brice Dutheil added a comment - 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

            People

            • Assignee:
              Juergen Hoeller
              Reporter:
              Chris Beams
              Last updater:
              Juergen Hoeller
            • Votes:
              15 Vote for this issue
              Watchers:
              21 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                51 weeks, 6 days ago