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

[spring-projects-issues]

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:

• beans.xml (5.57 kB)
• DaoFactory.java (860 bytes)
• MyDao.java (2.58 kB)
• MyDaoImpl.java (640 bytes)
• ProjectDao.java (66 bytes)

[spring-projects-issues]

Jan Goyvaerts commented

The interface extending JpaRepository

[spring-projects-issues]

Jan Goyvaerts commented

Context configuration. The classic JPA/Hibernate/EHCache stuff

[spring-projects-issues]

Jan Goyvaerts commented

The repository factory referenced in the context configuration

[spring-projects-issues]

Jan Goyvaerts commented

Implementation of the repository interface

[spring-projects-issues]

Jan Goyvaerts commented

An example of a repository interface used in the code

[spring-projects-issues]

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]

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]

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]

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 ...)