cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: AbstractLogEnabled...
Date Tue, 16 Oct 2007 16:02:51 GMT
Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
>> Hi,
>>
>> Ok I'm confused about AbstractLogEnabled business. Is it correct that
>> instead of org.apache.avalon.framework.logger.AbstractLogEnabled we
>> should be using org.apache.cocoon.util.AbstractLogEnabled [1]?
>>
>> If yes, why there are only 2 usages of the latter and around 100 usages
>> of the former? :)
>>
>> Should I go ahead and do a replacement? Or may be we should discuss it
>> first. For example, should there be an implementation of
>> enableLogging(org.apache.avalon.framework.logger.Logger logger) method
>> to provide backward compatibility.
>>
> No, I don't think so - one of the main ideas of this base class is to
> avoid dependencies to Avalon.

Ok - no enableLogging. But what about previous questions? To avoid dependency, 
switch should be made, isn't it?


> Now, today, I think even this class can be removed as it creates an
> unnecessary dependency to the module containing it. If you want to log,
> just instantiate the commons logger in your own code and use it.

But this adds a dependency on commons logging ;-)


> If you
> want to make it configurable, provide a setLogger() method like this
> abstract class does.

IMHO it is cleaner to use a base class. No need to replicate logging stuff 
everywhere - it is easier to extend from common base class (where it is possible 
/ makes sense)

Vadim

Mime
View raw message