> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
>
>
> For me, in general I slurp in a properties file into a Properties or
> something, and punch them in, and the second takes care of that.
>
Not that I like to rain on your party, but have you considered that there is
no guarantee Properties.getKeys() and so on will give you the properties in
the same order as they were in the file.
What that means is that you may get:
setProperty("config.property.5", "value5")
setProperty("config.property.3", "value3")
setProperty("config.property.2", "value2")
setProperty("config.property.1", "value1")
setProperty("config.property.4", "value4")
Now, if "config.property" has a value on the default configuration, how
do you know when to replace the old values and when to add to the existing?
So I am not sure you are not back on square one in the case of Properties.
> I think we have complete coverage in three Runtime methods
> and can make
> convenience methods in o.a.v.a.Velocity.
>
> > So I think if you really wanted to load a properties file, alter it,
> > then Velocity.init(Properties) then I think the Configuration class
> > will deal with it fine internally.
>
> As long as we define a complete configuration API for
> Runtime, we could
> take care of this in the Velocity class. We would implement
> Velocity.init(Properties) to use the
> setProperty()/addProperty()/init()
> Runtime API, which I think covers everything.
As long as this class is intelligent enough as to deal with the above
issue, then everything is fine.
Jose Alberto
