Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Load resource bundles with context class loader #68

Open
cerker opened this issue Jun 16, 2021 · 0 comments
Open

Load resource bundles with context class loader #68

cerker opened this issue Jun 16, 2021 · 0 comments

Comments

@cerker
Copy link

cerker commented Jun 16, 2021

Problem

Using Valiktor 0.12.0, I added some custom constraints including a custom resource bundle for i18n. Therefore, I implemented a custom interface extending the Constraint interface and overrode the messageBundle property as a base interface for my constraints.

My application is running on Quarkus 1.13 and the validation messages from the default and the custom resource bundle are loaded when running the application from the JAR file or in tests, using ConstraintViolation.toMessage(). However, Quarkus offers a development mode (see https://quarkus.io/guides/getting-started#development-mode) which provides things like hot deployment and against which you usually work during development. In dev mode the lookup of the resource bundle does not work, though it is correctly located in the classpath.

The root cause seems to be a class loader issue since I can successfully look the resource bundle up in my code, but it doesn't work from the classes in the Valiktor lib.

I can imagine that this problem could also appear in other contexts with special class loading behaviour like application servers or OSGi.

Solution

I found the following Issue in the Quarkus Github Repo (quarkusio/quarkus#8103) where they propose to always look up resource bundles passing the context class loader:

ResourceBundle.getBundle(baseName, locale, Thread.currentThread().getContextClassLoader())

Could Valiktor be changed so that resource bundles are always looked up like described or maybe add this as an alternative when the existing mechanism cannot find a bundle?

Alternatives

As a workaround, we are using Valiktor now without i18n, which is not a long term solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant