commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
Subject Re: [configuration] Local lookup fix & enhancement
Date Sun, 22 Mar 2009 01:04:21 GMT
Hi Oliver,

Oliver Heger wrote:

> Jörg Schaible schrieb:
>> Hi,
>> 
>> Jörg Schaible wrote:
>> 
>>> Hi folks,
>>>
>>> OK then, so don't be surprised if I start to commit. I will have to make
>>> me familiar with the experimental branch first though.
>>>
>>> Oliver Heger wrote:
>>>
>>>> I am fine with both points and also agree with the comments of Ralph.
>>>>
>>>> 1) sounds that the current implementation is buggy - or at least
>>>> inconsistent; so this should really be improved.
>>> I'll start with this.
>> 
>> OK, this topic now nearly finished. To clean it up, I have to ask about
>> the desired behavior though. Main goal was to support local lookups in a
>> SubsetConfiguration that have been registered in its parent
>> (CONFIGURATRION-375). Additionally it is now also possible to interpolate
>> in the subset also a configuration key of the parent (CONFIGURATION-376)
>> i.e. the behavior is now similar to a SubnodeConfiguration. Looking at
>> the tests for a BasicConfiguration it should also possible to register a
>> lookup local to the subset only, this is implemented with
>> (CONFIGURATION-369). Changes have been done on the c2 branch and merged
>> back into trunk.
>> 
>> What we have now is:
>> ================ %< ================
>> AbstractConfiguration config = new BaseConfiguration();
>> config.getInterpolator().registerLookup("parent", ...);
>> config.setProperty("top.foo", "bar");
>> config.setProperty("top.sub.test", "junit");
>> config.setProperty("top.sub.val1", "${test}");
>> config.setProperty("top.sub.val2", "${top.foo}");
>> config.setProperty("top.sub.val3", "${parent:x}");
>> config.setProperty("top.sub.val4", "${child:y}");
>> SubsetConfiguration subConfig = config.subset("top.sub");
>> subConfig.getInterpolator().registerLookup("child", ...);
>> 
>> assertEquals("junit", subCongig.getKey("val1"));
>> assertEquals("bar", subCongig.getKey("val2"));
>> assertEquals("px", subCongig.getKey("val3"));
>> assertEquals("cy", subCongig.getKey("val4"));
>> ================ %< ================
>> 
>> Supported asserts for val1, val3 and val4 are new. As suggested by Ralph
>> I keep an eye on SubnodeConfiguration also:
>> 
>> ================ %< ================
>> HierarchicalConfiguration config = new HierarchicalConfiguration();
>> config.getInterpolator().registerLookup("parent", ...);
>> config.setProperty("top.foo", "bar");
>> config.setProperty("top.sub.test", "junit");
>> config.setProperty("top.sub.val1", "${test}");
>> config.setProperty("top.sub.val2", "${top.foo}");
>> config.setProperty("top.sub.val3", "${parent:x}");
>> config.setProperty("top.sub.val4", "${child:y}");
>> SubnodeConfiguration subConfig = config.subset("top.sub");
>> subConfig.getInterpolator().registerLookup("child", ...);
>> 
>> assertEquals("junit", subCongig.getKey("val1"));
>> assertEquals("bar", subCongig.getKey("val2"));
>> assertEquals("px", subCongig.getKey("val3"));
>> assertEquals("cy", subCongig.getKey("val4"));
>> ================ %< ================
>> 
>> However, here asserts for val2 and val4 fail. Main issue is that a
>> SubnodeConfiguration does always use the parent configuration's
>> interpolater and ignores the local one. However, this seems by design.
>> Question is now, if I should fix this assuming the design has flaws? The
>> pro side is the equivalent behavior of subset and subnode then.
>> 
>> What do you think?
> 
> The interpolate() method of SubnodeConfiguration was probably written
> before the invention of local lookups. When the lookups were added, it
> was forgotten to update this method, too.
> 
> So IMO this could be considered a bug. If you have a fix for it, go ahead!

Done (CONFIGURATION-377).

> 
>> 
>> - Jörg
>> 
>> 
>> BTW: How are the JIRA issues handled? Should I simply resolve them?
>> Normally I would have expected that all resolved issues are closed when a
>> release is been made (with the appropriate fix version), but currently
>> nearly all issues for configuration have state "resolved" ...
>> 
> In fact, we have never closed issues, but treated the RESOLVED state as
> CLOSED. Closing the tickets after a release seems to be good idea. I
> think we should do that.

The fine difference is, that a user can reopen the resolved issue, but not a
closed one. This gives him the possibility to raise concerns as long as the
release did not happen. After the release it's mood and he rather open a
new issue or CLONE the closed one.

- Jörg


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


Mime
View raw message