commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <>
Subject RE: [configuration] Property Substitution Policy
Date Wed, 31 Aug 2005 21:37:19 GMT
Quoting Moran Ben-David <>:

> > > 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></url>
> >     <url></url>
> >     <url></url>
> > </props>
> >
> > And I did...
> >
> > config.getProperty("url");
> >
> > I would get only the first value, which is ""?
> 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></url>
>      <url></url>
>      <url></url>
>      <myresource>${url}myresource.html</myresource>
> The issue here is, should the entire list (",
>, ...") be used to substitute into "myresource"?
> I take it that Oliver's fix will be to have Config.getProperty("myresource")
> return

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

Then again, if the config file developer referenced it like this (not sure if
syntax is right here, but you get the idea)...


..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.


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

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

View raw message