You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Jörg Schaible <Jo...@Elsag-Solutions.com> on 2004/12/02 14:17:57 UTC

[Configuration] Property interpolation & subsets

Hi folks,

looking at the current implementation, I am not convinced, that the current behaviour is intentional. Look at the case:

defaults.client.port=8000
client.A.dir=${java.io.tmpdir}
client.A.url=http://client:${port}

having:

CompositeConfiguration globalConfig = new CompositeConfiguration();
globalConfig.addConfiguration(ConfigurationConverter.getConfiguration(System.getProperties()));
globalConfig.addConfiguration(readConfigWithPropertiesFromAbove);

one might assume, that is is save to do:

CompositeConfiguration clientConfig = new CompositeConfiguration();
clientConfig.addConfiguration(globalConfig.subset("client.A"));
clientConfig.addConfiguration(globalConfig.subset("defaults.client"));

Now these statements are true:

assertEquals("http://client:8000", clientConfig.getString("url"));
assertEquals(8000, clientConfig.getInteger("port"));
assertEquals("${java.io.tmpdir}", clientConfig.getString("dir"));

What's the problem?

As you can see, the administrator configuring the properties has to know in what scope the interpolation will be done by the application implementation, the implementation itself rely on the assembled subset though. The interpolation of the system property would have worked only, if another Configuration with system properties have been added to the client configuration.

So should the SubsetConfiguration use its parent configuration as fallback for the interpolation? Then both cases can be handled.

- Jörg

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


Re: [Configuration] Property interpolation & subsets

Posted by Emmanuel Bourg <sm...@lfjr.net>.
Hello Jörg, good point I didn't think about this issue I'll investigate 
it. Translating the key in the interpolation method might be another 
solution, I'm not sure how to do this though.

Emmanuel Bourg


Jörg Schaible wrote:
> Hi folks,
> 
> looking at the current implementation, I am not convinced, that the current behaviour is intentional. Look at the case:
> 
> defaults.client.port=8000
> client.A.dir=${java.io.tmpdir}
> client.A.url=http://client:${port}
> 
> having:
> 
> CompositeConfiguration globalConfig = new CompositeConfiguration();
> globalConfig.addConfiguration(ConfigurationConverter.getConfiguration(System.getProperties()));
> globalConfig.addConfiguration(readConfigWithPropertiesFromAbove);
> 
> one might assume, that is is save to do:
> 
> CompositeConfiguration clientConfig = new CompositeConfiguration();
> clientConfig.addConfiguration(globalConfig.subset("client.A"));
> clientConfig.addConfiguration(globalConfig.subset("defaults.client"));
> 
> Now these statements are true:
> 
> assertEquals("http://client:8000", clientConfig.getString("url"));
> assertEquals(8000, clientConfig.getInteger("port"));
> assertEquals("${java.io.tmpdir}", clientConfig.getString("dir"));
> 
> What's the problem?
> 
> As you can see, the administrator configuring the properties has to know in what scope the interpolation will be done by the application implementation, the implementation itself rely on the assembled subset though. The interpolation of the system property would have worked only, if another Configuration with system properties have been added to the client configuration.
> 
> So should the SubsetConfiguration use its parent configuration as fallback for the interpolation? Then both cases can be handled.
> 
> - Jörg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> 

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