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
