I tried all ways to find a file and always got this exception:
java.io.FileNotFoundException: class path resource [src/main/resources/sport.properties] cannot be opened because it does not exist
This is my folder structure:
What path in this String is correct? #PropertySource("classpath:/src/main/resources/sport.properties")
What path in this String is correct? #PropertySource("classpath:/src/main/resources/sport.properties")
That is incorrect because you are mixing up two "name spaces".
The string "classpath:/src/main/resources/sport.properties" is a URI.
The "classpath" means you are telling Spring to look on the application's runtime classpath.
But "/src/main/resources/sport.properties" is not a name on the runtime classpath. Rather it is a pathname in the file system relative to the Eclipse project directory.
Since you are using Maven with Eclipse, you need to understand that the resources tree(s) get added to your classpath; i.e. "${MAVEN_PROJECT}/src/main/resources/a/b" becomes "/a/b" on the runtime classpath.
The "${MAVEN_PROJECT}/src/main/resources" directories for all Maven projects that make up your app are added to the classpath in this way.
When unit testing, "${MAVEN_PROJECT}/src/test/resources" directories get added ro the classpath as well.
In short, you should probably use #PropertySource("classpath:/sport.properties")
I would suggest using TestPropertySource as mentioned below for integration tests.
#RunWith(SpringRunner.class)
#ContextConfiguration(locations = "/applicationContext.xml")
#TestPropertySource(locations = "/sport.properties")
#TestPropertySource is a class-level annotation that is used to
configure the locations() of properties files and inlined properties()
to be added to the Environment's set of PropertySources for an
ApplicationContext for integration tests.
Precedence:- Test property sources have higher precedence than those
loaded from the operating system's environment or Java system
properties as well as property sources added by the application
declaratively via #PropertySource or programmatically (e.g., via an
ApplicationContextInitializer or some other means). Thus, test
property sources can be used to selectively override properties
defined in system and application property sources. Furthermore,
inlined properties() have higher precedence than properties loaded
from resource locations().
Related
In which class in the source code of spring-boot or spring is the application.yml file or application.properties processed?
For spring boot (version 2.x) the application properties are loaded from the environment into the context via a PropertySourceLoader.
In for example the spring-boot-2.6.3.jar we can find the following file:
META-INF/spring.factories
# PropertySource Loaders
org.springframework.boot.env.PropertySourceLoader=\
org.springframework.boot.env.PropertiesPropertySourceLoader,\
org.springframework.boot.env.YamlPropertySourceLoader
Where PropertiesPropertySourceLoader loads .properties and .xml files, and YamlPropertySourceLoader loads .yml and .yaml.
These are loaded with the SpringFactoriesLoader, which we can see in action in org.springframework.boot.context.config.ConfigFileApplicationListener (deprecated) or org.springframework.boot.context.config.StandardConfigDataLocationResolver (via ConfigDataEnvironmentPostProcessor -> ConfigDataEnvironment -> ConfigDataLocationResolvers) :
this.propertySourceLoaders = SpringFactoriesLoader.loadFactories(PropertySourceLoader.class,
getClass().getClassLoader());
You can read in the ConfigFileApplicationListener JavaDoc that the properties are indeed loaded with this class:
EnvironmentPostProcessor that configures the context environment by loading properties from well known file locations. By default properties will be loaded from 'application.properties' and/or 'application.yml' files in the following locations:
file:./config/
file:./config/*/
file:./
classpath:config/
classpath:
...
If you're interested in context loading from the environment in spring(boot), I suggest you setup your project with maven, download the sources jars, and have a look around in the mentioned factories file. You will find more relevant code in the org.springframework.boot.env and org.springframework.boot.context (config and properties) packages.
You can find your application.yml or application.properties at the src/main/resources. You can have as many as possible configurations for your spring boot application for every case. Lets assume that you have 3 local-profiles like demo, production and server, so you made 3 configuration and assumingyou set for active profile the demo at the application.yml . I hope you get the idea. Its the first thing that actually is running before the springboot is up.
Please look the officials docs !
Coming from Play Framework, a handy feature that has helped to organize the application configurations was to use includes (Link) to spilt the various configurations into multiple .conf files as below.
application.conf Content
include "play-http.conf"
include "play-modules.conf"
include "play-i18n.conf"
include "authentication.conf"
include "hbase.conf"
include "custom-caches.conf"
include "custom-filters.conf"
#Any other root level application configurations
Is there an equivalent to this in Spring Boot .properties files?
From Spring 2.4, we can create multiple properties file for each profiles as below.
application-main1.properties
application-sub1.properties
application-sub2.properties
And then in default application.properties file we can group all sub profiles and activate the main profile
spring.profiles.group.main1=sub1,sub2
spring.profiles.active=main1
I am not sure if we can group sub profiles under default profile. You can try out
spring.profiles.group.default=sub1,sub2
This way you don't need to have another file for main profile.
I use yaml configuration files myself but I think that the configuration is mostly similar. You should take a look at the PropertySourcesPlaceholderConfigurer.
I have defined a PropertySourcesPlaceholderConfigurer bean to use a configuration override file located outside of the jar. Anything that is in the override file will be used instead of the default configuration. Anything that is not in the override file is still retrieved from the default configuration file. I think you can create a similar bean to achieve what you are looking for.
Here's my code:
#Bean
static PropertySourcesPlaceholderConfigurer propertySourcesPlaceholderConfigurer() {
var properties = new PropertySourcesPlaceholderConfigurer();
properties.setLocation(new FileSystemResource("./application.yaml"));
properties.setIgnoreResourceNotFound(true);
return properties;
}
For my use case, I only needed to define one properties location, but it is also possible to specify multiple locations:
...
properties.setLocations(Resource... locations);
...
My requirement was simply achieved using the spring.config.import (Link).
I created multiple property files such as hbase.properties, custom-caches.properties etc. And then in my application.properties imported those additional property files as below.
spring.config.import=hbase.properties,custom-caches.properties
#Any other properties in the application.properties file
Thanks
I am setting the logging.file.name in application.properties file which I want to pass as command line argument. Is it possible?
The reason is I am trying to run multiple jar files from a single application and I want to display logs of each application run at a single location.
Spring Boot provides several options to externalize configuration.
Spring Boot uses a very particular PropertySource order that is
designed to allow sensible overriding of values. Properties are
considered in the following order (with values from lower items
overriding earlier ones):
Default properties (specified by setting SpringApplication.setDefaultProperties).
#PropertySource annotations on your #Configuration classes. Please note that such property sources are not added to the
Environment until the application context is being refreshed. This is
too late to configure certain properties such as logging.* and
spring.main.* which are read before refresh begins.
Config data (such as application.properties files).
A RandomValuePropertySource that has properties only in random.*.
OS environment variables.
Java System properties (System.getProperties()).
JNDI attributes from java:comp/env.
ServletContext init parameters.
ServletConfig init parameters.
Properties from SPRING_APPLICATION_JSON (inline JSON embedded in an environment variable or system property).
Command line arguments.
properties attribute on your tests. Available on #SpringBootTest and the test annotations for testing a particular
slice of your application.
#TestPropertySource annotations on your tests.
Devtools global settings properties in the $HOME/.config/spring-boot directory when devtools is active.
So you should be possible to override the values defined in your application.properties by setting environment variables, Java system properties, or command line arguments:
Environmant variables: export LOGGING_FILE_NAME=yourfile.txt
Java system property: -Dlogging.file.name=yourfile.txt
Command line argument: --logging.file.name=yourfile.txt
In Karaf, is there a way for a bundle to read a properties file from another bundle?
I have bundle1, which contains some classes that bundle2 uses (bundle1 exports the package containing those classes in its maven pom via maven-bundle-plugin and bundle2 imports it). But bundle2 also needs to use a properties file from bundle1. Is there a way that in addition to classes, bundle2 can access a file from bundle1?
From what I've read, one option is to deploy the properties to the karaf etc folder via the features file and then it can be accessed from bundle2 via blueprint. I would like to avoid that if possible, as bundle1 is currently not deployed as a feature. So hoping for an alternate approach.
The nicest way is to wrap the access through a class of bundle1. Assume bundle1 contains a class named MyClass. Inside this class you can do this.getClass().getResourceAsStream(path). The path is relative to the package of the class.
So a method of this class could return an Inputstream for the properties file or allow access to the actual properties.
In fact you can also access the properties file from bundle2. Simply use MyClass.getResourceAsStream(path) from a class in bundle2. This works as each class is by default loaded by the classloader of the bundle it resides in.
I'm probably thinking about this incorrectly, but here's what I'm up against:
I'm injecting Spring Resource objects into my app that give me the location of security certificates, for example:<property name="certificateResource" value="SomeCert.p12" /> where certificateResource is of type org.springframework.core.io.Resource
Running under JUnit the Resource is a classpath resource and everything is fine. When deployed as a war under Tomcat the the Resource is in a Servlet Context and requires WEB-INF/classes/ prepended to the certificate.
I've tried a number of Resource prefix and wildcard combinations but can't come-up with a single string that satisfies both contexts. So far the "solution" is to override the bean definition in src/test/resources/test-applicationContext.xml but that means maintaining the strings in two locations.
Any pointers to better solutions would be appreciated, thanks.
I have tried to make a small but descriptive application using spring-test and spring-webmvc and using resources referenced in xml configs while these xml's are reused by production and testing spring configurations. Here is what I recieved: github.com/isopov/spring-resource-test
The central is the referencing of the prodcution xml config from the testing config:
<import resource="file:src/main/webapp/WEB-INF/applicationContext.xml" />
it is also possible to not import one xml from the other, but give each test several configs:
#ContextConfiguration(locations = { "classpath:test-applicationContext.xml",
"file:src/main/webapp/WEB-INF/applicationContext.xml" })
the resource itself resides in src/main/resources (I assumed you are using Maven or something derived from the "Standard Directory Layout") so is always accessible with "classpath:hello.txt" from any spring config.
I tested this with maven build, as web-application and running UTs inside Eclipse.