Les messages Bean Validation (ci-après «BV») (messages par défaut fournis par des fournisseurs tels que Hibernate Validator (ci-après «HV»)) créent «ValidationMessages.properties» (fichier pour chaque langue car il s'agit d'un ensemble de ressources) directement sous le chemin de classe. Vous pouvez le changer en faisant.
Par exemple ... Lors de l'utilisation de HV comme fournisseur, les messages par défaut pour «@ Size» (annotation de contrainte fournie par VB) et «@ Length» (annotation de contrainte fournie par HV) sont les suivants.
Définition du message dans le fichier jar HV
javax.validation.constraints.Size.message = size must be between {min} and {max}
org.hibernate.validator.constraints.Length.message = length must be between {min} and {max}
Si vous souhaitez modifier ce message ...
src/main/resources/ValidationMessages.properties
javax.validation.constraints.Size.message = 'Size' must be between {min} and {max}.
org.hibernate.validator.constraints.Length.message = 'Length' must be between {min} and {max}.
Vous pouvez le changer en n'importe quel message.
ValidationMessages.properties?Ensuite, quand il y a plusieurs ValidationMessages.properties ... Qu'est-ce que c'est exactement? Dans le cas où j'ai été impliqué, il y avait une situation où ValidationMessages.properties existait dans les deux modèles suivants.
ValidationMessages.properties dans le fichier Jar (a été stocké)ValidationMessages.properties est stocké (a été stocké) dans chaque module.Dans la mesure où j'ai parcouru la spécification BV, plusieurs fichiers n'ont pas été mentionnés, il semble donc que la norme ne prend pas en charge plusieurs fichiers. (Puisque l'anglais est faible, il peut être lu ...)
Je n'ai pas supprimé les petits mouvements, mais ... Si vous utilisez HV comme fournisseur, l'un des fichiers sera valide. Le fichier avec la priorité la plus élevée du chemin de classe sera probablement utilisé, mais si la priorité ne peut pas être explicitement spécifiée comme le fichier jar dans la bibliothèque de l'application Web (war), l'implémentation du serveur d'application, etc. Il est également prévu que les fichiers activés par changeront. ↓ En conséquence, le message qui était censé être le message spécifié pour le fichier qui n'est pas devenu valide disparaît (→ c'est-à-dire qu'il devient un bogue).
Si vous êtes particulier au sujet de la conformité des spécifications BV, supprimez ValidationMessages.properties dans la bibliothèque ou le sous-module, et contrôlez de sorte queValidationMessages.properties soit un sur le chemin de classe lorsque l'application est exécutée.
Si vous n'êtes pas particulièrement attentif à la conformité aux spécifications BV et supposez que vous l'utiliserez sur + HV, [Fonction de lecture de la définition de message d'origine du mécanisme de HV](https://docs.jboss.org/hibernate/stable/validator/reference/ Vous pouvez utiliser en-US / html_single /? V = 6.0 # _constraint_definitions_via_code_serviceloader_code).
Plus précisément ... Veuillez changer pour stocker ContributorValidationMessages.properties au lieu deValidationMessages.properties directement sous le fichier Jar de la bibliothèque ou du sous-module. Cela permettra au HV de lire tous les ContributorValidationMessages.properties qui existent sur le chemin de classe et de créer le message.
Si vous organisez l'ordre de priorité des définitions de message (par ordre décroissant de priorité) lorsque vous utilisez HV ...
ValidationMessages.properties directement sous le chemin de classe (un seul fichier est valide s'il y en a plusieurs)ContributorValidationMessages.properties directement sous le chemin de classe (tous les fichiers sont valides)Ce sera.
Si la bibliothèque est destinée à être utilisée sur HV, il semble préférable de définir le message par défaut dans ContributorValidationMessages.properties et de le distribuer. Même si vous l'utilisez sur un fournisseur autre que HV, cela ne devrait pas être mauvais ...
Recommended Posts