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
#15811 Support for @Valid in @MessageMapping annotated methods
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.
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.