I would like to set the Profile using application.properties file with the entry:
mode=master
How to set spring.profiles.active in my context.xml file? init-param works only in a web.xml context.
<init-param>
<param-name>spring.profiles.active</param-name>
<param-value>"${mode}"</param-value>
</init-param>
There are a few ways to change active profiles, none of which take directly from a properties file.
You can use the <init-param> as you are doing in your question.
You can provide a system parameter at application startup
-Dspring.profiles.active="master"
You can get the ConfigurableEnvironment from your ApplicationContext and setActiveProfiles(String...) programmatically with context.getEnvironment().setActiveProfiles("container");
You can use an ApplicationListener to listen to context initialization. Explanations on how to do that here. You can use a ContextStartedEvent
ContextStartedEvent event = ...; // from method argument
ConfigurableEnvironment env = (ConfigurableEnvironment) event.getApplicationContext().getEnvironment();
env.setActiveProfiles("master");
You can get the value "master" from a properties file as you see fit.
You can use either a environment variable, system variable (-D option for the JVM or application) or put it in JNDI (java:comp/env/. You cannot however put it in a properties file, as it is needed before the that specific properties file is read.
There is more information in the #Profile javadocs.
Another solution is to create your own ApplicationContextInitializer implementation which reads a certain file and activates the given profile.
You also can achieve this indirectly via System.setProperty:
// spring.profiles file: profile1,profile2
String anotherProfiles = Files.readString(Path.of("spring.profiles")); // or any other file
// Even some logic can be applied here to anotherProfiles
System.setProperty("spring.profiles.include", "dev," + anotherProfiles)
This sample can be rewritten a bit to read your application.properties file and take specified profiles for Spring.
Related
Can some one help me to understand this syntax on this ActiveMQConnectionFactory bean ? What are the 3 options for? what is the logic?
DU_MESSAGING_SERVER_URL (system param on our system)
MESSAGING_SERVER_URL (system param on our system)
tcp://localhost:61917
<property name="brokerURL" value="${DU_MESSAGING_SERVER_URL:${MESSAGING_SERVER_URL:tcp://localhost:61917}}"/>
This syntax using ${} is for loading system or environmental properties into a configuration file.
This is useful in situations where you might not want to modify the configuration file but rather just set a system property (e.g. moving between a test environment and prod). You just put the name of the system property in the configuration file and the value of that property will be substituted when the configuration is loaded. For example, you could use ${foo} in your config file and then define this system property -Dfoo=bar and then the value bar would be used in your config file.
The : character defines a default value if the system property is not set. For example, you could use ${foo:defaultFoo} in your config file and then if the foo system property was not defined then the value defaultFoo would be used in your config file.
In your situation these ideads are being nested together. So if you use ${DU_MESSAGING_SERVER_URL:${MESSAGING_SERVER_URL:tcp://localhost:61917}} then the value of the DU_MESSAGING_SERVER_URL system property will be used in the configuration. If DU_MESSAGING_SERVER_URL is not defined then ${MESSAGING_SERVER_URL:tcp://localhost:61917} will be evaluated which will use the value of the MESSAGING_SERVER_URL system property in the configuration. If MESSAGING_SERVER_URL is not defined then tcp://localhost:61917 will be used.
i've been working with Spring for some time and have a question regarding the very common configuration properties files (like the common application.properties that comes with every spring boot app you initialize). Recently, i also found that configurations like this can be done in yaml files. I have two questions:
When in a application.properties file, we write something like:
# application.properties
spring.debug = true
some-random-value = 15
does this mean that these values will be injected in the application context?
When we write something like:
# application.properties
spring.debug = true
does this mean, that somewhere, there is some class, that has an attribute that looks something like this? -->
#Component
class SomeClass{
#Value("spring.debug")
boolean shouldIRunInDebugMode;
...
}
2.a. If the answer to question 2 is yes, then how can I, looking at something like this:
# application.properties
spring.debug = true
find that class that is expecting that value. The same would apply to if i was looking at something like:
# application.yaml
someThidPartyLibraryName:
shouldWeLog: true
If i see a yaml configuration file, just looking at all the configuration there usually is not enough for me to know what is happening. How can i find the class that is being affected by this configuration, so that i can better understand what this config is doing?
Thank you!
The response is generally yes. If you declare a property in the application.properties or application.yaml is mainly, because you would use it later in the code, for example injecting in some bean with the support of #Value annotation. However, there are also many built-in properties (let's say for example server.port), which you usually don't have to declare and therefore you won't see explicitly in the code. Use an IDE to search the configuration properties and the manual to check the preconfigured ones in case of need.
Your understanding regarding spring value injections from application.properties is correct. #2 - is Yes. Any property from application.properties can be injected to any java class as #Value.
Regarding #2.a - Yaml is just another format on how you organize your variable hierarchy by indentations. That's a superset to the JSON structure.
For example,
in application.properties file you can add something like this
myapp.db.url=<dburl>
myapp.db.username=<dbuser>
myapp.db.password=<dbpassword>
the same can be represented in Yaml in a much efficient manner as below
myapp:
db:
url:<dburl>
username:<dbuser>
password:<dbpassword>
And in either case, for your Jave file you can inject as
#Value("myapp.db.url"
private String dbUrl;
Properties defined in yaml or a properties file may be accessed using the #Value annotation to inject, or using a #ConfigurationProperties class - see https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-features.html#boot-features-external-config-typesafe-configuration-properties for complete details.
Finding the property usage is supported by some IDEs - IntelliJ allows you to click through. Otherwise it's a search through the source. For #ConfigurationProperties, once you find the class then just look for code that calls its accessor methods.
Properties files and yaml files are used in Spring Boot for configurations. The main difference between the two is yaml provides structuring/grouping of configurations where as Properties are usually flat and may be repeating the same information:
For example;
Properties file
server.port = 8080
server.host = localhost
yaml file
server:
port: 8080
host: localhost
But in a Spring Boot AutoConfiguration class regardless of yaml or Properties used, a following looking ConfigurationProperties class will be used which will map server.port and server.host
#ConfigurationProperties(prefix = "server")
public class ServerConfiguration {
private int port;
private String host;
}
#Configuration
#EnableConfigurationProperties(ServerConfiguration.class)
public class ServerAutoConfiguration {
}
Hope this answers your questions.
I have a Spring 3.1 application. Let's say it has an XML with the following content:
<context:property-placeholder location="classpath:somename.properties" />
<context:property-placeholder location="classpath:xxx.properties" />
I would like some.properties to be always loaded (let's assume it exists), but the xxx part of the second place holder to be replaced by some name depending on the active profile. I've tried with this:
<beans profile="xx1">
<context:property-placeholder location="classpath:xx1.properties" />
</beans>
<beans profile="xx2">
<context:property-placeholder location="classpath:xx2.properties" />
</beans>
Also, both files have properties with the same key but different value.
But it didn't work as some later bean that has a placeholder for one property whose key is defined in xx1.properties (and xx2.properties) makes Spring complain that the key is not found in the application context.
You can do:
<context:property-placeholder location="classpath:${spring.profiles.active}.properties" />
It works fine, but is perhaps not adapted when using multiple profiles in the same time.
When declaring 2 property placeholders, if the 1st one does not contain all the applications keys, you should put the attribute ignoring unresolvable = true, so that the 2nd placeholder can be used.
I'm not sure if it is what you want to do, it may if you want both xx1 and xx2 profiles be active in the same time.
Note that declaring 2 propertyplaceholders like that make them independant, and in the declaration of xx2.properties, you can't reuse the values of xx1.properties.
If you need something more advanced, you can register your PropertySources on application startup.
web.xml
<context-param>
<param-name>contextInitializerClasses</param-name>
<param-value>com.xxx.core.spring.properties.PropertySourcesApplicationContextInitializer</param-value>
</context-param>
file you create:
public class PropertySourcesApplicationContextInitializer implements ApplicationContextInitializer<ConfigurableApplicationContext> {
private static final Logger LOGGER = LoggerFactory.getLogger(PropertySourcesApplicationContextInitializer.class);
#Override
public void initialize(ConfigurableApplicationContext applicationContext) {
LOGGER.info("Adding some additional property sources");
String profile = System.getProperty("spring.profiles.active");
// ... Add property sources according to selected spring profile
// (note there already are some property sources registered, system properties etc)
applicationContext.getEnvironment().getPropertySources().addLast(myPropertySource);
}
}
Once you've done it you just need to add in your context:
<context:property-placeholder/>
Imho it's the best way to deal with spring properties, because you do not declare local properties everywhere anymore, you have a programmatic control of what is happening, and property source xx1 values can be used in xx2.properties.
At work we are using it and it works nicely. We register 3 additional property sources:
- Infrastructure: provided by Puppet
- Profile: a different property loaded according to the profile.
- Common: contains values as default, when all profiles share the same value etc...
I have decided to submit and answer to this as it has not yet been accepted. It may not be what you are looking for specifically but it works for me. Also note that i am using the new annotation driven configuration however it can be ported to the xml config.
I have a properties file for each environment(dev.properties, test.properties etc)
I then have a RootConfig class that is the class that is used for all the configuration. All that this class has in it is two annotations: #Configuration and #ComponentScan(basePackageClasses=RootConfig.class).
This tells it to scan for anything in the same package as it.
There is then a Configuration Containing all my normal configuration sitting wherever. There is also a configuration for each environment in the same package as the root configuration class above.
The environment specific configurations are simply marker classes that have the following annotations to point it to the environment specific properties files:
#Configuration
#PropertySource("classpath:dev.properties")
#Import(NormalConfig.class)
#Profile("dev")
The import tells it to bring in the normal config class. But when it gets in there it will have the environment specific properties set.
If I have system property which I pass my container (e.g. Tomcat) like the following:
-Dmy.property=myValueOne
and a property with the same key defined in my web.xml:
<context-param>
<param-name>my.property</param-name>
<param-value>myValueTwo</param-value>
</context-param>
... and a property with the same key defined in one of my config*.properties files:
my.property=myValueThree
Which value will this property have?
myValueOne, myValueTwo or myValueThree?
If you have several properties with the same key, is there a hierarchy which defines which kind of property overwrites which other kind of property?
Simply said all three will be available and you can use SpEL to obtain the value of each.
#{systemProperties['my.property']} // myValueOne
#{servletContextInitParams['my.property'] // myValueTwo
The properties depend on how you are loading them (a #PropertySource or `
However you probably want to know what happens if you use a placeholder and you have the situation you have.
<property name="myProperty" value="${my.property}" />
Assuming you use the default (and are on Spring 3.1 or up) the following resources are consulted in order, in a web based environment.
Property Files
ServletConfig Init Params (
ServletContext Init Params
Jndi
System Properties (specified by -D)
Environment Properties
So in your case the ${my.property} will resolve to myValueThree. That is if you preserve the defaults. If you specify local-override="true" the property files are consulted last and the value would be myValueTwo.
Links
StandardServletEnvironment javadoc
StandardEnvironment javadoc
PropertySourcesPlaceholderConfigurer javadoc
predhme
You came up with a way to read environment variable into a Spring Bean then "was able to then pass that into the FileSystemResource".
Here:
Can I use an Environment variable based location for Spring FileSystemResource?
Could you please explain how you passed the variable to FileSystemResource?
Thanks!
Charlie
You want to use a PropertyPlaceholderConfigurer.
Once you have that set up, you should be able to pull any environment variable with the:
${variableName}
syntax anywhere in your configuration file.
I don't like the idea of having system properties for individual variables like these. Sooner you might turn into hundreds of system properties that might need to be set. Instead as others suggest, have the property file outside of the build and specify the location of the property file as a system property.
Having the properties that change with environment, in a properties file outside of the build (JAR / WAR..) helps a lot in making good builds.
This blog post might help.
Or something similar as below:
Using a property placeholder configurer
<bean id="myConfigPlaceholder"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"
p:location="${my.sys.variable}/fooModule/foo.properties"
p:placeholderPrefix="#foo{"
p:placeholderSuffix="}" />
Injecting in beans
#Value("#foo{some.key.defined.in.fooPropertiesFile}")
String myFileSystemResourcePath;
(or)
Using util:properties
<util:properties id="fooProps"
location="file:///${my.sys.variable}/fooModule.properties/>
Injecting in beans
#Value("#fooProps[some.key.defined.in.fooPropertiesFile]")
String myFileSystemResourcePath;
Note: When defining property-placeholder-configurer bean, there are different syntactic variations that are supported. You might choose any. Also instead of injecting with #Value, you can reference the property in the xml file with ${variableName} as dlawrence suggested.
Setting the environment variable
for one project:
Setting the envVariable, in this example my.sys.variable can be just done with
project-->(right click)-->run as-->run as configurations-->vm arguments
and there: -Dmy.sys.variable=file:///D:/myBaseDir
globally as a preference:
If this envProp is to be shared with different projects in eclipse, then you can do
Windows->Preferences->Java->Installed JREs->(select the jre)->edit->default vm arguments->and set it with something like -Dmy.sys.variable=file:///D:/myBaseDir