Skip to content
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

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

Closed
spring-projects-issues opened this issue Jan 1, 2014 · 3 comments
Assignees
Labels
in: web type: bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Jan 1, 2014

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:

  • #15811 Support for @Valid in @MessageMapping annotated methods

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

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 3, 2014

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 3, 2014

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 3, 2014

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web type: bug
Projects
None yet
Development

No branches or pull requests

2 participants