Provide default validation message in ContributorValidationMessages.properties

[yoshikawaa]

Description

Now, default messages of constraint annotation provided by common library is defined in ValidationMessages.properties of blank project.
However, this is vulnerable to changes, as you need to change the blank project whenever you change the common library. And we should also use a blank project to benefit from the default message.

In the first problem, only one ValidationMessages.properties is allowed per application in the Bean Validation specification (at least in the Hibernate Validator implementation).

-> See guideline JP.

To solve this, HibernateValidator provides ContributorValidationMessages.properties for defining default messages in libraries and submodules.

HibernateValidator resolves messages in the following order:

1. Only one ValidationMessages.properties
2. All of ContributorValidationMessages.properties
3. HibernateValidator default message ( org/hibernate/validator/ValidationMessages.properteis )

If don't use HibernateValidator, ContributorValidationMessages.properties is just ignored and does no harm.

Possible Solutions

(Please write ideas or candidates of solutions for the problem if you have)

Affects Version/s

• 5.5.1.RELEASE

Fix Version/s

• 5.6.0 (master)

Issue Links

• ValidationMessages.properties should not be included in terasoluna-gfw-common #256

[yoshikawaa]

Will it be a disruptive change?

Do not assume that disruptive changes will "prevent existing functionality".

1. If a default message is listed in ValidationMessages.properties, this takes precedence.
   -> The message definition of the existing blank project has priority.
2. If there is no default message in ValidationMessages.properties, the default message in ContributorValidationMessages.properties is used.
   -> If the message definition of an existing blank project has been deleted, the default message will be displayed if the message key has been displayed.
   -> The message key is displayed as an application bug, so there is no reason to protect this behavior

Supported version

Assuming that it will not be a disruptive change, messages will not be changed without special migration, so it will be improved rather than adding new functions.
As an improvement, it is assumed that it will be released as a maintenance version.