commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
Subject Re: [configuration] Local lookup fix & enhancement
Date Sat, 21 Mar 2009 15:50:56 GMT
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!

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

Oliver

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


Mime
View raw message