Avoid MessageFormat processing for default @Pattern validation message

[t-tera]

Affects: 5.1.5 RELEASE

Example1

Let's say a form bean has the following annotation:

@Pattern(regexp = "[\\w.'-]{1,}@[\\w.'-]{1,}")
private String email;`

If an invalid email is given, validation fails and the following error message is presented by form:errors tag.

... must match "[\w.-]{1,}@[\w.-][Ljavax.validation.constraints.Pattern$Flag;@4f413b2c"

Single quotes disappear and the second {1,} occurrence is replaced with [Ljavax.validation.constraints.Pattern$Flag;@4f413b2c.

Example2:

private Integer age;

Supply age={0}aaa'bbb then you get the following error message:

Failed to convert property value of type java.lang.String to required type java.lang.Integer 
for property age; nested exception is java.lang.NumberFormatException: For input string: 
"org.springframework.context.support.DefaultMessageSourceResolvable: codes formData.age,age]; 
arguments []; default message [age]aaabbb"

Again, {0} is replaced and single quote disappears.

The cause is that the values (the regexp in example1 and the user input in example2) are passed to java.text.MessageFormat#applyPattern() with no proper escaping.

It looks like the bug (example1) is similar to #11988.

[jhoeller]

Thanks for raising this! Our old fallback solution for MessageFormat mismatches isn't ideal there at all since it only catches invalid format syntax, not accidental matches with valid MessageFormat syntax.

As of 5.1.7, we generally don't apply MessageFormat rendering to Bean Validation default messages anymore, so any conflict with accidental placeholder or escaping syntax is avoided to begin with now.