----- Original Message -----
From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 01, 2001 2:21 PM
Subject: Re: LOG4J
[snip]
> >
> > I would prefer to do the following :
> > - write 2-3 asbtraction classes *for* Log4j, i.e. it is used as a
> > developer's guideline and methodology. Like for example standardizing on
> > using the full class name as logging Categories, ... The real intent of
> > these abstraction classes are just to make sure all the commons packages
use
> > it in the same manner as much as possible (so that it is easier to
> > understand the code and moving it to the Logging JSR later on will all
be
> > easier).
>
> Wouldn't this be an appropriate thing for log4j to do (or to contribute
> to log4j) ?
>
yes ! +1 for that ...
> > - Make it a rule that if some component of commons need to do logging,
it
> > has to use Log4j.
> >
> > Is that too restrictive ? Thoughts ?
>
> Yes, I think that's too restrictive. I think this is one of those
> evolutionary things - if a component needs to log, it would be up to the
> component, and if the users of that component find that it's appropriate
> to add log4j capability, it will happen.
>
I have agree with you on that point ... I should rephrase my previous mail
just by saying that I don't believe much in ourselves (i.e. jakarta-commons)
doing a generic facade for logging. You're right, just let every component
choose whether it wants to do logging or not and the tools for the job.
> Maybe trying to define a commons logging interface is worthwhile, but
> also, I think that evolution might resolve that question over time as
> well.
>
+1
> geir
>
> --
> Geir Magnusson Jr. [EMAIL PROTECTED]
> System and Software Consulting
>
> Developing for the web? See http://jakarta.apache.org/velocity/
>
