Unlike Jon's, this kind of objective argumentation makes a lot
more sense to me and it sure raises my interest for log4j.
However, I still think that this and other libraries (e.g.:
HttpClient) should be log-engine agnostic. Even when there is
a standard API, they should use that API but still stay engine
agnostic.
Just my 2 cents,
Paulo Gaspar
> -----Original Message-----
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 01, 2001 2:56 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [GUMP] Build Failure - Velocity
>
>
> On 7/31/01 8:06 PM, "Jon Stevens" <[EMAIL PROTECTED]> wrote:
>
> > on 7/31/01 4:47 PM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote:
> >
> >> Should we agree with you just because YOU are tired of LogKit?
> >
> > I'm just voicing my opinion.
> >
> > I never said that you have to agree with me.
> >
> >> Shouldn't Velocity be log system agnostic?
> >
> > It already is. I wrote the code.
>
> I still think using log4j directly is the way to go. I'm having
> the same argument everywhere but log4j allows you to integrate
> with any other logging system and it provides more flexibility
> and granularity than you can get with a simple interface.
>
> For example, you could very simply create a log4j appender that
> interfaces with the servlet logging mechanism for unified logging
> in a webapp if you wanted.
>
> I have made log4j appenders to interface with a couple existing
> logging system, and made one to log to a database and it's pretty
> simple. To me log4j is a logging interface. There are a growing
> number of these little logging interfaces poping up all over the
> place but I don't think they really buy you anything. Any interface
> created is less flexible and provides less granularity. With log4j
> by simply changing a config file you could have reference errors
> go to one appender, say a mail message to designer to tell him
> that a reference is not defined, and database resource errors log
> to syslog where a system admin would find with a standard syslog
> logfile processing tool. Log4j is completely flexible and you
> can log anything you want to any destination by changing the
> config file.
>
> As I've said before the usage pattern offered by log4j and the
> sun logging API are becoming standard: it may seem unecessary
> to get an instance of a category in each class (you could do
> it in a subclass if you wished) but it truly allows full
> control over all logging options.
>
> And because jsr27 is now very, very close to what log4j does
> (this was a result of Ceki's discussions with the spec lead) so
> flipping from one to the other is very easy. A search and replace
> operation if you wanted to change in the future, but I still think
> log4j is better.
>
> I don't think we lose anything by binding to log4j directory, and
> I don't think we gain anything by making another logging interface.
> I have asked Ceki how small we could make a log4j-tiny.jar to provide
> the bare minimum for logging so people can't complain about the size.
> I don't find this a valid argument anyway because everything needs
> logging so it is likely that a log4j jar will be around.
>
> I'm going to take a stab at making a minimal log4j just to try
> it but I think tiny log4j jar would provide a better option than
> rolling another logging interface.
>
> > My suggestion is to take that out and just depend on Log4J.
> >
> > It will remove a few classes from Velocity itself, and make the code and
> > configuration smaller and simpler.
> >
> > -jon
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
