commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <remy.mauche...@gmail.com>
Subject Re: Idea: combine JCL 2.0 and UGLI in Logging Services' CL2
Date Sun, 27 Mar 2005 19:52:31 GMT
On Sun, 27 Mar 2005 20:21:04 +0200, Simon Kitching <skitching@apache.org> wrote:
> There really is no reason for an application to use JCL. I´m personally
> surprised that Tomcat chose to do so for its internal logging, and
> pleased to see that the next version is moving away from it.

That's news to me.

> JCL is great for libraries, where the code *cannot* make any assumptions
> about what logging library is available. However there is a significant
> price to pay for using JCL:
>   * a "least common denominator API", and

We have never needed anything more.

>   * a significant performance hit.

JFluid didn't ever show logging as an issue, so it does not matter to me.

> Application code which can make assumptions about what logging library
> it will be bundled with should generally code directly to that logging
> libraries´API. The app then gets a more complete API and better
> performance. [1]
> 
> And libraries which provide fairly simple functionality don´t need
> logging at all; they can report problems via exceptions.
> 
> But for libraries that are complex enough to need logging, but can´t
> assume a particular logging implementation, what options are there other
> than commons logging (or UGLI once it is released)? I would really be
> interested to know! Hard-wiring the use of log4j into such a library
> isn´t an option for obvious reasons.
> 
> Please note that the above is just my personal view..

I don't think Tomcat has a buisiness deciding which logger people
should use, just the same as for your libraries.

-- 
xxxxxxxxxxxxxxxxxxxxxxxxx
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
xxxxxxxxxxxxxxxxxxxxxxxxx

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message