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: [email protected]
For additional commands, e-mail: [email protected]
