GH-39865 added support for MethodValidationResult to DefaultErrorAttributes but it filters the list errors published in the result and used for counting to instances of ObjectError.

With a method signature (in a RestController) of e.g. public void method(@PathVariable @Pattern(regexp = "^a.*") String parameter), this results in * message = "Validation failed for method='public void <class>.method(java.lang.String)'. Error count: 0" * errors = []

This is due to the fact, that the MethodValidationResult generated by MethodValidationAdapter will contain instances of ParameterValidationResult that have resolvable errors of type DefaultMessageSourceResolvable (and not ObjectError).

Spring Boot 3.3.1 Spring Framework 6.1.10

Comment From: wilkinsona

This was (somewhat) intentional as we wanted to be confident that the error was suitable for serializing to JSON. Filtering things so that only ObjectError instances are considered achieved this and aligned with what we already do for BindingResult. Perhaps we can relax things a little. To help us to investigate, please provide a minimal sample that reproduces the behaviour that you have described.

Comment From: sunruh

As an ObjectError extends DefaultMessageSourceResolvable, relaxing it should be ok.

Actually the example in https://github.com/spring-projects/spring-framework/issues/32396#issuecomment-1985602958 would cause it.

  • A validation problem regarding the RequestBody object would show up as that would create a ParameterErrors instance due to the problem being in a property (of the object).
  • A validation problem regarding the String parameter does not show up, as that creates a ParameterValidationResult (containing DefaultMessageSourceResolvable as errors)

Comment From: wilkinsona

Thanks for the additional details but I'd really like to see a complete, minimal sample that reproduces this. Can you please provide one?

Comment From: sunruh

spring-boot-issue-42013.zip

Here's a minimal sample. I based it on Spring Boot 3.3.3.

  • One of the test classes will show the problem
  • The other test class has a (potential) fix applied to addMessageAndErrorsFromMethodValidationResult() where it does not filter for ObjectError instances and the same test case succeeds.

The tests do not use MockMvc on purpose as otherwise the error controller would never be called.

Comment From: philwebb

I'm wondering if we should create our own wrapper object for serialization and try to support the MessageSourceResolvable. Looking at the code, there's a lot of overlap with the reactive and servlet version of DefaultErrorAttributes and I wonder if now might also be the time to try and pull the common code up to the org.springframework.boot.web.error package.

Comment From: philwebb

We discussed this today and would like to add a wrapper object. This will be a slight breaking change and the Javadoc of DefaultErrorAttributes will need to be updated. We'll need to provide a way for the user to get the original ObjectError if they wish to.

Comment From: YongGoose

@philwebb

Can i contribute?

Comment From: philwebb

Absolutely @YongGoose, that would be most welcome. We won't be able to merge it for 3.4 but it can be a 3.5 enhancement.

Comment From: philwebb

Closing in favor of PR #43330. Thanks @YongGoose