Log4j v1.3 Changes and New Features

NB: Log4j 1.3 development has been abandoned and no future releases or development are anticipated. See http://logging.apache.org/log4j/1.3/index.html

This page will be updated by developers to describe important changes and features in the upcoming version 1.3 of log4j. If you have any questions or comments, please post them to the log4j-user mailing list.

JDK 1.2 or later required

The decision was made that starting with v1.3, the log4j framework will require JDK 1.2 or later. Users required to use JDK 1.1 can still use the current v1.2.X. This decision was not made lightly, but most of the current Jakarta projects require JDK 1.2 or later. And there are many "modern" classes/convienences that log4j can use and take advantage of.

Joran configurator

JoranConfigurator handles (parses) config files in XML format. The intention is to have Joran to replace DOMConfigurator.

Joran does not do much for the time being. However, Ceki claims to have all the parts working in his head, he just needs to transcribe it in Java.

Joran parses files based on rules: patterns and actions. It has one advantage compared DOMConfigurator. JoranConfigurator can learn new rules at runtime without need for recompilation.

Joran is very similar to commons-digester. Joran is largely modeled after it. However, commons-digester uses commons-logging which is a no-no for a core log4j component. Other than that Joran differs from Digester in the following minor ways:

Implicit action are applied when no explicit rule applies. The action is asked to check whether it is applicable in the current context. If it says yes, then it is applied.

Plugins, Receivers, and Watchdogs...oh my!

Plugins will be added to version 1.3 and will provide a powerful mechanism for log4j users to add/extend log4j. Plugins can be configured to operate on a  LoggerRepository , and will be configurable via configuration files (at least XML). They can also be started, stopped, restarted programatically. What the plugin actually does is entirely up to the developer. A  PluginRegistry  service is provided to manage the lifetime of a plugin, starting and stopping the plugin at the appropriate points in the Plugin/ LoggerRepository  lifetime. Two uses of plugins planned for version 1.3 are Receivers and Watchdogs.

A single configuration could receive events from multiple  SocketAppender ,  SocketHubAppender , and/or  JMSAppender  sources. This will simplify the task of creating a remote logging server, and renders obsolete the  SocketServer  and  JMSSink  classes. And this is probably just the beginning. One could, for example, write a receiver to append logging events appended to the JDK 1.4 Logging API. Why would you want to? Don't know, but now you'll be able to, should the need arise. We are sure other sources will appear. Receivers will also make it much easier for the gui clients like Chainsaw and LF5 to receive logging events from multiple destinations and from appender types not yet developed. All they need is to be configured with the appropriate set of receivers in the configuration on

org.apache.log4j.filters

The new package, org.apache.log4j.filters, will either ship as part of the core v1.3 release or as part of a "sandbox" or auxiliary package. Either way, it will contain a set of useful appender filters.

All of the above classes are currently checked into the log4j cvs repository, so if you want to use/review them now, feel free.

org.apache.log4j.servlet

The new package, org.apache.log4j.servlet, will either ship as part of the core v1.3 release or as part of a "sandbox" or auxilary package. Either way, it will contain a set of useful classes that can be used in the servlet/web application environment. Currently planned/implemented are:

All of the above classes are currently checked into the log4j cvs repository, so if you want to use/review them now, feel free.

org.apache.log4j.selectors

The new package, org.apache.log4j.selectors, is an experimental package that will be provided as part of a "sandbox" or auxiliary package. The various classes will implement the  org.apache.log4j.spi.RepositorySelector  interface in various ways. These will serve as both examples to those that need to implement their own version while also providing implementations useful in web application and other development.

Packaging changes

In the v1.3 release, the Chainsaw and LF5 tools will be packaged in separate, executable jars. This will reduce the size of the core log4j jar, and separate the "required" classes from the tool/client classes.

There will also be a set of "sandbox" or auxiliary jars that will contain useful, possibly experimental, classes that log4j users can use, but the classes don't yet belong in the core log4j jar.

Chainsaw v2

Here is a screenshot of the latest build of Chainsaw v2:

Anti Rayap Atap Fiberglass Perlengkapan Bayi Outsourcing Indonesia

Log4jv13Features (last edited 2013-04-29 06:09:20 by tonyguards)