Validation failure not exposed next to binding failure for immutable form class [SPR-16841]

[spring-projects-issues]

Masatoshi Tada opened SPR-16841 and commented

Immutable sample -> https://github.com/MasatoshiTada/spring-mvc-form-sample/tree/master/01-immutable
Mutable sample -> https://github.com/MasatoshiTada/spring-mvc-form-sample/tree/master/02-mutable

 

"Message" is constrained by @NotBlank and "Birthday" is constrained by @NotNull and @DateTimeFormat(pattern = "yyyy-MM-dd").

1. Behavior of mutable sample
   Both values are validated (see "mutable.png")

2. Behavior of immutable sample
   The only "Birthday" is validated (see "immutable.png")

---

Affects: 5.0.6

Reference URL: https://github.com/MasatoshiTada/spring-mvc-form-sample/blob/master/01-immutable/src/main/java/com/example/immutable/SampleForm.java

Attachments:

• immutable.png (82.00 kB)
• immutable-20180717.png (54.22 kB)
• mutable.png (87.24 kB)
• mutable-20180717.png (23.37 kB)

Issue Links:

• Cannot create BindStatus for valid field on immutable form object in case of bind errors [SPR-16449] #20994 Cannot create BindStatus for valid field on immutable form object in case of bind errors
• Validation is not executed when type conversion failed on immutable form [SPR-17235] #21768 Validation is not executed when type conversion failed on immutable form
• spring-webflux ModelAttributeMethodArgumentResolver validateIfApplicable [SPR-17073] #21611 spring-webflux ModelAttributeMethodArgumentResolver validateIfApplicable
• @RequestBody validation kotlin support improvement [SPR-17085] #21622 @RequestBody validation kotlin support improvement
• No type-based error code used by immutable form class when type conversion error occurs [SPR-16854] #21394 No type-based error code used by immutable form class when type conversion error occurs

Referenced from: commits 955665b

[spring-projects-issues]

Juergen Hoeller commented

While I was able to reproduce the other two data class issues, this one seems to work for me: I always get constraint violations for all affected fields reported. Could you double-check what was going wrong for you here?

[spring-projects-issues]

Masatoshi Tada commented

Thank you for your check!

I've checked again just now, and I found my mistakes.

But validation behaviors of two are still different. (See attached images)

When form is immutable and type conversion failed at "Birthday", there is no messages at "Message".

Could you take a look again?

!immutable-20180717.png!

!mutable-20180717.png!

[spring-projects-issues]

Juergen Hoeller commented

I see what you mean now: With immutable form classes, we aggregate type mismatches in the initial pass when trying to construct the instance, so type mismatches will appear on their own first. We can't run the regular bean validation step in such a case since there is literally no instance state to introspect yet and therefore no other field values to validate; that's unfortunately a limitation in the common JSR-303 instance model. For that reason, regular constraint violations will only appear once all type mismatches have been resolved and an instance could be constructed.

In case of type mismatches, we could individually validate other property values through Validator.validateValue (getting a constraint 'preview' report for the case when we would bind a specific value, instead of a post-binding report against a full object instance) and aggregate them in the same phase. This would roughly lead to the same validation report as in the instance case. I'll give that a try.

[spring-projects-issues]

Juergen Hoeller commented

This will be available in the upcoming 5.1.0.BUILD-SNAPSHOT. Please give it an early try...

[spring-projects-issues]

Masatoshi Tada commented

Thank you so much!

I tried Spring 5.1.RC1, and unfortunately it seemed that this issue is not fixed.

Could you check it again, please?

 

[spring-projects-issues]

Juergen Hoeller commented

This works for me in a unit test (ServletAnnotationControllerHandlerMethodTests.dataClassBindingWithValidationErrorAndConversionError)... Could you try to isolate your case a bit further so that we can identify the differences?

[spring-projects-issues]

Juergen Hoeller commented

I'll keep this ticket marked as resolved for RC1, with the intended feature at least partially working there. For follow-up work based on your scenario, please create a separate ticket which I'll look at ASAP.