log4j.properties

Thursday, February 22, 2007

Log4J Logger vs. Category

Logging is the practice of recording sequential data. This is also a low-tech method of debugging and in some cases also the only way as the proper debugging tools may not be always available or applicable. Logging in Java can range from simple System.out.println() statements to usage of sophisticated logging frameworks.

At the time of writing there are several logging frameworks for logging in Java available. There is a popular and probably the most widely used Log4J framework. Younger brother of Log4J is the Java'sLogging API that became part of Java SE in version 1.4. See How does the Java logging API stack up against log4j for comparison. The are many other logging frameworks: SimpleLog, jLo, Protomatter Syslog, etc.

There are also several frameworks that enable abstraction from logging frameworks, also known as logging bridges(Apache Commons Logging, log-bridge). These allow switching between logging frameworks. These and many others can be found at Open Source Logging Tools in Java at java-source.net.

Log4J was one of the early logging frameworks that gained popularity and is present in many source code bases. In some cases you could encounter usage of Category class rather than Logger. If you work or worked on projects that are built on top of relatively young frameworks, you may not even know that Category class exists as its natural habitat is in old Java code. I hadn't known that Category class existed until I saw it one day. I saw it in a place where I would usually use Logger class. Since that day I kept reminding myself to look at it and see what's different from Logger class and why would one use it.

So what is the difference between Category and Logger classes? The Java documentation in Category class states

This class has been deprecated and replaced by the Logger subclass. It will be kept around to preserve backward compatibility until mid 2003.

Logger is a subclass of Category, i.e. it extends Category. In other words, a logger is a category. Thus, all operations that can be performed on a category can be performed on a logger. Internally, whenever log4j is asked to produce a Category object, it will instead produce a Logger object. Log4j 1.2 will never produce Category objects but only Logger instances. In order to preserve backward compatibility, methods that previously accepted category objects still continue to accept category objects.

Then the following example shows how Category was used and how Logger should be used.

// Deprecated form:
Category cat = Category.getInstance("foo.bar");

// Preferred form for retrieving loggers:
Logger logger = Logger.getLogger("foo.bar");

And that's it. That's all you have to do to replace Category with Logger (apart from renaming the variable).

The documentation also says

There is absolutely no need for new client code to use or refer to the Category class. Whenever possible, please avoid referring to it or using it.

Why is this important? The plan is that from Log4J version 1.3 Category class will be removed! What can we do to prepare our code for Log4J 1.3? Well Preparing for Log4J version 1.3 has it all spelled out. It's worth to read if you want to understand all implications this upgrade may have. I just shamelessly paste the steps here:

Never refer to the Category class directly, refer to Logger instead.
Do not invoke the deprecated Category.getRoot method. Invoke Logger.getRootLogger method instead.
Do not invoke the deprecated Category.getInstance(String) method. InvokeLogger.getLogger(String) method instead.
Do not invoke the deprecated Category.getInstance(Class) method. InvokeLogger.getLogger(Class) method instead.
Never refer to the Priority class, refer to Level class instead.
Do not invoke the deprecated Category.setPriority(Priority) method. InvokeLogger.setLevel(Level) method instead.
Do not invoke the deprecated Priority.toPriority(int) method. Invoke Level.toLevel(int) method instead. The same holds true for the other variants of the Priority.toPriority method.
Never refer to the deprecated Priority.FATAL, Priority.ERROR, Priority.WARN,Priority.INFO, Priority.DEBUG fields. Refer to the Level.FATAL, Level.ERROR,Level.WARN, Level.INFO, Level.DEBUG fields instead.

If you confiugure appenders programmatically, do not forget to invoke the activateOptions method of an appender after you have instantiated it and set its options.

and as the above mentioned document says

For 99.99% of users, this translates to the following string find-and-replace operations:
Replace the string "Category.getInstance" with the string "Logger.getLogger".
Replace the string "Category.getRoot" with the string "Logger.getRootLogger".
Replace the string "Category" with the string "Logger".
Replace the string "Priority" with the string "Level".

Happy logging!

source - http://hanuska.blogspot.kr/2007/02/log4j-logger-vs-category.html

OSGi(Open Service Gateway initiative) (0)	2012.03.25
모델1과 모델2의 차이점 (0)	2012.03.21
디자인 패턴 (0)	2012.03.18
Refactoring (0)	2012.03.18
Struts 2 따라잡기 (0)	2010.12.26

OSGi(Open Service Gateway initiative) (0)

2012.03.25

모델1과 모델2의 차이점 (0)

2012.03.21

디자인 패턴 (0)

2012.03.18

Refactoring (0)

2012.03.18

Struts 2 따라잡기 (0)

2010.12.26