You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Brett Porter <br...@apache.org> on 2007/02/09 15:55:43 UTC
[configuration] fix for CONFIGURATION-242 can cause regressions?
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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] fix for CONFIGURATION-242 can cause regressions?
Posted by Brett Porter <br...@apache.org>.
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: 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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] fix for CONFIGURATION-242 can cause regressions?
Posted by Brett Porter <br...@apache.org>.
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: 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
Re: [configuration] fix for CONFIGURATION-242 can cause regressions?
Posted by Oliver Heger <ol...@oliver-heger.de>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org