Yeah, I agree that different components will probably have different
logging needs.  I think it's premature to try and standardize on a
particular logging format.  Also, in my mind it's not a given that we
would port from LOG4J to the new Sun API; only if there are clear
advantages.

Simple per-component facades are probably the way to go.  If we turn out
to perform logging on HttpClient (looks possible), I'll see if I can cook
up something.  It would probably be a facade to LOG4J that provides
resonable default behaviour.  That way concerns about ease-of-use will be
addressed.  That's what I was assuming in any case.  It doesn't make sense
for clients to handle logging, unless they want to customize it.  Being
able to do both is a big bonus.

- Morgan


On Tue, 1 May 2001, Vincent Massol wrote:

> 
> ----- 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/
> >
> 
> 

Reply via email to