Hibernate Class Level Validators cause IllegalArgument Exception [SPR-8895]

[spring-projects-issues]

Dan Ford opened SPR-8895 and commented

When a class level validator is invoked during "binding" of an input form with a "form object"/Bean, its failure to validate at the class level is treated as a "FieldError". This causes an IllegalArgumentException to be reported later from GenericConvesionService.convert() when it attempts to convert the Bean (i.e., the "value") to the type of the field, e.g., to String. This issue does not exist in 3.1.0.RC1. From 3.1.0.RC1 to 3.1.0.RC2, there was a change to SpringValidatorAdapter.validate(Object,Errors) that seems to be one/the source of this problem. Attached is an Eclipse/Maven project that demonstrates the issue. The pom.xml file has two profiles one for 3.1.0RC1 and one for 3.1.0.RC2. There are two Eclipse launch configurations defined that invoke Maven with one or the other profile active. Maven will start up Jetty and then run a single Selenium test that provides two different "passwords" for a "new user page". A "@Matches" validator will be called to compare these two values and will return "false" because they are different. The current logic seems to treat this as a "binding failure" and associates the Bean instance (the value being validated) with the "confirmationPassword" field as its "invalid value." The conversion service later tries to convert the Bean to a String, the type of the field, which causes the IllegalArgumentException to be thrown.

---

Affects: 3.1 RC2

Attachments:

• RC2Bug.zip (46.29 kB)

Issue Links:

• NumberFormatException caused by property paths from JSR-303 based validation with no index into a collection [SPR-8634] #13276 NumberFormatException caused by property paths from JSR-303 based validation with no index into a collection

Referenced from: commits aedccec

[spring-projects-issues]

Juergen Hoeller commented

The problematic case here is that you're declaring a bean-level constraint while nevertheless registering a property path for the resulting constraint violation. Hibernate Validator exposes the bean itself as the invalid value then, despite the registered path pointing to a specific property. This specific case was not handled by our SpringValidatorAdapter change in 3.1 RC1.

In any case, for 3.1 GA, we've restored SpringValidatorAdapter's ability to handle bean constraints with property paths, using a specific check for this case.

Juergen

[spring-projects-issues]

Dan Ford commented

Juergen, thanks for the quick resolution. It has been a long time since I wrote this code and had my head in the validation framework, for my education, I'm a bit unclear on your comment: "while nevertheless registering a property path for the resulting constraint violation". How did I register a property path? Is there some other/better way I could have implemented the constraint to avoid this issue? Thx!

[spring-projects-issues]

Juergen Hoeller commented

Dan, it's the following part in your validator implementation:

context.buildConstraintViolationWithTemplate(
        "{com.forddaniel.end.constriants.matches}")
        .addNode(fieldName2).addConstraintViolation();

where the addNode(fieldName2) part specifies a property path for this violation, despite the violation itself being defined at the bean level.

This isn't wrong per se. It's just a bit of an unclear case in JSR-303 where the invalid value as provided by Hibernate Validator is inappropriate (and since 3.1 RC1, we're relying on exactly that value). We're falling back to Spring-driven lookup of the actual property value for that specific case in 3.1 GA now.

Hope that helps,

Juergen