Logo Questions Linux Laravel Mysql Ubuntu Git Menu

Override Spring form error messages

In Spring how do I override default form error massages ?

I'm using a Validator and a properties file to add my own error messages, but how do I override messages that get printed on conversion/encoding error for example ?

They seem to be generated automatically and I don't think are helpful for the user:

Failed to convert property value of type java.lang.String to required type java.lang.Double for property minPrice; nested exception is java.lang.NumberFormatException: 
like image 332
GionJh Avatar asked Mar 16 '23 17:03


1 Answers

You can override the defaults by creating custom messages in your localization bundle with keys following conventions defined by Spring's DefaultMessageCodeResolver. For the sake of completeness here is the relevant part of its documentation:

Will create two message codes for an object error, in the following order (when using the prefixed formatter):

1.: code + "." + object name
2.: code 

Will create four message codes for a field specification, in the following order:

1.: code + "." + object name + "." + field
2.: code + "." + field
3.: code + "." + field type
4.: code 

For example, in case of code "typeMismatch", object name "user", field "age":

1. try "typeMismatch.user.age"
2. try "typeMismatch.age"
3. try "typeMismatch.int"
4. try "typeMismatch" 

This resolution algorithm thus can be leveraged for example to show specific messages for binding errors like "required" and "typeMismatch":

at the object + field level ("age" field, but only on "user");
at the field level (all "age" fields, no matter which object name);
or at the general level (all fields, on any object). 

In case of array, List or Map properties, both codes for specific elements and for the whole collection are generated. Assuming a field "name" of an array "groups" in object "user":

1. try "typeMismatch.user.groups[0].name"
2. try "typeMismatch.user.groups.name"
3. try "typeMismatch.groups[0].name"
4. try "typeMismatch.groups.name"
5. try "typeMismatch.name"
6. try "typeMismatch.java.lang.String"
7. try "typeMismatch" 

By default the errorCodes will be placed at the beginning of constructed message strings. The messageCodeFormatter property can be used to specify an alternative concatenation format.

In order to group all codes into a specific category within your resource bundles, e.g. "validation.typeMismatch.name" instead of the default "typeMismatch.name", consider specifying a prefix to be applied.

like image 147
Bohuslav Burghardt Avatar answered Mar 24 '23 18:03

Bohuslav Burghardt