We Keep Coding

How to configure the Spring java environment without the locations configuration property?

I am creating a class called FileConfig with the following annotation:
#ConfigurationProperties(locations = { "classpath:application.properties" , "${file.config.location}" })
The following line exists within 'application.properties':
file.config.location = fileinfo.yaml
Apparently, my compiler says, that the locations property has deprecated in favor of configuring the environment directly with additional locations. Can someone please help me how to configure the environment so that the variables in FileConfig are initialized using the contents of 'fileinfo.yaml' file
Using #PropertySource("classpath:testapplication.properties") instead of using the above line of code produces an error.

If I understand your question correctly, you specify the location of fileInfo.yaml file in your application.properties file. And this value should be set as location of your property class FileConfig.
I think thats not possible because SpEL expressions are not evaluated.
Here the part of the java doc from #ConfigurationProperties:
Annotation for externalized configuration. Add this to a class definition or a #Bean method in a #Configuration class if you want to bind and validate some external Properties (e.g. from a .properties file).
Note that contrary to #Value, SpEL expressions are not evaluated since
property values are externalized.

Unable to resolve property placeholder [duplicate]

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.

Precedence of properties: system vs. deployment descriptor vs. properties file

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

Spring Property Placeholders with String Concatenation

My problem looks simple but I'm not able to resolve it. I have a properties file which contains configuration details of all environments (dev, qa, prod).
Example config.properties:
dev.maxLength=2000
qa.maxLength=4000
We have a parent Properties file which holds the host name, environment mappings.
Example hosts.properties:
host1=dev
host2=qa
The property name host1 is stored in a bean hostname.
<bean id="hostname"
factory-bean="localhostInetAddress"
factory-method="getHostName"/>
To resolve the config properties name I have to join the strings as follows,
${${**hostname**}.maxLength} which should be resolved as ${dev.maxLength}
I tried using SpEL with no success. I am getting Could not resolve placeholder Exception. How can I concatenate a bean value in property place holder? How are dynamic property names constructed?
Spring version 3.2

To concatenate the values parsed from Spring property placeholders, you need to escape their values using single quoutes ('') and wrap the placeholder expressions by a SpEL expression using #{}.
<bean id="myService" class=""com.services.MyService">
...
<property name="endpointAddress" value="#{'${server}' + ':' + '${port}' + '${endpoint}'}" />
</bean>
where:
server = http://domain.host.com
port = 7777
endpoint = /services/myservice
The result would be:
http://domain.host.com:7777/services/myservice

I solved the issue by changing PropertyPlaceholderConfigurer beans to Properties.
<util:properties/> are accessible in SpEL.
Example:
"#{prop[host+'.'+'maxLength']}"
where host is a string bean.

It would be better to have environment specific properties in a file of its own and use Spring Profiles.
For example, I have four xml files just for db configuration, local.db.xml, dev.db.xml, qa.db.xml and prod.db.xml.
Inside each db.xml, I set the profile to the appropriate value.
My local.db.xml has
<beans profile="db.local" .. >
For starting Tomcat, I specify the VM options as follows
-Dspring.profiles.active=db.local

How do you pass a variable into the FileSystemResource?

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