Yo,
Comments in mixed in.
"Geir Magnusson Jr." wrote:
>
> >
> > o Configuration cleanup: I would like to use the Configuration class instead
> > of
> > Properties as it deals with multiple same name keys, includes, and deals
> > with
> > default values internally. This would clean up the Runtime, and all
> > configuration
> > issues will be handled by the Configuration class. The Configuration
> > class is
> > an amalgum of the
> > VelocityResources/ExtendedProperties/ConfigurationRepository.
> > The attempt was to make it work like a standard Properties class except
> > it has
> > more features.
>
> I think that we really should consider this decision carefully. I
> really like having the options of using the Properties to load - since I
> would bet that the Properties class is very common for people to use in
> their own apps, every java101 programmer understands how to use it, etc,
> etc, etc
There would be no difference in usage. And we used the Configuration type
class before we started doing anything with Properties. We should have
considered carefully using Properties but we didn't: we should have used
the same type config class for initializing the Runtime that the Runtime
uses internally . It has only become an issue now because we have
multiple same value keys, but the Configuration class has always
been able to deal with this.
>
>
> The multi-key problem only surfaced recently with the multi-node
> template and jar paths, and that was solvable in the same way WM solved
> it, by letting the property be free form, and letting the entity that
> required multi-valued properties to parse in the way it needs.
The Configuration class always dealt with multiple keys correctly, it's the
Properties
class that doesn't. It should have been something like init(Configuration) from
the start. But it didn't even cross my mind at the time, I just think this is
the correct way to go and is used the same way a Properties class is so it's
not like there's a big learning curve or anything :-)
>
>
> Everything that we want to do could be achieved with the
> java.util.Properties.
I don't think so, the Properties class doesn't behave the way the
Configuration class does and it's the Configuration class that has
always been the core configuration class. To make a Properties
class work with the Configuration class you would have to add
a hack in the runtime to parse CSV lines when the Configuration
class does this already.
> If Configuration makes life easier internally to
> justify the added code, then I am all for it, but I still think that we
> should support the standard Properties object as a full functional
> method of init.
Just for the record, I don't consider the using a Properties object to
init the runtime the standard way. The app that has been using Velocity
the longest, turbine, has never used this method.
My argument is that the usage is the same, initializing with a Configuration
class is more consistent with what we've always had , which is the
Configuration type class (I think it was a mistake we never caught or thought
of),
and it will simplify the Runtime internally. The Resource Loader was greatly
simplied by just using the Configuration.subset(prefix) to grab the config for
a resource loader. And laying over top of defaults will be easier with the
Configuration class. You can simply do something like
Configuration c = new Configuration(config File/Stream, defaults File/Stream)
and it will take care of all our current behaviour regarding the loading of
a default set of properties and laying down overriding properties on top
of them.
>
>
> The set-what-you-want-and-call-init method is quite simple....
Yes. I agree
Configuration c = new Configuration()
c.setProperty(a,b)
Properties p = new Properties()
p.setProperty(a,b)
If they work the same, is it really that much of a leap?
>
>
> > o Log4j: I would like to swtich to using log4j as it seems to be the most
> > mature of the logging packages and the options provided by log4j
> > are very desirable IMO. Rolling log files, or logging to a database (to
> > go along with the data resource loader :-)), or logging via syslog. All
> > these things are possible for minimal effort as log4j will do all the
> > work :-)
>
> can it be pluggable?
Do we really need it to be pluggable? I think log4j will become the standard
logging tool. But if it's decided that it should be pluggable then what do we
go for? Turbine has a pluggable logging service, Avalon has one, and there's
the Sun Logging API (whatever it's called).
My preference would be to just use log4j.
>
>
> > o Get a copy of Alexandria running on the apache.org box so that we
> > can have a link on our site to the javadocs. We can do this manually
> > if necessary, but it would be nice to use Alexandria as that's what
> > it's intended for. Hopefully Jeff Martin and Sam Ruby can help out
> > with this so we will have Javadocs updated daily by the time we
> > release.
>
> Can we update javadocs whenever we want with that?
I'm hoping it does it daily by itself. That's what I'm lead to
believe anyway :-) I want it to do it by itself. Like magic!
> I'll dig up a bunch.
>
Cool.
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
