{"id":13146,"date":"2014-08-18T16:06:29","date_gmt":"2014-08-18T13:06:29","guid":{"rendered":"http:\/\/examples.javacodegeeks.com\/?p=13146"},"modified":"2014-09-03T06:11:23","modified_gmt":"2014-09-03T03:11:23","slug":"log4j-log-levels-example","status":"publish","type":"post","link":"https:\/\/examples.javacodegeeks.com\/java-development\/enterprise-java\/log4j\/log4j-log-levels-example\/","title":{"rendered":"log4j – Log Levels Example"},"content":{"rendered":"

In this post, we are going to discuss about log4j<\/a><\/code> levels<\/em> and how you configure them using both log4j.properties<\/em> and log4j.xml<\/em> files.<\/p>\n

1. What is log4j?<\/h2>\n

log4j <\/strong>is a tool to help the programmer output log statements to a variety of output targets.<\/p>\n

In case of problems with an application, it is helpful to enable logging so that the problem can be located. With log4j<\/em> it is possible to enable logging at runtime without modifying the application binary. The log4j<\/em> package is designed so that log statements can remain in shipped code without incurring a high performance cost. It follows that the speed of logging (or rather not logging) is capital.<\/p>\n

At the same time, log output can be so voluminous that it quickly becomes overwhelming. One of the distinctive features of log4j<\/em> is the notion of hierarchical loggers. Using loggers it is possible to selectively control which log statements are output at arbitrary granularity.<\/p>\n

log4j<\/em> is designed with three goals in mind: reliability, speed and flexibility. There is a tight balance between these requirements. We believe that log4j strikes the right balance.<\/p>\n

log4j<\/em> has three main components: loggers<\/strong>, appenders<\/em> and layouts<\/em>. These three types of components work together to enable developers to log messages according to message type and level<\/strong>, and to control at runtime how these messages are formatted and where they are reported.<\/p>\n

1.1 What are log4j loggers?<\/h3>\n

Loggers<\/em> are named entities. Logger<\/em> names are case-sensitive and they follow the hierarchical naming rule:<\/p>\n

Named Hierarchy<\/strong><\/p>\n

A logger<\/em> is said to be an ancestor of another logger<\/em> if its name followed by a dot is a prefix of the descendant logger<\/em> name. A logger is said to be a parent of a child logger if there are no ancestors between itself and the descendant logger<\/em>.
\nFor example, the logger<\/em> named “com.foo” is a parent of the logger named “com.foo.Bar”. Similarly, “java” is a parent of “java.util” and an ancestor of “java.util.Vector”. This naming scheme should be familiar to most developers.<\/p>\n

The root logger resides at the top of the logger hierarchy. It is exceptional in two ways:<\/p>\n