Return-Path: 
 <commons-user-return-13493-apmail-jakarta-commons-user-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org
Received: (qmail 99946 invoked from network); 1 Sep 2005 06:25:49 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 1 Sep 2005 06:25:49 -0000
Received: (qmail 34706 invoked by uid 500); 1 Sep 2005 06:24:47 -0000
Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org
Received: (qmail 33556 invoked by uid 500); 1 Sep 2005 06:24:41 -0000
Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-user-unsubscribe@jakarta.apache.org>
List-Help: <mailto:commons-user-help@jakarta.apache.org>
List-Post: <mailto:commons-user@jakarta.apache.org>
List-Id: "Jakarta Commons Users List" <commons-user.jakarta.apache.org>
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Delivered-To: mailing list commons-user@jakarta.apache.org
Received: (qmail 29371 invoked by uid 99); 1 Sep 2005 06:24:12 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 Aug 2005 23:24:12 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Received: from [137.248.254.138] (HELO mailgate.med.uni-marburg.de)
 (137.248.254.138)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 Aug 2005 22:57:43 -0700
Received: from localhost (localhost [127.0.0.1])
	by mailgate.med.uni-marburg.de (Postfix) with ESMTP id A34D8A8D7A
	for <commons-user@jakarta.apache.org>; Thu,  1 Sep 2005 07:57:25 +0200 (CEST)
Received: from mailgate.med.uni-marburg.de ([127.0.0.1])
 by localhost (mailgate [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 15685-09 for <commons-user@jakarta.apache.org>;
 Thu,  1 Sep 2005 07:57:05 +0200 (CEST)
Received: from post.med.uni-marburg.de (post.med.uni-marburg.de
 [137.248.253.12])
	by mailgate.med.uni-marburg.de (Postfix) with ESMTP id 5318AA8C58
	for <commons-user@jakarta.apache.org>; Thu,  1 Sep 2005 07:57:04 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by post.med.uni-marburg.de (Postfix) with ESMTP id 8E6B6270D8
	for <commons-user@jakarta.apache.org>; Thu,  1 Sep 2005 07:57:03 +0200 (CEST)
Received: from post.med.uni-marburg.de ([127.0.0.1])
 by localhost (post [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 26918-10 for <commons-user@jakarta.apache.org>;
 Thu,  1 Sep 2005 07:57:00 +0200 (CEST)
Received: from [137.248.224.93] (wstlehre93.med.uni-marburg.de
 [137.248.224.93])
	by post.med.uni-marburg.de (Postfix) with ESMTP id 3742A270CE
	for <commons-user@jakarta.apache.org>; Thu,  1 Sep 2005 07:57:00 +0200 (CEST)
Message-ID: <4316982B.2090006@med.uni-marburg.de>
Date: Thu, 01 Sep 2005 07:56:59 +0200
From: Oliver Heger <hegero@med.uni-marburg.de>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: de, de-at, en-us, en
MIME-Version: 1.0
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Subject: Re: [configuration] Property Substitution Policy
References: <20050831200155.39F8244C427@relay1.r1.iad.emailsrvr.com>
 <1125524239.4316230fa006d@my.visi.com>
In-Reply-To: <1125524239.4316230fa006d@my.visi.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at med.uni-marburg.de
X-Virus-Scanned: by amavisd-new at med.uni-marburg.de
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Jacob Kjome schrieb:
> Quoting Moran Ben-David <moran@place-base.com>:
> 
> 
>>>>Exactly. I opened a Bugzilla ticket for this issue (#36447) and fixed
>>>
>>>it.
>>>
>>>Just to clarify, do you mean that if I have the following config...
>>>
>>><props>
>>>    <url>http://www.boo.com/</url>
>>>    <url>http://www.hoo.com/</url>
>>>    <url>http://www.foo.com/</url>
>>></props>
>>>
>>>And I did...
>>>
>>>config.getProperty("url");
>>>
>>>I would get only the first value, which is "http://www.boo.com/"?
>>
>>No.  The case that we were talking about is when the property is used during
>>interpolation (substitution).  For example, if you had an extra property
>>
>>     <url>http://www.boo.com/</url>
>>     <url>http://www.hoo.com/</url>
>>     <url>http://www.foo.com/</url>
>>     <myresource>${url}myresource.html</myresource>
>>
>>The issue here is, should the entire list ("http://www.boo.com/,
>>http://www.hoo.com/, ...") be used to substitute into "myresource"?
>>
>>I take it that Oliver's fix will be to have Config.getProperty("myresource")
>>return
>>
>>	http://www.boo.com/myresource.html
>>
> 
> 
> Oh, ok.  That does make more sense.  However, it doesn't make complete sense. 
> Seems like that's an error on the part of the config file writer being
> ambiguous about what he/she is actually referring to.  Changing this behavior
> to produce a more sensible looking value doesn't really help.  In fact, it
> might mask the fact that the config file is written in an ambiguous way because
> the value returned from Config.getProperty("myresource") doesn't look like
> there's anything wrong with it because it is using a default URL (the first
> one) even though that may not be the URL originally intended to be referenced.
> 
> For instance, think about the case where there is a config file with the 3 URL's
> above.  Now a developer who doesn't know that order is meaningful, adds another
> URL to the top rather than the bottom.  Now this new URL is returned by
> Config.getProperty("myresource") when really the 2nd one was meant to be
> returned.
> 
> Then again, if the config file developer referenced it like this (not sure if
> syntax is right here, but you get the idea)...
> 
> <myresource>${url(1)}myresource.html</myresource>
> 
> ..order would still be important.  But in this case, it is declared to be
> important by the config file writer so future editors of the config file will
> be tippped off that order is important and re-order accordingly.
> 
> I guess it is hard to say what's correct behavior.  In any case, I'm glad my
> original assumption of what this discussion was all about was incorrect.
> 
> 
> Jake

ATM interpolation takes place only in getString() and for the single 
elements of an array returned by getStringArray(). In this context using 
only the first value of a multi-valued property IMO makes more sense 
than working with a String representation of a value list, which cannot 
be influenced (because simply toString() is called on this list).

But I agree with you that the "correct behavior" certainly depends on 
personal view or a concrete use case. I made this fix to be included in 
the 1.2 release to be consistent with the behavior of other getter 
methods. For the future there is an enhancement request in Bugzilla to 
improve interpolation features 
(http://issues.apache.org/bugzilla/show_bug.cgi?id=35116). This will 
also support custom interpolation strategies and will make it possible 
to change the way multi-valued properties are treated.

Oliver

> 
> 
>>But you'll have to check bugzilla as to what the fix will look like.

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