You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Thomas Eichstädt-Engelen <th...@gmx.net> on 2007/01/26 13:13:39 UTC

[configuration] Overriden Properties in CombinedConfiguration and the configuratinAt method

Hi,

i am using commons-configuration with constantly growing enthusiasm. Thank you for this great job!

Now my question:

I am using CombinedConfiguration to make use of the Property overriding mechanism. My configuration-definition.xml looks like this:

<configuration>
  <header>
    <result>
      <nodeCombiner config-class="org.apache.commons.configuration.tree.OverrideCombiner"/>  
      <expressionEngine config-class="org.apache.commons.configuration.tree.xpath.XPathExpressionEngine"/>
    </result>
  </header>
  <override>
    <system />
    <xml fileName="${OPERATIONS_CONFIGURATION}" throwExceptionOnMissing="true"
      config-name="operationsConfiguration" config-optional="false">
      <reloadingStrategy refreshDelay="1000"
        config-class="org.apache.commons.configuration.reloading.FileChangedReloadingStrategy"/>
    </xml>
    <xml fileName="messageComposerConfiguration.xml" throwExceptionOnMissing="true"
      config-name="messageComposer" config-at="messageComposer" config-optional="false">
      <reloadingStrategy refreshDelay="1000"
        config-class="org.apache.commons.configuration.reloading.FileChangedReloadingStrategy"/>
    </xml>
    [... more xmlConfigurations ...]
  </override>
</configuration>

operationsConfiguration is intended to be a smaller (and more handy) configuration available outside the archives (jars) containing only the relevant operational properties. It overrides some values of the other xmlConfigurations of the e.g. backend libraries. So far so good ... now i would like to use the BeanCreation mechanism furthermore. To provide data for those beans i use the configurationAt(key) method to get a unique subtree containing all relevant data.

And here is my problem:

Using the configurationAt(key) throws an IllegalArgumentException because the given key is ambiguous. That is correct because it is overriden and added twice hence. It tried the workaround to create a combined node via getRootNode(). It worked but in this case all the e.g. configured ReloadingStratety disappears because i had to create a new XmlConfiguration.

Would it make sense to overload the configurationAt method in CombinedConfiguration to support such a behaviour? Or (and that could be really possible) didn't i understand the concept of the CombinedConfiguration exactly.

Kind regards,

Thomas E.-E.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [configuration] Overriden Properties in CombinedConfiguration and the configuratinAt method

Posted by Thomas Eichstädt-Engelen <th...@gmx.net>.
Hi Oliver,

thanks for your answer ... i'll try it out tommorow!

Regards,

Thomas E.-E.


-------- Original-Nachricht --------
Datum: Mon, 29 Jan 2007 22:12:14 +0100
Von: Oliver Heger <ol...@oliver-heger.de>
An: Jakarta Commons Users List <co...@jakarta.apache.org>
Betreff: Re: [configuration] Overriden Properties in CombinedConfiguration and the configuratinAt method

> yes, I think I understand your problem now. I tried to reproduce it, but 
> without success. I have written the following test case:

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [configuration] Overriden Properties in CombinedConfiguration and the configuratinAt method

Posted by Oliver Heger <ol...@oliver-heger.de>.
Thomas Eichstädt-Engelen wrote:
> Hi Oliver,
> 
> thanks for your quick response.
> 
>> Or could you provide a more detailed example with such an overridden
>> bean declaration that causes ambigous keys?
> 
> Let's assume i have two XmlConfigurations. Both of which are configured in my configuration-definition.xml file. The order is SpecialisedConfiguration at first followed by GeneralConfiguration.
> 
> SpecialisedConfig (lies somewhere editable for my operationsTeam)
> 
> <jobs>
>   <job_1 secretKey="geheim" />
> </jobs>
> 
> and the GeneralConfig (is packed into a war-file)
> 
> <jobs>
>   <job_1 config-class="de.eichstaedt.ClassToCreateViaBeanUtils"
>     secretKey="anfang"
>     attribut_1="foo"
>     attribut_2="bar" />
>   <job_2 [...] />
>   [...]
> </jobs>
> 
> 
> Now I use a DefaultConfigurationBuilder to create my configuration object as described in the UserGuide:
> 
> DefaultConfigurationBuilder builder = new DefaultConfigurationBuilder();
> builder.setFile(new File("configuration.xml"));
> CombinedConfiguration cc = builder.getConfiguration(true);
> 
> After that i start the bean creation with:
> 
> // get a combined subConfig with 
> // overridenValues to build a Bean from
> HierchicalConfiguration config = cc.configurationAt("jobs.job_1")
> BeanDeclaration decl = new XMLBeanDeclaration(config);
> ClassToCreateViaBeanUtils createdClass = (ClassToCreateViaBeanUtils) BeanHelper.createBean(decl);
> 
> At this point i assumed to get a view to one combined configuration and to get a Configuration with the overriden secretKey attribute. But an exception is thrown instead.
> 
> My workaround is to create a combined node via getRootNode(). It worked but in this case all that previoulsy configured stuff e.g. ReloadingStratety, NodeCombiner, etc. disappears because i created a new XmlConfiguration from that RootNode.
> 
> I think the exception at configruationAt() - implemented in HierarchicalConfiguration - occured because it simply fetches a nodeList with the given key. It does not take into account that one configuration has overriden some values of the other one. That is clear because the overriding behaviour is added deeper in the ClassHierarchy initially with the CombinedConfiguration. Thus i assumed to find a specialised version of configurationAt() dealing with the combinedRoot in that class.
> 
> Does my question became clearer now? Sorry for my english ...
> 
> Kind regards from Germany,
> 
> Thomas E.-E.
Thomas,

yes, I think I understand your problem now. I tried to reproduce it, but 
without success. I have written the following test case:

     public void testCombinedAttributes()
     {
         HierarchicalConfiguration c1 = new HierarchicalConfiguration();
         c1.addProperty("jobs.job_1[@secretKey]", "geheim");
         HierarchicalConfiguration c2 = new HierarchicalConfiguration();
         c2.addProperty("jobs.job_1[@config-class]", 
Object.class.getName());
         c2.addProperty("jobs.job_1[@secretKey]", "test");
         c2.addProperty("jobs.job_1[@attribute_1]", "foo");
         c2.addProperty("jobs.job_2[@secretKey]", "test2");
         CombinedConfiguration cc = new CombinedConfiguration(new 
OverrideCombiner());
         cc.addConfiguration(c1);
         cc.addConfiguration(c2);
         assertEquals("geheim", cc.getProperty("jobs.job_1[@secretKey]"));
         HierarchicalConfiguration c3 = cc.configurationAt("jobs.job_1");
         assertEquals("geheim", c3.getString("[@secretKey]"));
     }

Here I create a combined configuration manually by combining two 
hierarchical configurations with similar content as in your example. 
This seems to work. I can call configurationAt(), and the resulting sub 
configuration has the overridden attribute.

Note that CombinedConfiguration does not need its own implementation of 
configurationAt(). Its content is produced by a NodeCombiner object, 
which already takes overriding properties into account.

So, I am not sure why you get an exception. What you can do for testing 
purposes is to dump your combined configuration to see how it looks like:

XMLConfiguration xmlconf = new XMLConfiguration(cc);
xmlconf.save("combined.xml");

(The constructor that takes another configuration was added after the 
1.3 release, so you need a recent nightly build to check this.) This 
should create a XML file with the content of the combined configuration. 
Maybe this is helpful to find out why the key is ambiguous.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [configuration] Overriden Properties in CombinedConfiguration and the configuratinAt method

Posted by Thomas Eichstädt-Engelen <th...@gmx.net>.
Hi Oliver,

thanks for your quick response.

> Or could you provide a more detailed example with such an overridden
> bean declaration that causes ambigous keys?

Let's assume i have two XmlConfigurations. Both of which are configured in my configuration-definition.xml file. The order is SpecialisedConfiguration at first followed by GeneralConfiguration.

SpecialisedConfig (lies somewhere editable for my operationsTeam)

<jobs>
  <job_1 secretKey="geheim" />
</jobs>

and the GeneralConfig (is packed into a war-file)

<jobs>
  <job_1 config-class="de.eichstaedt.ClassToCreateViaBeanUtils"
    secretKey="anfang"
    attribut_1="foo"
    attribut_2="bar" />
  <job_2 [...] />
  [...]
</jobs>


Now I use a DefaultConfigurationBuilder to create my configuration object as described in the UserGuide:

DefaultConfigurationBuilder builder = new DefaultConfigurationBuilder();
builder.setFile(new File("configuration.xml"));
CombinedConfiguration cc = builder.getConfiguration(true);

After that i start the bean creation with:

// get a combined subConfig with 
// overridenValues to build a Bean from
HierchicalConfiguration config = cc.configurationAt("jobs.job_1")
BeanDeclaration decl = new XMLBeanDeclaration(config);
ClassToCreateViaBeanUtils createdClass = (ClassToCreateViaBeanUtils) BeanHelper.createBean(decl);

At this point i assumed to get a view to one combined configuration and to get a Configuration with the overriden secretKey attribute. But an exception is thrown instead.

My workaround is to create a combined node via getRootNode(). It worked but in this case all that previoulsy configured stuff e.g. ReloadingStratety, NodeCombiner, etc. disappears because i created a new XmlConfiguration from that RootNode.

I think the exception at configruationAt() - implemented in HierarchicalConfiguration - occured because it simply fetches a nodeList with the given key. It does not take into account that one configuration has overriden some values of the other one. That is clear because the overriding behaviour is added deeper in the ClassHierarchy initially with the CombinedConfiguration. Thus i assumed to find a specialised version of configurationAt() dealing with the combinedRoot in that class.

Does my question became clearer now? Sorry for my english ...

Kind regards from Germany,

Thomas E.-E.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [configuration] Overriden Properties in CombinedConfiguration and the configuratinAt method

Posted by Oliver Heger <ol...@oliver-heger.de>.
Thomas Eichstädt-Engelen wrote:
> Hi,
> 
> i am using commons-configuration with constantly growing enthusiasm. Thank you for this great job!
:-)
<snip/>
> 
> And here is my problem:
> 
> Using the configurationAt(key) throws an IllegalArgumentException because the given key is ambiguous. That is correct because it is overriden and added twice hence. It tried the workaround to create a combined node via getRootNode(). It worked but in this case all the e.g. configured ReloadingStratety disappears because i had to create a new XmlConfiguration.
> 
> Would it make sense to overload the configurationAt method in CombinedConfiguration to support such a behaviour? Or (and that could be really possible) didn't i understand the concept of the CombinedConfiguration exactly.
> 
> Kind regards,
> 
> Thomas E.-E.
I think I do not fully understand your problem. Which key do you pass to
the configurationAt() method? Is it not possible to make this key more
specific (e.g. by adding an index), so that it points to a single
configuration only?

Or could you provide a more detailed example with such an overridden
bean declaration that causes ambigous keys?

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org