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

Inconsistent behavior for JSR 303 method validation [DATAJPA-311] #677

Closed
spring-projects-issues opened this issue Mar 13, 2013 · 9 comments
Closed
Assignees
Labels
in: core type: bug

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Mar 13, 2013

Jan Goyvaerts opened DATAJPA-311 and commented

I'm trying to get repository method argument and return type validation. To eliminate any repetitive need to write explicit validation code on them.

The various methods of JpaRepository are overridden in a subinterface to enforce this behavior.

There seems to be a dependency on the way the code is built. Because depending on what did the build (Maven or Intellij) and in what order (Maven after Intellij or inverse) the validation works, sometimes work, is totally ignored or triggers an error that no validator was found for Iterable<S>.

Initially the annotation @NotEmpty was used. Replacing it by @NotNull @Size(min=1) alas did not solve the problem.

I have tried many configurations, but never can I seem to get a consistent behavior. Hence this bug.

I'm including the various concerned files into this ticket.

Btw, let me congratulate the people who had the stroke of genius of "programming-repositories-by-intention" !


Affects: 1.3 GA

Attachments:

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Mar 13, 2013

Jan Goyvaerts commented

The interface extending JpaRepository

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Mar 13, 2013

Jan Goyvaerts commented

Context configuration. The classic JPA/Hibernate/EHCache stuff

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Mar 13, 2013

Jan Goyvaerts commented

The repository factory referenced in the context configuration

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Mar 13, 2013

Jan Goyvaerts commented

Implementation of the repository interface

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Mar 13, 2013

Jan Goyvaerts commented

An example of a repository interface used in the code

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Mar 14, 2013

Jan Goyvaerts commented

UPDATE:

The CI environment runs the very same test code, in separate VM's, against different databases. Sometimes the validation is applied. Sometimes it isn't. Rerunning with the same code might fail different jobs. While previously failing jobs might succeed

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Mar 15, 2013

Jan Goyvaerts commented

UPDATE:

MUCH more stable behavior with Hibernate Validator 5.0.0.CR2 !

To make it work:

  • Define a custom aspect to intercept calls to methods annotated with javax.validation.constraint.* and org.hibernate.validator.constraints.* and imitate MethodValidationPostProcessor.
  • Redefine JpaRespository, CrudRepository and PagingAndSortingRepository - to provide annotations to the methods. Otherwise there's no way to overcome BV inheritance specs 4.5.5.

The inconsistent behavior reappears when keeping the redefined interfaces but reverting to HV 4.3 and using MethodValidationPostProcessor instead of the custom aspect.

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Mar 15, 2013

Jan Goyvaerts commented

Is it possible to close this ticket ?

I've replaced Spring data with in-memory service objects. And it still gives the random validation results.

Hence Spring Data is not to blame here. :-)

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented May 22, 2019

Jens Schauder commented

Batch closing resolved issue without a fix version and a resolution indicating that there is nothing to release (Won't fix, Invalid ...)

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

No branches or pull requests

2 participants