Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4714E0AB.9020107@reverycodes.com>
Date: Tue, 16 Oct 2007 12:02:51 -0400
From: Vadim Gritsenko <vadim@reverycodes.com>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: AbstractLogEnabled...
References: <4714D07D.3060402@reverycodes.com> <4714D9EB.6040902@apache.org>
In-Reply-To: <4714D9EB.6040902@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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