commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: [configuration] fix for CONFIGURATION-242 can cause regressions?
Date Sun, 11 Feb 2007 13:00:30 GMT
I should add a final note... I haven't tested this, but it may not be  
the builder vs non-builder that is at fault here, but hierachical  
(since builder uses this via combined configuration) vs non- 
hierachical (since the test case uses this - via BaseConfiguration)

On 11/02/2007, at 11:54 PM, Brett Porter wrote:

> Well, it has become even more confusing :) My assessment is that it  
> should be left as it is currently for 1.4 (see below).
> I've attached some unit tests to the issue.
> I've found that under 1.3, the same configurations constructed  
> using a builder behave differently to those constructed by hand.  
> This meant that:
> - using a builder, you could resolve a key within the subset when  
> interpolating in that subset, but that you could not do this when  
> not using a builder
> - using a builder, you could not resolve a key from the parent in a  
> subset (this is what CONFIGURATION-242 fixes), but you could outside.
> Under 1.4, everything behaves consistently, between builder and non- 
> builder. This is achieved by changing the first point above so that  
> it doesn't work under either scenario (which is what I considered a  
> regression).
> You could consider this the correct behaviour, though - it is now  
> consistent, and if it did work as before (even if it were under  
> both builder and non-builder), there was another inconsistency:  
> under both 1.3 and 1.4 if you lookup the same key from the parent,  
> the variable is resolved against the parent only, causing an  
> inconsistency when you look it up.
> So...
> * the behaviour is now consistent, and I think that's worthwhile  
> retaining for a 1.4 release. The changes should be noted in the  
> release notes - ie, you can no longer lookup within a subset.
> * it *may* be worth filing an future enhancement to restore this  
> behaviour, in such a way that it applies to both builder and non- 
> builder, and so that if looked up from the parent it still resolves  
> the same (by remembering which subset the interpolation belongs to  
> - perhaps by automatically adding an optional prefix to any  
> expressions inside subsets such that the interpolator first looks  
> inside the subset, then into the root if not found)
> I hope that makes sense - it's rather difficult to explain, but  
> hopefully the attached sample does a better job :)
> - Brett
> On 11/02/2007, at 3:13 AM, Oliver Heger wrote:
>> Brett Porter wrote:
>>> Hi,
>>> I tested out 1.4 on some code I have using 1.3, which has some
>>> expressions that resolve within the same configuration, but which is
>>> located at a different prefix (via config-at). This broke under  
>>> 1.4,  as
>>> it now assumes all interpolations need to happen in the parent.
>>> The feature is definitely useful - but should it first look  
>>> inside  the
>>> subset, and then go to the parent if not found, rather than   
>>> skipping
>>> the subset altogether?
>>> Cheers,
>>> Brett
>> Brett,
>> can you provide a short example code fragment (or even better a unit
>> test) that demonstrates this behavior? I will have a look.
>> Thank you.
>> Oliver
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message