commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Heger (JIRA)" <j...@apache.org>
Subject [jira] Closed: (CONFIGURATION-414) Support inheritance for configuration
Date Sat, 03 Apr 2010 14:45:27 GMT

     [ 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.


Mime
View raw message