Nathan Bubna wrote:


[..snip..]

you mean for developers developing with multiple VelocityEngine's who want
their log output to go in different directions.

for the rest of app developers using Velocity--who may want to filter VE log
output by class/source--this is less convenient.

i support the static logger pattern because i think the second group
outnumbers the first.

"Injection way" of getting/providing a logger is always more flexible, from external point-of-view.


The usual code sample:

VelocityEngine ve = new VelocityEngine();
ve.setLogger(somethingThatImplementsLogsystem);
vs.init();

So, how would the app developer filter VE log output in this case? He/she has two options:

* 1st approach would be to provide no logger and let Velocity grab a root logger itself, most probably with category name "org.apache.velocity" or something similar.

VelocityEngine ve = new VelocityEngine();
//logger not provided externally
vs.init();

Note: with this default behaviour Velocity needs to use the static factory approach, but only ONCE for VelocityEngine instance.

So, inside the init() there would be something like:
public void init() {
    if (this.logger == null)
        this.logger = LoggerFactory.getLogger("org.apache.velocity");
    ...
}

The important part is that the static method is used ONLY IF the logger was not provided externally.

* 2nd approach would be to provide a logger. However, as the application developer is probably very static factory approach friendly (as you suggest), he/she can just do the following:

VelocityEngine ve = new VelocityEngine();
ve.setLogger(LoggerFactory.getLogger("org.apache.velocity"));
vs.init();

or, if the application already has a logger (which is true in most cases):

VelocityEngine ve = new VelocityEngine();
ve.setLogger(this.logger.getChildLogger("velocity"));
vs.init();

See, lots of choice that would otherwise be limited to only static factory approach of redirecting the logging output.
(and no issue with multiple velocity instances all logging to same appender where it is VERY difficult afterwards to figure out what was going on where...)


Rgds,
Neeme


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to