commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [Configuration] experimental branch uses java.util.logging?
Date Wed, 15 Apr 2009 07:20:33 GMT

On Apr 14, 2009, at 11:40 PM, Jörg Schaible wrote:
> Yes and no, since it was never the goal of CL to add additional
> functionality, but to provide a facade for the lowest common set of
> functionality (and originally it was Log4J that prevented the  
> addition of
> the trace level ;-).
> See, we have some global players as customers and all of them use an  
> own
> logging framework that provides explicit support for their operation
> management. However, all provide at least a factory for CL.

More and more of them are supporting SLF4J. Heck, even Apache projects  
are switching.

> As long as you are building an application you have simply more  
> freedom to
> select an appropriate logging framework, but for small components  
> (as I
> consider all components of Apache Commons) you should not force  
> unnecessary
> incompatibilities. Especially since log messages from such basic  
> components
> might turn out simply to have a too fine granularity
> (

> ).
> While I am not conforming to the complete article, it has some valid  
> points
> to consider.

I think Ceki's comment at the end is quite pertinent. But in the end,  
my reaction to that article is pretty much, "I'd love to see a real  
world example of someone doing that". I doubt you'll find many.

It has gotten to the point with SLF4J that NOT logging is extremely  
cheap.On some tests I ran a year or two ago I showed that NOT logging  
1 million records incurred a few hundreths of a second of CPU on my  
desktop machine.  That is insignificant noise.  But the benefits of  
being able to go in and set "java.lang" (or any other package) to  
debug when you are trying to diagnose a significant problem are  
incredibly valuable. I know this because I am encountering this  
problem right now. Commons Configuration just does way too little  
logging to help diagnose problems at runtime. I am having to create  
what I think is a matching scenario for a use case and then see if the  
error happens and then finally run it under the debugger to actually  
figure out what the problem is.

Again, I have no problem reverting back to Commons Logging if that is  
what the community prefers.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message