[
https://issues.apache.org/jira/browse/CONFIGURATION-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger closed CONFIGURATION-414.
--------------------------------------
> Support inheritance for configuration
> -------------------------------------
>
> Key: CONFIGURATION-414
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-414
> Project: Commons Configuration
> Issue Type: New Feature
> Reporter: garpinc
>
> Some time ago I created a contribution for jconfig which completed the work
> described here: http://www.jconfig.org/ConfigurationInheritance.html
> Jconfig seems however to be no longer maintained and I never found a home for
> the code.
> Basically jconfig would allow for a -D option to be specified in the JVM
> which would allow an application to decide which xml config file to start
> with per environment and at that point inheritance would take over. In each
> config file it supported a 2 level hierarchical structure. Therefore you can
> group certain properties into categories. There is one default category
> called "general".
> so how it would work is as follows:
> you ask for property "myapplication:theproperty" first it would look in the
> first config file pointed to from the -D option and see if a category
> "myapplication" and a property within "theproperty" was defined.. If not it
> would follow the extends xml config to determine the same for that category
> and property and so on and so forth.. In addition if after looking
> specifically for the category property combination it is not resolved then it
> would look for the same property in the general category once again starting
> with the first config and following the extends.
> In addition if a property value contained a place holder i:e
> ${mycategory2:myproperty2} it would resolve that using the same hierarchical
> procedure before returning that value in the config.
> The usecase here of this in practice is as follows...
> On the app server classpath we maintained a config xml file that contained
> the general category for storing properties that were specific to environment
> vs application.
> This xml config would extend app config file in the application itself
> the app config file in the application has a category that was specific to
> the application i.e: myapplication and properties that were application
> specific
> this file then extended another library config file which kept default
> properties that were specific to frameworks in the general category
> so hence properties for app, framework or libraries can be defined or
> overridden at any level. In the environment, in the application or in the
> global library configuration
> It lead to great flexibility..
> Is there anything quite like this is Commons Configuration and if not how
> likely would you be to work with me to get the code I have based on jconfig
> to port to this solution?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
