cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Porting Cocoon Logging to Log4j - Proposal and Discussion
Date Thu, 28 Aug 2003 13:32:40 GMT
Nicola Ken Barozzi wrote:

> 
> Berin Loritsch wrote, On 28/08/2003 15.08:
> 
>> Robert Simmons wrote:
>>
>>> Actually, I was proposign the removal of the avalon logging mechanism
>>> completely.
>>
>>
>> -1000
>>
>> If I want to use a NullLogger (no logging completely, and no need for 
>> a logging
>> toolkit) then I should be able to.  If I want to use Log4J I should be 
>> able to.
>> And if I am happy with LogKit (which is smaller BTW), then why should 
>> I loose
>> that ability?
> 
> 
> Berin, I think that Robert has a valid point here, and that is similar 
> to what Avalon said about Logkit and Log4j.
> 
> When I was still in Avalon, Avalon had informally agreed to push Logkit 
> EOL in favor of log4j, and the log4j community accepted the challenge of 
> bridging the last differences still remaining.
> 
> Why is this point much different from the one Robert is talking about?


I would be very much against marrying the Cocoon system to Log4J despite
it's advantages over LogKit.  Let's assume for the moment that JDK 1.4
logging becomes mainstream over Log4J (not likely, but play devil's advocate
for a moment).  If you have forceably ripped out the LogEnabled interfaces
and hardcoded against Log4J, the migration path would be very painful to
say the least.

Also, to make matters worse, not everyone has the same needs.  Some shops
will blindly use corporate products or language APIs regardless of their
merit.  Other shops evaluate the available libraries.  If we have a very
lightweight logging abstraction that doesn't tie us down to one implementation,
we can easily make everyone happy.

Not everyone uses Log4J (as Robert asserts).  I would be against coding
ourselves into a corner when there are legitimate ways to avoid the situation
_already_ in place.

Yes, informally the Avalon team will be deprecating LogKit in favor of Log4J 2.0
but it isn't out yet.  Plans can change (although this seems to be a pretty
safe bet).

Lastly, the NullLogger included in Avalon Framework is orders of magnitude
faster than any of the full Logging toolkits like LogKit, Log4J, and
java.util.logging.  If you don't need/want logging (extreme example), why
force it?

I can understand going backwards a short distance if the alternate route
let's us go farther.  However, the proposal seems to take a good route and
trade it for a dead end.  I am not for that.



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


Mime
View raw message