commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Moran Ben-David" <mo...@place-base.com>
Subject RE: [configuration] Property Substitution Policy
Date Wed, 31 Aug 2005 21:55:49 GMT
I see what you're saying.  My original request to Oliver was to be able to
alter the behaviour of Configuration and interpolation from the outside.
That is, from my application's code.  I made some code changes to preserve
both old (using all the multi-list) and new (using the first value)
behaviours.

I am not sure what Oliver's take of your case is, but I believe he asked the
list if there were any cases that anyone had for keeping the existing
behaviour.  I guess your email is to that.

The great issue at I think is that some of us use multiple instances of the
variables assignments in config files to OVERRIDE (myself) while other use
them to ADD (yourself).

I don't think it's a badly written configuration when you have something
like a base file (with defaults) that also has an include at the top (for
the personal properties file.  What we do (in my team) is we check in the
base file, and don't check in the personal file.  In so doing, we can
publish configuration variables automatically to other's sandboxes by our
source repository system (svn).  However, we don't destroy our personal
settings since we don't check in the 'personal properties' file.

Wrote this email rather quickly, so I hope I've added to the discussion.

Thanks,
Moran

> -----Original Message-----
> From: Jacob Kjome [mailto:hoju@visi.com]
> Sent: Wednesday, August 31, 2005 5:37 PM
> To: Jakarta Commons Users List
> Subject: RE: [configuration] Property Substitution Policy
> 
> 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
> 
> > 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


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


Mime
View raw message