feat: Default I18N provider

[caalador]

Add implementation for a I18N
provider that is loaded if there
are translation properties files
in the defined classpath folder.

If a custom I18N is set default will
never be loaded.

Fixes #5917

[github-actions]

Test Results

1 013 files  +  3  1 013 suites  +3   1h 2m 35s ⏱️ -16s
6 487 tests +10  6 446 ✔️ +11  41 💤 ±0  0 ❌  - 1 
6 743 runs  +  9  6 695 ✔️ +10  48 💤 ±0  0 ❌  - 1 

Results for commit ebfa2f3. ± Comparison against base commit 5a62cc9.

♻️ This comment has been updated with latest results.

[knoobie]

Would it make sense to move this in a protected method to allow overwriting this to e.g. implement a caching mechanism? MessageFormat can be quite expensive.

[caalador]

I don't think the default implementation brings in so much functionality that it would make sense to override it instead of just implementing your own I18NProvider as you need to anyway set it as you do at the moment.

[knoobie]

I just wanted to ask if you wanna also implement a PropertyPlaceholderResolver in here, with your comment.. I think I know the answer :D Reference of the resolver used by Spring: https://github.com/spring-projects/spring-framework/blob/main/spring-core/src/main/java/org/springframework/util/PropertyPlaceholderHelper.java

[knoobie]

General Question: Should this class be registered as Spring Bean with ConditionalOnMissingBean so that it's also available for DI in Spring as default and people can inject / use it even without always asking the Instantiator for it.

[caalador]

The springInitiator actually falls back on the defaultInitiator on this if no bean found:

    public I18NProvider getI18NProvider() {
        int beansCount = context.getBeanNamesForType(I18NProvider.class).length;
        if (beansCount == 1) {
            return context.getBean(I18NProvider.class);
        } else {
            if (loggingEnabled.compareAndSet(true, false)) {
                LoggerFactory.getLogger(SpringInstantiator.class.getName())
                        .info("The number of beans implementing '{}' is {}. Cannot use Spring beans for I18N, "
                                + "falling back to the default behavior",
                                I18NProvider.class.getSimpleName(), beansCount);
            }
            return super.getI18NProvider();
        }
    }

[caalador]

Also having Spring annotations is a bit problematic as this is outside of spring in the normal framework.

[knoobie]

Thanks for the explanation! Yeah, I was wondering if it would be worth to add it to the VaadinApplicationConfiguration like a bean:

  @Bean
  @ConditionalOnMissingBean(value = I18NProvider.class)
  public DefaultI18NProvider vaadinI18nProvider() {
    return new DefaultI18NProvider(/* get locales from somewhere*/);
  }

[mcollovati]

Maybe a known issue, but this seems not to work when running the application as a Spring Boot fat JAR

[mcollovati]

And it seems not to work even if I put the translations in a JAR file, although I don't know if this can be considered a valid use case for this feature.

bundleFolder= file:/xxxxxxxxx/vaadin/starters/skeleton-starter-flow/v-i18n.jar!/vaadin-i18n
bundleFolder.exists() = false

[caalador]

Good Point. I'll look into it and fix the jar path. It will require using the FileSystem, but should be doable.

[caalador]

Now it knows how to handle the files inside jars also.

[mcollovati]

Works great with the resource bundle in JAR!

However, is still fails with the Spring Boot fat JAR, both by adding the properties files in the project or in external JAR.

bundleFolder = {File@6570} "file:/xxxx/skeleton-starter-flow-spring/target/spring-skeleton-1.0-SNAPSHOT.jar!/BOOT-INF/classes!/vaadin-i18n"
pathInJar = "/BOOT-INF/classes!/vaadin-i18n"


bundleFolder = {File@8348} "file:/xxxx/skeleton-starter-flow-spring/target/spring-skeleton-1.0-SNAPSHOT.jar!/BOOT-INF/lib/i18n-1.0.jar!/vaadin-i18n"
pathInJar = "/BOOT-INF/lib/i18n-1.0.jar!/vaadin-i18n"

For the first case, removing the ! from pathInJar makes the solution work. The second case is more tricky.
I wonder if it could be better to provide some specific implementations in the Spring add-on, or if we have to find some hack
to add in the current implementation 🤔

[knoobie]

I would suggest to go with a spring based solution in the spring module based on

ResourcePatternResolver allowing to get all resources within a folder in a spring boot application within one line of code - foul and future proof :) relying on it for years to load our default configurations

[caalador]

Seeing as this was supposed to be a small enhancement, I would propose to open a new ticket for creating Spring-Boot fat Jar support by extending the default translation with Spring parts in the spring add-on

[mcollovati]

It looks like we need a ticket as well for the Quarkus add-on.
The class loader used to detect the bundle folder ( I18NUtil.class.getClassLoader()) returns null, whereas it works using Thread.currentThread().getContextClassLoader()
Would it be possible to replace the protected static ClassLoader getClassLoader() method with a non-static version, so it can be overridden to provide the best class loader for each environment?
Or can we have the class loader reference as class member, provided to additional constructor?

[caalador]

We can use current as that's not a problem. Sending a loader around becomes too complex for testing from instantiator

[mcollovati]

Works fine in Quarkus now 👍

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[vaadin-bot]

This ticket/PR has been released with Vaadin 24.3.0.alpha1 and is also targeting the upcoming stable 24.3.0 version.