Jason van Zyl wrote:
>
> Yo,
>
> Comments in mixed in.
>
> "Geir Magnusson Jr." wrote:
>
> > 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.
Can we just support both then? The 'same value key' problem is somewhat
artificial, because you and john wanted to do, for multiple paths,
path = foo
path = bar
path = woogie
rather than
path = foo:bar:woogie
or
path.1 = foo
path.2 = bar
path.3 = woogie
(The latter way is nicer - you don't have to worry that the separator
is a valid character in the data )
If we switched to the second way, then both the Configuration and the
Properties would work. I do agree that it's a shame there isn't
multi-valued property support in Properties.
> > 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 :-)
It's not the learning curve : I just don't want to force people to use
it. I am just arguing to keep it, and add an init( Configuration ), but
keeping init( Properties ) would be easy for those using the Properties
in their own apps.
> >
> >
> > 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.
Or if we made a simple change to what a multi-path spec is, to
path.1 = foo
path.2 = bar
wouldn't the issue just go away?
> > 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.
And looking at TurbineVelocityService, it uses a Properties internally
(so some apps *do* use the Properties class for configuration
management), and knows where its properties file is. I think the
following code would make Turbine compatible with using j.u.Properties
to initialize :
Properties p = new Properties();
p.load( vProperties );
p.setProperty(Runtime.FILE_RESOURCE_LOADER_PATH, vTemplates);
p.setProperty(Runtime.RUNTIME_LOG, vLog);
Runtime.init();
It's one line of code more than the current implementation. It's
structurally the same : the current implementation just uses Runtime as
a Properties, and the above uses a Properties as a Properties.
Of course, there may be something subtle about Turbine where that
wouldn't work. I am not sure.
If we got rid of those methods from Runtime, Runtime would get smaller,
and clean up the initialization semantics w/o undue burden on Turbine.
Further, in general one wouldn't be tempted to call
Runtime.setProperty() after init(), since those methods wouldn't exist.
Currently, we don't support post-init() property additions anyway, so
nothing would be lost.
The rule would be 1) optionally setup the properties (in a Properties
or Configuration) and then 2) call init() [with no arg for defaults,
with a filename for vel to read, with a Properties if you have one, or a
Configuration if you use that.]
And I don't consider either the 'standard way' - I just see the
java.util.Properties as an easy way using a standard class that people
could already use in their own applications (like Turbine seems to) - so
they could just glom together the velocity properties with their
properties for easy configuration, and just use that.
I think giving people the choice of
init() : use defaults
init( filename ) : use filename
init( Properties ) :
init( Configuration )
would make it more convenient.
> 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
<mental meandering aside>
I wonder if it would get even simpler if you let the consuming class
(the *ResourceLoader) deal with their own configuration properties, and
let the Manager get what it needs either directly from the
configuration, or in the case of values specific to each loader,
through a standard manager interface supported by each Loader. A simple
set of utilities to help the loaders would make it easy.
</mental meandering aside>
> 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.
Cool. I guess to summarize, I am just trying to say that we can support
all of the types, I think, if we just change the new multi-value
property bit to something else.
like
resource.loader.1.resource.path.1 = foo
resource.loader.1.resource.path.2 = bar
resource.loader.1.resource.path.3 = woogie
it would also mean that the user could specify the search order
explicitly. (I guess they do it implicily with the ordering now ?)
>
> > 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?
Not at all. I didn't think it would be. :)
But if I alrady have a Properties for my app, I can just drop it in.
> > > 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.
me too as our default.
but if there was a simple wrapper we could put around log4j, we have the
ability to easily change later, or if a user already has some existing
investment in a logging system they lik, they could wrap it in our
interface and plug velocity right in.
> >
> > > 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!
Ah magic.
What I was asking was - can I force it if I need to, or do you have to
wait for the next cycle? Just thinking if we need a quick update for
some reason. Doesn't matter : sounds good.
> > I'll dig up a bunch.
> >
>
> Cool.
>
> --
> jvz.
>
> Jason van Zyl
> [EMAIL PROTECTED]
>
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/turbine
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
