[jira] Created: (CONFIGURATION-414) Support inheritance for configuration

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (CONFIGURATION-414) Support inheritance for configuration

David Mollitor (Jira)
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.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (CONFIGURATION-414) Support inheritance for configuration

David Mollitor (Jira)

    [ https://issues.apache.org/jira/browse/CONFIGURATION-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852980#action_12852980 ]

Ralph Goers commented on CONFIGURATION-414:
-------------------------------------------

Why is this a Jira issue?  This is a question for the users list.

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

Reply | Threaded
Open this post in threaded view
|

[jira] Resolved: (CONFIGURATION-414) Support inheritance for configuration

David Mollitor (Jira)
In reply to this post by David Mollitor (Jira)

     [ https://issues.apache.org/jira/browse/CONFIGURATION-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oliver Heger resolved CONFIGURATION-414.
----------------------------------------

    Resolution: Not A Problem

Ralph is right, JIRA is not the appropriate forum for these kinds of questions. However, as this ticket exists, I think I can answer your question here as well.

Commons Configuration provides the classes {{ConfigurationFactory}} and {{DefaultConfigurationBuilder}} (the latter is a more powerful successor of the former and should be used by new applications). These classes support loading of multiple configuration sources and combining them to a composite configuration. You can influence how the composite configuration is constructed, so it serves different use cases. For instance, you can instruct {{DefaultConfigurationBuilder}} to create a union configuration which contains the sum of all properties.

Another supported mode is called an _override configuration_ which should be similar to your use case (if I understand it correctly): When a property is queried the available configuration sources are searched in the order they were loaded. The first value found is returned. So you can load an application-specific configuration first and then a generic one. Properties defined in the application-specific configuration file override properties in the generic file. If a property is not found in the application-specific configuration, it is searched in the generic configuration.

Variable substitution is also supported and works the same way.

More information is available in the user's guide at http://commons.apache.org/configuration/userguide/user_guide.html, in the sections "Using a Configuration Factory" and following ones and "Using DefaultConfigurationBuilder".

I am going to close this ticket. If you have further questions, please send them to the user mailing list. If you have more specific feature requests, you can open new JIRA tickets.

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

Reply | Threaded
Open this post in threaded view
|

[jira] Closed: (CONFIGURATION-414) Support inheritance for configuration

David Mollitor (Jira)
In reply to this post by David Mollitor (Jira)

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