The reasons to use Logger (or LogFactory).getLogger(getClass()):
One simple reason: If the class you are creating is a candidate for extension, you must use dynamic initialization, regardless of any abstract base class, to obtain the ability to filter appropriately on the class name.
Here's an example:
1. org.apache.xindice.util.net.NetUtility extends org.apache.util.SomeUtility
2. Both utilize the static way of logging: private static Logger logger = LogFactory.getLogger(SomeUtility.class) or LogFactory.getLogger(NetUtility.class)
3. To change the logging to debug, utilizing log4j or any other heirarchy based logging system, you must enable it for:
<category name="org.apache.util">
<priority value="debug"/>
</category>
<category name="org.apache.xindice.util">
<priority value="debug"/>
</category>
This goes on and on for each class in the heirarchy, and can be quite a pain to figure out when you are just trying to debug something simple.
I recognize that the commons-logging folks recommend it, but just because it is published, doesn't mean that this is the best way to do it. If that's the philosophy, why not use an RDBMS? ;-)
-Kevin Ross
Vladimir R. Bossicard wrote:
public class AbstractLoggable{ protected Logger getLogger(){ } }and how am I supposed to use this class? According to the name "Loggable", a class willing to use a logger should extend the AbstractLoggable class, right?As a big OO fan, I can see the advantage of this approach, but AFAIK Java only supports single extension. Should I work with mock objects in classes that already extend a base class? Last question: why should we need this solution when the current one: - works fine (and nobody cares as long as it works) - is used by tons of other projects - is recommended by the Commons-Logging folks -Vladimir -- Vladimir R. Bossicard Apache Xindice - http://xml.apache.org/xindice
