mvc:annotation-driven incorrectly detects validation provider on classpath [SPR-11272]

[spring-projects-issues]

John Mark opened SPR-11272 and commented

I currently have javax.validation:validation-api:1.1.0.Final on my classpath since I include an artifact that uses that jar. Spring seems to detect this and try to create a validator using org.springframework.validation.beanvalidation.LocalValidatorFactoryBean which then fails since I don't have a validation provider like Hibernate Validator on my classpath. This then causes my entire webapp to fail to start.

This behavior does not make sense to me. If I don't have a validation provider on my classpath, then why does Spring think I want to use validation? I would think that mvc:annotation-driven should use the same type of detection mechanism that LocalValidatorFactoryBean uses to determine if a validation provider is on the classpath. That way it wouldn't try to create a validator just because I have the validation API on my classpath. It should only try to create a validator if a provider implementation exists. According to the documentation at http://docs.spring.io/spring-framework/docs/current/spring-framework-reference/html/mvc.html (Section 16.1.1) mvc:annotation-driven/ should only enable validation if a JSR-303 Provider is present on the classpath.

---

Affects: 4.0 GA

Issue Links:

• Support for @Valid in @MessageMapping annotated methods [SPR-11185] #15811 Support for @Valid in @MessageMapping annotated methods

Referenced from: commits b9c8f47, 6a5a3c9, e334489, 6aabb5f, c48da0d, 8d1e55d

[spring-projects-issues]

Juergen Hoeller commented

Unfortunately, this isn't trivial to address: We only know about the existence of an actual validation provider through a call to JSR-303's Validation.byDefaultProvider().configure()... which triggers a whole chain of initialization steps in the provider that we don't want to trigger at the time of Spring namespace parsing.

In Spring Framework 4.0.1, we should be able to address this through a custom LocalValidatorFactoryBean subclass or delegate that only actually performs validation if a JSR-303 provider is available. However, this seems too risky a change for the 3.2.7 release. I'll see what we can do for 4.0.1; I hope you don't mind an upgrade to that one.

Juergen

[spring-projects-issues]

Brian Clozel commented

Since #15811, AbstractMessageBrokerConfiguration needs a Validator instance (it's trying to fetch an instance created by WebMvcConfigurationSupport, but creates one if none available).

This issue is resolved for 4.0.1, so this Configuration class has the same issue regarding the validation API and may need additional work in the simpValidator method.

[spring-projects-issues]

Juergen Hoeller commented

Brian, I've introduced an OptionalValidatorFactoryBean subclass that simply catches and logs setup exceptions, turning Validator calls into no-ops in such a scenario. If you're setting up a LocalValidatorFactoryBean at the moment, simply switch to OptionalValidatorFactoryBean to get the no-op fallback behavior. To be committed in a few minutes.

Juergen