NotReadablePropertyException on validated list in request body when there are validation errors

[plc010]

Affects: 6.1.1 (Spring Boot 3.2.0)

Not sure if this is an issue or expected behavior and I missed something in the upgrade guide. Spring Boot 3.1.6 and earlier produce expected binding result errors.

The sample code attached will produce the exception below when a constraint violation (blank dog name) is in the request

org.springframework.beans.NotReadablePropertyException: Invalid property 'list[0]' of bean class [com.demo.validationdemo.Dog]: Bean property 'list[0]' is not readable or has an invalid getter method: Does the return type of the getter match the parameter type of the setter?

Sample request body with constraint violation:

[
  {
    "name": ""
  }
]

With Spring Boot 3.1.6 and earlier, the expected binding results below are produced:

Field error in object 'dogs' on field 'list[0].name': rejected value []; codes [NotEmpty.dogs.list[0].name,NotEmpty.dogs.list.name,NotEmpty.list[0].name,NotEmpty.list.name,NotEmpty.name,NotEmpty.java.lang.String,NotEmpty]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [dogs.list[0].name,list[0].name]; arguments []; default message [list[0].name]]; default message [must not be empty]

I have tried changing the data binder to allow direct field access, but that did not resolve the issue. Stepping through the code it seems the list property of the Dogs class is not an available property to the AbstractNestablePropertyAccessor class as it is in Spring Boot 3.1.6 and earlier.

Update:
I've found that if I replace the @Valid annotation on the request body in the controller method with @Validated the binding errors match the behavior seen in Spring Boot 3.1.6.

Change

ResponseEntity<Void> uploadList(@RequestBody @Valid @NotNull Dogs dogs, BindingResult bindingResult) {

to

ResponseEntity<Void> uploadList(@RequestBody @Validated @NotNull Dogs dogs, BindingResult bindingResult) {

---

validation-demo.zip

[rstoyanchev]

Thanks for the sample. The issue is a subset of #31746 where the problem is described more broadly. It is related to changes for #31530. For now, I am closing this as superseded, but will confirm any fixes with the sample.