fallback messege file in spring boot is always "en" - spring-boot

I configured my web application as indicated in https://www.baeldung.com/spring-boot-internationalization#localeresolver
with setting Locale.ITALIAN as default locale for LocaleResolver bean.
I have two message files:
message.properties with italian messages
message_en.properties with messages in english
However, labels defined in messages_en.properties, when exists. For example with setting locale via lang=es request parameter, messages in english are shown.
The expected behaviour, if I understand, should be that if lang=en, message_en.properties should be used, where as for all other languages messages in message.properties should be used.
Suggestions?

If you use the latest version of Spring Boot (2.5.3 at the moment), the tutorial isn't as up-to-date. For example, with the latest Spring you must do additional, but simple config to override LocaleResolver bean.
Depending of your implementation, you may need to add in the application.properties file the line spring.messages.fallback-to-system-locale=false or if you overridden the "messageSource" bean, you must set messageSource.setFallbackToSystemLocale(false); in your own bean.
This way the app should work as expected, with all languages except EN using message.properties.

Related

In Spring Boot how do you register custom converters that are available when parsing application configuration?

In a Spring Boot application how do you register custom converts to be used when processing application configuration?
I have made a custom convert (org.springframework.core.convert.converter.Converter) so it can be used by the ApplicationConversionService/Binder to parse #ConfiguraitonProperties defined in application.properties and application.yaml configuration files but do not know how to register it.
I have tried the solution here https://stackoverflow.com/a/41205653/45708 but it creates an instance of my converter after the application configuration parameters have been processed.
I ran into this issue myself recently. From what I can tell, the key issue is that binding to configuration properties occurs very early in the Spring startup process, before the Application Context is fully initialized. Therefore the usual methods for registering a converter are not reliable. In fact the ConversionService used for configuration binding appear to be a one-off and not really connected to the ConversionService that is stored in the Application Context.
I was able to get something working but it feels like a hack, as it relies on internal implementation details that may work today but not tomorrow. In any case, this is the code I used:
((ApplicationConversionService) ApplicationConversionService.getSharedInstance()).addConverter(myCustomConverter);
The trick I found was to make sure this gets called as soon as possible at application startup so that it gets called before the configuration binding where it's needed. I put it in a #PostConstruct block inside my main #SpringBootApplication class as this seemed to get invoked early on, at least in my case.

Custom application property to be supplied to spring boot app through cmd line

I was wondering if we can supply a custom attribute (a key to be in application.properties file), I know for sure that -Dserver.port=8080 works, and overrides the property value, but server.port is a spring boot's expected property value.
How about something other than that, for example a jdbc connection string or service name? does -Ddb.service.name=dbservice work?
Yes, any property can be set via system property. You can use -D or -- notation. There are also a variety of property sources Spring Boot uses:
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html

Spring environment validation

We're building a Spring-based application which will be delivered to end users as a distribution package. Users are responsible for properly configuring whatever needs to be configured (it's mostly about various filesystem locations, folder access permissions, etc). There's a good idea to make the app help users understand what is not configured or which parts of configuration are invalid.
Our current approach is a custom ApplicationContextInitializer which does all the environment validation "manually" and then registers few "low level" beans in the application context explicitly. If something is wrong, initializer throws, exception is caught somewhere in main(), interpreted (converted into plain English) and then displayed.
While this approach works fine, I'm wondering if there are any best practices to minimize hand-written code and use Spring whenever possible.
Here's an illustrative example. The application requires a folder for file uploads. This means:
There should be a configuration file
This file should be accessible by the app
This file should have no syntax errors
This file should explicitly define some specific property (let it be app.uploads.folder)
This property should describe the existing filesystem entity
This entity should be a folder
The app should have read/write access to this folder
Does Spring provide any tools to implement this sort of validation easily?
Spring Boot has a nice feature for context and external configuration validation. If you define a POJO class and declare it as #ConfigurationProperties then Spring will bind the Environment (external properties and System/OS typically) to its properties using a DataBinder. E.g.
#ConfigurationProperties(name="app.uploads")
public class FileUploadProperties {
private File folder;
// getters and setters ommitted
}
will bind to app.uploads.folder and ensure that it is a File. For extra validation you can do it manually in the setter, or you can implement Validator in your FileUploadProperties or you can use JSR-303 annotations on the fields. By default an external property in app.uploads.* that doesn't bind will throw an exception (e.g. a mis-spelled property name, or a conversion/format error).
If you use Spring Boot Autoconfigure #EnableAutoConfigure you don't have to do anything else, but if it's just vanilla Spring (Boot) you need to say #EnableConfigurationProperties in your #Configuration somewhere as well.
A bonus feature: if you also use the Spring Boot Actuator you will also get JMX and HTTP support (in a webapp) for inspecting the bindable and bound properties of #ConfigurationProperties beans. The HTTP endpoint is "/configprops".

Custom error message for custom validation annotation

I got this problem, that I got from my friend a annotation code that checks if input data is proper VIN number. Annotation works fine, however when number is wrong it should render a default message:
String message() default "{validator.nrVINBad}";
I dont't know where to put this message, I tried my *.properties files but it's not that. Everywhere I look, there's always instructions how to make message from *.properties files, but as I know now, you can't put in those files error messages.
This is not part of JSF. This is part of Bean Validation (BV, also known as "JSR303"). Both JSF and BV are part of Java EE. JSF just happens to have builtin recognition and delegation for BV.
To localize BV messages, just follow the instructions in chapter 4.3.1.1 of JSR303 specification. In a nutshell, create a ValidationMessages.properties file in the classpath root (there where your Java source code also is, so that it ultimately ends up in /WEB-INF/classes) with he following content:
validator.nrVINBad = Your message here
See also:
Internationalization in JSF, when to use message-bundle and resource-bundle?

Accessing proper resource bundle in Spring Framework

I am trying to access a resource bundle using Spring framework (WebFlow). A messages.properties file and accordingly messages_ar_AE.properties file are kept in the classpath from where the Spring Framework access the resource bundle.
The code in invoked from a xhtml file using the JSTL resourceBundle attribute.
<myCustom:includedInSetValidator set="5.0, 5.0.1, 5.1"
validationMessage="#{resourceBundle['jboss.version.error']}" />
But irrespective of locale, the "#{resourceBundle['jboss.version.error']}" always fetches the default text, i.e; from English;
As I learned from some forums I got an hint that I need to handle this using LocaleChangeInterceptor or some other predefined classes. Once the Spring Locale is set, the proper resource bundle will be loaded by default, and hence solving my problem.
I need a way to change the Spring Framework Locale programatically to set the Locale. How do I achieve this programatically ?
Thanks.
Reached the solution for the problem.
Continuing from my question, when Spring Framework encounters a JSTL expression like "#{resourceBundle['jboss.version.error']}" by default it looks for message.properties file in the classpath, unless a resource bundle is defined explicitly.
When trying to fetch the proper resource bundle, the framework looks at the at the locale it is set to. As the locale of Spring Framework was not set in my case, it was not fetching me the expected resource bundle. Out of available options i chose Spring LocaleResolver
I modified existing JSF Custom ViewHandler in my application, where I added code to set the locale of Spring Framework.
public Locale calculateLocale(FacesContext arg0) {
HttpServletRequest request = (HttpServletRequest)arg0.getExternalContext().getRequest();
HttpServletResponse response = (HttpServletResponse)arg0.getExternalContext().getResponse();
LocaleResolver localeResolver = RequestContextUtils.getLocaleResolver(request);
localeResolver.setLocale(request, response, **setYourLocaleHere**);
}
The story just doesn't end here, setting the locale in locale resolver this way would throw the error:
Cannot change HTTP accept header – use a different locale resolution strategy
Refer Cannot change HTTP accept header error
To overcome this, one should include
<bean id="localeResolver"
class="org.springframework.web.servlet.i18n.SessionLocaleResolver">
<property name="defaultLocale" value="en" />
</bean>
in the Spring configuration file.
And now the desired locale of the Spring Framework is set.
There could possibly a better solution than what I did. One can also suggest their solutions if any.
Thanks.
You could do this multiple ways as outlined here in the doc.

Resources