Jacob Kjome schrieb:
Quoting Moran Ben-David <[EMAIL PROTECTED]>:
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
