DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=39068>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39068 Summary: constructor for CompositeConfiguration which takes a list of Configurations Product: Commons Version: 1.2 Final Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Configuration AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] 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()) { Configuration currentConfig = (Configuration)i.next(); addConfiguration(currentConfig); } } 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. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
