I know that by default a Spring application will look for message files containing internationalization keys and values in the src/main/resources folder. What is the best way to specify an alternate location for these message files (i.e. other than src/main/resources)?
The more simple way to achieve this is to use in your properties file: spring.messages.basename,
There is another more complicated way is to define your own Bean of type: MessageSource.
Of course, the first way should be the one to use.
Related
New to Spring Boot here, long-time Spring Framework user though.
I'm looking for a way to split my externalised configuration into multiple .properties files, for better readability and manageability.
I already saw this SO answer: having the ability to specify a list of configuration file names in spring.config.name (which, by the way, doesn't seem to be mentioned in Boot reference documentation, correct me if I'm wrong) would solve my problem perfectly, however that configuration property can be specified only via system properties or environment variables. If I try to specify it inside my application.properties file, it gets ignored. The same happens for spring.config.additional-location. I understand this happens because, when application.properties is read, it's too late to tell Spring Boot to search for different externalised configuration file names. However this is not a proper solution, because the way I split my configuration should be an "implementation detail" that the consumer of my application shouldn't be aware of, so I don't expect the consumer to specify an external parameter otherwise my application breaks out-of-the-box.
I think that a way to do this should be provided. Perhaps some import mechanism for .properties files or the ability to specify spring.config.name even in application.properties (some known and reasonable limitations would be acceptable).
The best I could find out is to use #PropertySource, but this is not profile aware: unless you use some ugly nested class hack, or you put spring.profiles.active variable in the resource name (which will break if multiple profiles have been activated), you won't get the benefit you have for application.properties profile-specific files.
I was not able to find an "official way" to do this, apart from some statements from Spring Boot devs that say that they're rather promoting the use of a single (possibly giant...) externalised configuration file. It seems like this position is not so popular, judging from the post reactions on GitHub, and IMHO it really seems to be a basic feature missing. I have been working with multiple properties files in Spring Framework (using XML configuration) for years and I never felt that having an only huge file would have been better.
If I understand it right, in Boot 1.x this was in some way possible using the location attribute of #ConfigurationProperties, which is however missing in Boot 2.x.
Any suggestion?
Have you tried with Spring Profile?
What you can do is create application-file1.properties/yml, application-file2.properties/yml and put it in config location and then add spring.profile.active=<your env profiles>,file1,file2.
It will load the files.
This profile entry can be in bootstrap.yml, or JVM args to application, in Manifest-<env>.yml in case of Pivotal Cloud Foundry. Not sure on AWS and other cloud provider.
Hope this will help.
I have a Spring Boot property source file containing a set of arbitrary properties. I would like to get all of those properties and add them to the environment.
I tried injecting the Environment into the class, and I am able to use that to get known properties. But I am not sure how to get all properties from there.'
If course I can use a traditional Properties.load() but is there a Spring way to do that?
Have you tried #PropertySource anotation?
I wouldn't recommend using PropertySource because you can't configure the precedence of the properties that you add. You may want that these properties can be overridden in some way, maybe? Or you may want that these properties take precedence over others. For this, I recommend you implement an EnvironmentPostProcessor.
There is a sample in this university session at Devoxx where we showcase how to read a file from the home directory and add it after command line properties. You could do pretty much the same thing and order them the way you want.
The sample app is available here if you want to give that a try.
If you put your properties into the "application.properties" (or any of the other places described here), the properties are automatically available in Spring's Environment.
One way to access the properties then is simply to #Autowire the Environment into the class where you want to access it.
I have a Spring (3.1.) app that has a large app-context.xml file. There is a second very small stand-alone application that needs just a few parameters from one of the beans that are configured in that xml file.
Rather than that little application instantiating the whole application context (which builds a lot of connections, etc), I just want to read in the couple of configuration parameters that are contained in that file.
I could of course create a new smaller small-app-context.xml that only has the configuration i need or put those parameters in a properties file, but then I need to maintain that information in two places, which I am trying to avoid. I know I could read in and parse the raw XML file (not exactly sure the most efficient way to do that). However, I was hoping that Spring provides a nice way to do this but I haven't found it.
Does Spring provide a clean way to do this?
Thanks.
In Spring you can have multiple configuration files. So for the part that you would like to reuse you would create a smaller, self-contained config file. It can remain in the original project and your app-context.xml can include it. Then your new, small project could include the small config xml and you wouldn't need to maintain the information in two locations.
I could of course create a new smaller small-app-context.xml that only has the configuration i need or put those parameters in a properties file
I would agree that configuration belongs in a properties file. Not the application context file. You should not be maintaining the configuration in two places. You should have the configuration once in your properties file and then make that available to any contexts which require it.
When I open a Spring configuration files at my application on Intellij IDEA sometimes it says
File Set Not Configured For The File
and gives me a link
Configure File Set
When I click it it says:
MVC dispatcher servlet
Create New File Set
or opens a new window cnd let me check some files.
What happens when I click them and what is this for? I click MVC dispatcher Servlet and check the code but doesn't see any changes.
What it is for?
this is for IDEA to help you out with dependencies between different files.
For example you have "service-spring-config.xml" and "mvc-spring-config.xml", where the MVC config uses some beans from the Service config. If you add these both files to the "File Set", IDEA will know that these two files represent a single application context.
By knowing that, it will help you autocomplete beans in XML + will inform you if something is not resolvable without you having to actually run the app.
I click MVC dispatcher Servlet and check the code but don't see any changes
This is because you only have a single file (for now). Later on, you can add some other configs that use/reference beans from each other => then it'll become REALLY helpful
From IDEA File Sets documentation:
By combining Spring XML configuration files in a file set you tell IntelliJ IDEA that these files are mutually related. In this way you form a common editing context for these configuration files and get all the associated coding assistance.
Spring file sets on IntelliJ are for grouping related files.
IntelliJ could autodetect some of this groups, for example files that are loaded with ContextLoaderListener on web.xml or default files for DispatcherServlet (That seems to be your case)
When IntelliJ asks to configure a File Set for a Spring file, is 'cause IntelliJ couldn't detect a default way to include in a group, for example files that are loaded within the ApplicationContext's constructor Ex:
new ClasspathXmlApplicationContext("somefile.xml","anotherfile.xml");
When file sets are correctly configured IntelliJ could bring many goodies like auto-complete, navigation, validation, dependency graphs and others
our web application uses Spring 2.5. It consists of several modules, each of which can bring additional Spring context files, which are loaded automatically (into one application context). We want to let each module provide additional resource bundles (for I18N support).
Spring supports internationalization by registering a bean with name messageSource in the configuration file, but this assumes I know exactly what is the fully qualified name of the class or properties file that contained the translates strings. This is a problem because other modules might have their own properties files put in a different location. So I'm looking for a way to let each module define its own messageSource with its own resource bundles and I don't know how to do it.
Does anybody know the solution to this problem?
Thanks.
I have used the Message Sources in Spring for some i18n support. In my case I only needed one so it was easy to inject the one message source I needed into the service bean that I was creating.
I was hoping to see something like what I will propose later on in the Spring sources itself. But I don't see anything that will aggregate heterogeneous message sources. If all of them will be parts of a resource bundle like property files, I'm sure you could write a wrapper for ResourceBundleMessageSource that could be dynamically updated as beans were registered.
However, if you wanted to aggregate heterogeneous MessageSources, this is what I would suggest. Create an message source aggregating bean that upon loading asks the ApplicationContext for beans of type MessageSource.class. This aggregating bean can then let each source attempt to resolve the key and format the message. Depending on how many files/msg source classes you have you may want to allow the aggregating implementation to prioritize which ones it attempts to use first. If performance becomes a problem, you could also cache which source resolved which keys so that the aggregator doesn't have to guess each time.