Allow kiwi to register its custom messages with Hibernate validator

[sleberknight]

kiwi has its own ValidatorMessages.properties which works fine in our services because none of those services have their own ValidatorMessages.properties. But if a service (or any application) uses kiwi and includes its own ValidatorMessages.properties, then that takes precedence over kiwi's and none of kiwi's validation annotations will work as expected; instead of having the expected violation message, you would simply get the name of the message template, e.g. you would see something like {org.kiwiproject.validation.Required.message} instead of is required. I guess this could be considered a bug, but I've labeled this discussion as an enhancement instead.

So, how can we make kiwi register its custom messages with Hibernate Validator (or whatever the validation provider is)?

I searched for how to do this and found How to use Java Hibernate validation with multiple Resource bundles? The accepted answer is the one we care about.

Per the answer, there is a lovely AggregateResourceBundleLocator, e.g.:

private static final ValidatorFactory FACTORY = Validation.byDefaultProvider()
     .configure()
     .messageInterpolator(new ResourceBundleMessageInterpolator(
          new AggregateResourceBundleLocator(List.of("MyLibraryValidationMessages", "MyAppValidationMessages"))))
     .buildValidatorFactory();

But, we want to use the above to still get the default behavior (i.e. using the bundle that comes with Hibernate Validator) as well as the one in kiwi and any one provided by an application.

And here's how we can do it, though not sure if this is "production-ready":

// These don't need to hard-coded, and we could provide a way to add more...
var bundleNames = List.of(
        "ValidationMessages",  // default bundle
        "org.kiwiproject.validation.ValidationMessages"  // the kiwi bundle
);

var validator = Validation.byProvider(HibernateValidator.class)
    .configure()
    .messageInterpolator(new ResourceBundleMessageInterpolator(
            new AggregateResourceBundleLocator(bundleNames)))
    .buildValidatorFactory()
    .getValidator();

Hibernate Validator takes care of also adding its own (i.e. the ValidationMessages_xx.properties properties files located in org.hibernate.validator). So in the above example code, three message bundles will be registered: ValidationMessages at the classpath root, org.kiwiproject.validation.ValidationMessages, and org.hibernate.validator.ValidationMessages. Each bundle should of course ensure that its property names are unique; in kiwi we prefix all ours with org.kiwiproject.validation.

We will also need to move kiwi's ValidationMessages.properties into src/main/resources/org/kiwi/validation/ in order for this to work. (And need to build a kiwi JAR and verify that I am correct.)

Another question is whether this will also pick up other locales, e.g. ValidationMessages_es.properties. I'm pretty sure the answer is "yes" since this is how Java's message bundles work.

And, we also need to update KiwiValidations#newValidator to do the above, and might also want to allow callers to specify this additional configuration, e.g.

public static final String KIWI_BUNDLE_NAME = "org.kiwiproject.validation.ValidationMessages";

// ...

KiwiValidations.newValidatorBuilder()
    .addMessageBundleName("ValidationMessages")
    .addMessageBundleName("com.acme.ValidationMessages")
    .addMessageBundleName(KiwiValidations.KIWI_BUNDLE_NAME)
    .build();

Or just always include the default bundle and kiwi's bundle and allow users to exclude them if desired? e.g.

KiwiValidations.newValidatorBuilder()
    .excludeDefaultBundleName()
    .excludeKiwiBundleName()
    .addMessageBundleName("com.acme.ValidationMessages")
    .build();

This would allow someone to completely override the default messages from Hibernate Validator and/or kiwi. One question would be what happens if you include a bundle that doesn't exist, e.g. if there is no ValidationMessages.properties at the root-level? Other than that, we can use the AggregateResourceBundleLocator to make this all work much better.

[sleberknight]

Also see #690

[sleberknight]

We don't need to specify the Hibernate-specific provider; we can use the generic provider, since it still provides access to configure the message interpolator.

Also, all this would also need to be integrated into the Dropwizard startup, e.g. in the initialize method, to build and change the ValidatorFactory in the Bootstrap object. This can easily be done since Bootstrap provides a setValidatorFactory method. This should obviously be opt-in such that an application chooses to do this.

[sleberknight]

Additional resources to read:

• Adding custom constraint definitions via the Java service loader
• Hibernate Validator Reference Guide - 12.15.1. Constraint definitions via ServiceLoader

[sleberknight]

The better way to do this is definitely adding custom constraint definitions via the Java service loader mechanism.

The one thing that could be problematic is using the Maven Shade plugin to build and uber-JAR, since only one ContributorValidationMessages.properties would "win" when shading. So, if two separate libraries (e.g., kiwi and some other library) both provide custom constraints and both have a ContributorValidationMessages.properties, then the build would need to use an Appending Transformer to combine/merge the contents of all files named ContributorValidationMessages.properties. And hopefully the files don't have conflicting keys, though as long as libraries "behave" it should not be an issue. For example, kiwi prefixes all the validation messages with org.kiwiproject.validation to avoid conflicts.

But as long as only the service has its own ValidationMessages.properties and kiwi contains the only ContributorValidationMessages.properties, then things will "just work".

[sleberknight]

This is addressed and fixed by #1112 , so this discussion is now closed.