Details
-
Improvement
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
1.2
-
None
-
None
-
None
-
Operating System: other
Platform: Other
-
39068
Description
I have recently found a good case for CompositeConfiguration to have a
constructor which takes a Collection of Configurations. I'm using the spring
framework with my application, and I wanted to build a CompositeConfiguration
bean out of several PropertiesConfigurations beans and a MapConfiguration bean.
So I go along and declare beans for the properties and map configurations like so:
<bean id="buildProperties"
class="org.apache.commons.configuration.PropertiesConfiguration">
<constructor-arg index="0"><value>build.properties</value></constructor-arg>
</bean>
<bean id="projectProperties"
class="org.apache.commons.configuration.PropertiesConfiguration">
<constructor-arg
index="0"><value>project.properties</value></constructor-arg>
</bean>
<bean id="defaultProperties"
class="org.apache.commons.configuration.MapConfiguration">
<constructor-arg index="0">
<map>
<entry key="sync.facade.printService" value="mockPrintService"/>
<entry key="sync.facade.fulfillService" value="mockFulfillService"/>
<entry key="sync.facade.userService" value="mockUserService"/>
<entry key="acegi.authenticationDao" value="mockAuthenticationDao"/>
</map>
</constructor-arg>
</bean>
Now, if you wanted to build a composite configuration out of these, normally
you'd have to instantiate a new CompositeConfiguration, then call
addConfiguration for each of the Configurations you'd want to add. However, in
spring-land, this isn't quite possible, because you always deal with either
bean-like properties (setters/getters) or constructor args. So, I propose adding
a constructor does something to the effect of:
public CompositeConfiguration(Collection configs) {
Iterator i = configs.iterator();
while (i.hasNext())
}
With this constructor, it allows you to configure our composite configuration
like so:
<bean id="compositeProperties"
class="org.apache.commons.configuration.CompositeConfiguration">
<constructor-arg index="0">
<list>
<ref bean="defaultProperties"/>
<ref bean="buildProperties"/>
<ref bean="projectProperties"/>
</list>
</constructor-arg>
</bean>
So now, you can inject this configuration into your other beans, or whatever you
want. In my application, for example, I implemented a variation of
PropertyPlaceholderConfigurer that is backed by a Configuration, instead of
using properties files. I also use it to in some places to get at global type
settings.