commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siegfried Goeschl <siegfried.goes...@it20one.at>
Subject Re: [exec] How to support the various Logging APIs?!
Date Mon, 14 Jan 2008 09:37:31 GMT
Hi folks,

fortunately my personal opinion is shared with parts of the commons 
community (well, I'm doing some cherry picking here) so I propose

+) remove any logging support forcing an additional dependency
+) provide documentation how to hook in an arbitrary logging API

On the downside the current implementation silently drops so many 
exceptions that I feel a bit uncomfortable about it (or to state it more 
clearly I would reject such a code during code review) -  so I have no 
final conclusion what to do

+) doing nothing is simple and straight forward
+) passing a simple logger facade is a way to go but not terribly 
elegant (we call it "edelhack" in German)
+) I'm not repeating all the other arguments here regarding logging 
frameworks but state that I have no favorite

Cheers,

Siegfried Goeschl

Luc Maisonobe wrote:
> Siegfried Goeschl wrote:
>
>> Because using commons-logging is not undisputed and log4j/jdk logging 
>> would reduce the number of dependencies for a user
>
> I agree. Lots of debate have already occured on this subject, and no 
> consensus reached. This simply shows this is a matter of taste, and 
> probably even passion. So there is no point in pushing one choice 
> among the users. I do have a favorite library too, but will neither 
> say what it is nor try to provide any argument for it.
>
> Removing a dependency is always a good thing for a library that is 
> intended to be a building bloc for some higher level application.
>
> Torsten Curd wrote:
>
> > And I would argue that a library should be so robust that (at
> > least preferably) it does not need any logging at all ...or if there
> > is a problem you just debug it.
>
> I also agree. Commons are quite low level components, they should be 
> as lighweight as possible. They should neither impose some framework 
> to work nor make any assumption on how they will be used. They should 
> be robust and simple enough to not need logging *inside* themselves.
>
> Luc
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>

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


Mime
View raw message