Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect resolution of ResolvableAttributes when MessageSourceSupport#alwaysUseMessageFormat is true [SPR-15123] #19690

spring-projects-issues opened this issue Jan 10, 2017 · 1 comment
in: core type: bug


Copy link

@spring-projects-issues spring-projects-issues commented Jan 10, 2017

Nicholas Tsim opened SPR-15123 and commented

Since Spring 4.3, validation annotation attributes are captured as ResolvableAttribute in SpringValidatorAdapter if they are strings. This behaviour appears to have been introduced due to #17986.

When MessageSourceSupport#alwaysUseMessageFormat is set to true (in the case of Spring Boot, it is possible to set this using the spring.messages.always-use-message-format property) it appears that attributes that may not need formatting will be passed through MessageFormat.

In my use case, I have code like this:

public class ValidatedBean {
    @Pattern(regexp = "[\\p{L} -]*", message = "{firstname.required}")
    private String firstName;

The regex is a valid expression that matches on Unicode letter characters.

Spring will try and pass the regexp attribute string through MessageFormat which causes issues as it then tries to resolve an argument for parameter L. Specifically, it will throw IllegalArgumentException in MessageFormat#makeFormat.

I don't think ResolvableAttribute should be applied to the regexp attribute (or any other attribute) indiscriminately. Is there something that can/should be done about this?

Affects: 4.3.5

Issue Links:

  • #17986 Support MessageSourceResolvable to string argument value at SpringValidatorAdapter
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 12, 2017

Juergen Hoeller commented

We explicitly never format a code-as-default-message now, even with alwaysUseMessageFormat=true. This is in sync with the useCodeAsDefaultMessage feature, just also checked against a MessageSourceResolvable's exposes default message now.

With the above in place, our explicit wrapping of constraint attributes just leads to optional message lookups now but doesn't impact the default attribute value anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: core type: bug
None yet

No branches or pull requests

2 participants