Am looking to pass variables at run time once war file is deployed on tomcat ..
How can i use application.properties whcih is in classplath along with another properties file ex. abcd.properties located at particular directory..Am basically looking to set additional classpath and read value from properties file in that path along with default classpath location for war deployment.
Am using Spring boot .One of the way is to pass all properties to database end , but am looking for a file based i.e properties based workout.
(Having multiple applications on same tomcat instance.)
Spring Boot App --> run as --> run configurations. Now here in VM arguments add Dproperties.location="Path of the properties".
Now, in your Spring Boot application use the annotation #PropertySource("file:${properties.location}/propertiesfileName.properties") just above the class declaration.
Autowire Environment in your class. use env.getProperty("propertyname").
You can access the values from application.properties as usual using #Value annotation. Hope this helps.
Related
I need to create multiple context for the same application context.xml file and each context use its own application.properties.
How to do it using spring boot ?
I have 3 clients who have the same behaviour but each one with specific details declared into client-application.properties.
So i use also spring integration and the flow will be reused for each client .
I need to launch 3 clients in the same time and each one with its own application.properties. And i use xml for that.
Take a look at this... I have a single project, and inside of it are three application.properties (or the number you need)
in application.properties, i specify general parameters
and in each application-.properties i specify specific environment properties, e.g., the port in production:
And the port for my dev profile:
In order to use them check the documentation that Ivaylo recommended
...A small example:
In this case, the application will boot on the port showed in the different .properties files.
You can specify the profile like: mvn spring:boot run -Dspring.profiles.active=dev
Having something like
security.user.password = plainTextPassword
inside Spring Boot’s application.properties is obviously an anti-pattern as it prevents the code from being pushed to a public SCM. In my non-Spring Boot projects I use
security.user.password = ${myPasswordFromMavenSettingsXML}
and put a corresponding <properties/> reference inside my pom.xml.
Using Maven’s resource filter plugin the passwords are replaced at build time so the application have access to actual plain text passwords after it has been build and deployed.
For some reason Maven’s resource filter plugin does not work in this case. Is there a way to not commit plain text passwords to an SCM and let Spring Boot to insert them at build time?
Spring boot has multiple mechanisms to provided externalized configuration. Some examples are command line arguments, environment variables and also application properties outside of your packaged JAR.
What I usually do:
Locally we configured several environment variables. Most (if not all) IDE's allow you to configure environment variables from within the run configuration.
For example if you don't want to expose the spring.datasource.password property you could set an environment variable called SPRING_DATASOURCE_PASSWORD.
When we deploy on another environment, we usually choose to add another application.properties or application.yml file within the same folder as the application JAR/WAR, since Spring boot picks that up as well.
Another solution is to use Spring cloud since it has a config service which can be used as a microservice to provide configuration. The configuration can be versioned using SCM as well, but you can put it on a separate system that is not connected to your source code.
we put properties in a specific place(kept by zooKeeper, and already parsed into spring), not in classpath. Now in logback.xml, I need a DBAppender to log messages into mysql, I don't want to copy a properties into classpath, and I try to use placeholder ${url} directly without importing properties in logback.xml, it does not work.
So is there a way to use configuration in spring for logback?
No logback can only access system properties. And also logback tends to be intialised before spring, although you can cause it to be reconfigured.
Have a look at how spring-boot does it. It copies some (about 3 or 4) properties from spring config into system properties before re-initialising logback. In this way the log file path can be interpolated via spring properties and variable replacement.
We are using spring boot in a multi-module project.
We have a Domain access module which has the common domain object classes, repositories, together with configuration for the datasource, JPA, Hibernate, etc. These are configured using a application.properties. We put all this configuration into the common module to save duplicating these common configurations in the higher level modules.
This all works fine when building the domain module, so the configurations are loaded correctly in the test units.
However the problems start when we try to use the domain module in the higher layer modules; they have their own application.properties which means Spring loads them and not the the Domain module application.properties, which this means the data source is not configured because only the higher module application.properties are loaded.
What we would like is both the domain module and higher level application properties to be loaded by Spring. But we can't see any easy way to do this.
I'm thinking this must be a common problem, and wonder if there any recommended solutions for this problem?
As we are using spring-boot the solution should ideally use annotations instead of applictionContext.xml.
Maybe you should only use application.properties in the top-level aggregator project?
You can always use #PropertySource in the child projects to configure them with a name that is specific to their use case.
Or you can use different names for each project and glue them together in the top-level project using spring.config.location (comma-separated).
I agree with #Dave Syer. The idea of splitting an application into multiple modules is that each of those is an independent unit, in this case a jar file. Theoretically you could split each of those jar files into their own source repositories, and then use them across multiple projects. Let's say you want to reuse these domain classes in both a web and batch application, if all the APPLICATION level configuration is stored within each of the individual modules, it severely reduces their reusability.
IMO only the aggregating module should contain all of the configuration necessary to run as an application, everything else is simply a dependency that can be remixed and reused as necessary.
Maybe another approach could be to define specific profiles for each module and use the application.properties file just to specify which profiles are active
using the spring.profiles.include property.
domain-module
- application.properties
- application-domain.properties
app-module
- application.properties
- application-app.properties
and into the application.properties file of app-module
spring.profiles.include=domain,app
Another thing you can do (besides only using application.properties at the top-level as Dave Syer mentions) is to name the properties file of the domain module something like domainConfig.properties.
That way you avoid the name clash with application.properties.
domainConfig.properties would contain all the data needed for the domain module to be able to tested on it's own. The integration with the rest of the code can easily be done either using multiple #PropertySource (one for domainConfig.properties and one for application.properties) or configuring a PropertySourcesPlaceholderConfigurer bean in your Java Config (check out this tutorial) that refers to all the needed property files
in spring-boot since 2.4 support spring.config.import
e.g
application.name=myapp
spring.config.import=developer.properties
# import from other module
spring.config.import=classpath:application-common.properties
or with spring.config.activate.on-profile
spring.config.activate.on-profile=prod
spring.config.import=prod.properties
ref: https://spring.io/blog/2020/08/14/config-file-processing-in-spring-boot-2-4
Is there a way to use Spring 3 property place holder to load application specific properties without conflicting with other applications within the same tomcat/jvm ?
All of your application specific properties are residing inside your jar and tomcat will only make them available to your application.
Just put them under webapps/${app_war}/WEB-INF/classes/app.properties and your spring config will pick them up from classpath.
System properties via -D startup parameters are shared, but not application specific.