I am setting properties using:
<context:property-placeholder location="#{ T(System).getenv().get('DEV_PROPERTIES') ?: 'classpath:/META-INF/properties/config.properties' }"/>
I am able to access the properties:
#Value("${hostname}")
String hostname;`
This works fine.
However, i would like to access the properties using the property map or simple just get the values in a method which can't use #Value variables. Is there a way i can inject the property bean set using <context:property-placeholder />.?
Environment doesn't have the access to properties set from the properties file, it only can read properties from system and environment properties.
No you cannot access the properties used internally by the property-placeholder. What you can do is load the properties into a Properties object and inject that into the property-placeholder and also inject it into whatever you like.
Another tip you don't need to use SpEL to achieve what you want in your location attribute, a simple placeholder would do the trick.
To load a properties object use the util namespace.
<util:properties id="props" location="${DEV_PROPERTIES:classpath:/META-INF/properties/config.properties}" />
<context:property-placeholder properties-ref="props" />
To make the properties you want available to the Environment you should use the #PropertySource annotation on a #Configuration class.
#Configuration
#PropertySource("${DEV_PROPERTIES:classpath:/META-INF/properties/config.properties}")
public class ApplicationConfig { ... }
You can either add this as a bean to your xml file or have it detected while component scanning. Either way should work.
Related
I am using spring. I know how to use properties data inside a class but I need to know how to give component name from the properties file.
#Component("componentName") // here I need to give my property instead of "componentName".
public class TestClass {
}
I do search abt it but not able to find sos! Please help me...
I'm afraid that is not possible. All names that is given to #Controller, #Service and so on requires to be final/constant.
If you can use additional XML config, use alias directive as explained in this other question:
<beans>
<alias name="${service.class}" alias="Service"/>
<context:property-placeholder location="example/app.properties"/>
<context:component-scan base-package="example"/>
<beans>
If you need to use java config only, there's an open issue about it here. It is still unresolved, so for strictly java config the same is not currently possible.
If that's a problem, you can also register a bean programmatically as detailed here. So you'd autowire a property and your target bean, implement BeanDefinitionRegistryPostProcessor and register your bean in the registry you get as a parameter using your property.
I'm not sure if I understand correctly, from Spring 3 or up, you can use
#PropertySource annotation to externalize your configuration to a properties file. And then display the values with #Value
If you are talking about distinguishing configuration beans, #Qualifier is the thing you are looking for
I am doing this..
AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
XmlBeanDefinitionReader xmlReader = new XmlBeanDefinitionReader(context);
xmlReader
.loadBeanDefinitions(new ClassPathResource("SpringConfig.xml"));
PropertySourcesPlaceholderConfigurer propertyHolder = new PropertySourcesPlaceholderConfigurer();
propertyHolder.setLocation(new ClassPathResource(
"SpringConfig.properties"));
context.addBeanFactoryPostProcessor(propertyHolder);
......
context.refresh();
Now in my #Configuration files, the properties present in my SpringConfig.properties are not getting picked up if I do this...
#Autowired
private Environment env
.....
env.getProperty("my.property")
But I get that property if I use
#Value("${my.property}")
private String myProperty;
I even tried adding couple of more lines like this, but of no use.
ConfigurableEnvironment env = new StandardEnvironment();
propertyHolder.setEnvironment(env);
Does anybody know why my properties are not loaded into Environment? Thanks.
PropertySourcesPlaceholderConfigurer reads property files directly(as it was done by PropertyPlaceholderConfigurer in Spring 3.0 times), it's just a postprocessor which does not change the way properties are used in the Spring context - in this case properties are only available as bean definition placeholders.
It's the PropertySourcesPlaceholderConfigurer who uses Environment and not vice versa.
Property sources framework works on the application context level, while property placeholder configurers only provide the functionality to process placeholders in the bean definitions. To use property source abstraction you should use #PropertySource annotation i.e. decorate your configuration class with something like
#PropertySource("classpath:SpringConfig.properties")
I believe that you can do the same thing programmatically, i.e. you can get the container's ConfigurableEnvironment before the context was refreshed, modify its MutablePropertySources(you need first to get AbstractApplicationContext environment property via context.getEnvironment() ) via getPropertySources().addFirst(new ResourcePropertySource(new ClassPathResource(
"SpringConfig.properties"))); but it's unlikely what you want to do - if you already have a #Configuration annotated class, decorating it with #PropertySource("classpath:SpringConfig.properties") is much simpler.
As for the PropertySourcesPlaceholderConfigurer instance - it will fetch property sources automatically(as it implements EnvironmentAware) from its application context so you need just to register a default instance of it.
For the examples of custom property source implementation see http://blog.springsource.org/2011/02/15/spring-3-1-m1-unified-property-management/
Adding local properties to PropertySourcesPlaceholderConfigurer (with setProperties() or setLocation()) doesn't make them available in the Environment.
Actually it works in the opposite way - Environment acts as a primary source of properties (see ConfigurableEnvironment), and PropertySourcesPlaceholderConfigurer can make properties from the Environment available using ${...} syntax.
I did this per #Boris suggestion..
PropertySourcesPlaceholderConfigurer propertyHolder = new PropertySourcesPlaceholderConfigurer();
ConfigurableEnvironment env = new StandardEnvironment();
env.getPropertySources().addFirst(
new ResourcePropertySource(new ClassPathResource(
"SpringConfig.properties")));
propertyHolder.setEnvironment(env);
context.addBeanFactoryPostProcessor(propertyHolder);
context.register(SpringConfig.class);
context.refresh();
Now in #Configuration classes all properties (including my own and system properties) can be resolved using #Value.
But the Environment that gets #Autowired into #Configuration class has only system properties in it, not SpringConfig.properties I set as above. But clearly, before calling context.refresh() above, the ConfigurableEnvironment has my properties also. But once context.refresh() is called, my properties are removed from the Environment that gets autowired into #Configuration.
I want to be able to use the better syntax, env.getProperty("my.property"). Does anybody know why that is the case?
I am loading 2 types of properties one is the Environment property and the other is the context which you usually get from lets say servletContext.getServletContext().
My environment property is defined as : MOD_CONFIG_ROOT which is set seperately on the environment thereby seperating the location details the ear file which contains code. Here's the configuration.
[ Note: I had to load the property files as first thing before loading the servlets to make use of the properties using ${someProperty} ]
<bean id="externalProperties"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>file:#{ systemEnvironment['MOD_CONFIG_ROOT']
}#{servletContext.contextPath}/users.properties</value>
</list>
</property>
<property name="searchSystemEnvironment" value="true" />
<property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_FALLBACK" />
</bean>
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.
Is it possible to set a Spring bean sub-property using dot notation? For instance:
<bean name="rememberMe" class="com.mydomain.security.RememberMeManager">
<property name="cookie.domain" value=".${webRoot}"/>
</bean>
Or do I need to also create an intermediary bean for the Cookie object stored in RememberMeManager.getCookie()?
My objective is to set cookies set by my site to ".mydomain.com" instead of "mydomain.com". I have a properties file with webRoot=mydomain.com in it.
Spring's PropertyPlaceholder will have no problem with replacing placeholders that are substrings of the property/value, such as ".${webRoot}", and according to the documentation, it will also fallback to the system properties if no property in the properties file is found.
Did you try this? Does it work or not?
I have an ApplicationContext.xml file with the following node:
<context:property-placeholder
location="classpath:hibernate.properties, classpath:pathConfiguration.properties" />
It specifies that both properties files will be used by my application.
Inside pathConfiguration.properties, some paths are defined, such as:
PATH_ERROR=/xxx/yyy/error
PATH_SUCCESS=/xxx/yyy/success
A PathConfiguration bean has setters for each path.
The problem is: when some of those mandatory paths are not defined, no error is thrown. How and where should I handle this problem?
The standard behaviour of the PropertyPlaceholder that is configured via <context:property-placeholder ... /> throws an exception when a property cannot be resolved once it is required in some place as long as you do not configure it otherwise.
For your case if you have a Bean that requires some properties like this, it will fail when the value cannot be resolved. For example like this:
public class PropertiesAwareBean {
#Value("${PATH_ERROR}")
private String errorPath;
String getErrorPath() {
return errorPath;
}
}
If you want to relax the PropertyPlaceholder and don't make it throw an Exception when a property cannot be resolved you can configure the PropertyPlaceholder to ignore unresolvable properties like this <context:property-placeholder ignore-unresolvable="true" ... />.
One way to reinforce the verification of parameters is to switch to a classical PropertyPlaceholderConfigurer bean in your beans file.
The PropertyPlaceholderConfigurer has properties which you can use to tweak its behavior and specify either an exception is thrown or not if some key is missing (take a look at setIgnoreUnresolvablePlaceholders or setIgnoreResourceNotFound).
If I remember correctly, in Spring 2.5, only the location attribute is supported for <context:property-placeholder> (things might have changed though).
I'm not sure if I fully understand your issue, but there are probably a variety of ways to approach this. One would be to make the paths mandatory by using constructor injection. In the constructor you could then validate the incoming values and if null for example, throw BeanInitializationException instances.