# The Roadmap

The log4j committers have adopted a roadmap for future releases of log4j. This page documents that roadmap and gives you an idea of what to expect from future versions and timeframes for release.

Our users keep inventing better ways and adding new requirements. The downside is that our todo list keeps growing. The upside is that there is plenty of work to go around. If you are interested in participating, send an email on the log4j-dev@ mailing list stating your interest. You'll be promptly enrolled. We're always looking for help! Don't be put off if in the "Volunteer" column already has a person listed. Programming is fun, especially if it is done in a team.

# Release 1.2.12

Expected timeframe: End of July, 2005

Version 1.2.12 is planned primarily as a bug fix release. It will be addressing major bugs where the fixes do not require api changes. If you have a bug or problem that you feel should be addressed, please make sure that is reported in the log4j bug database and highlight it as a candidate for the 1.2.12 release.

The log4j committers did decide to include one change in the 1.2 api for the 1.2.12 release: adding the TRACE level as a level choice with supporting methods to log messages for that level and check if the level is enabled. The change is minor and should not cause problems with existing deployments that use version 1.2.12 throughout. However, the committers reserve the right to not include it if it appears to break too much.

It is expected that version 1.2.12 will be the last release for the 1.2 branch, the next major release being version 1.3. However, if a critical bug fix is needed, another version will be released.

# Release 1.3

Expected timeframe: October, 2005

The work for version 1.3 has been ongoing for a long time now, and it is time to button it up and let others take it for a ride. Reviewing, stablizing, and testing the 1.3 code for release is the major goal for the log4j committers for this year.

Version 1.3 is going to contain some very extensive changes and new features. You should expect a number of api changes. Early release alpha versions have been available for a while, and the releases will be accelerating as the committers review and cleanup the current code base for release. As part of those releases, the committers plan to include jDiff reports that will clearly outline the changes and additions to the log4j code since the most recent 1.2.X release. This should help you in seeing what might need to be reviewed or fixed in your own code related to log4j.

Below is a table from previous documentation about the 1.3 work plan and it is somewhat out of date. The committers will be updating this page with more and better documentation about what has changed, what has been reviewed, and what tasks remain as we work toward the 1.3 release.

Label | Comment | Volunteer | Status
--- | --- | --- | ---

test cases

Writing test cases is not the most sexy part of software development but it is one of the most important. Automated test cases allow us to catch bugs as early is possible. It is strongly recommended to add a new test case with each new feature or component.

Existing Perl language based test cases have been migrated to junit (all-Java)based test cases. The new tests are placed under the `tests/` directory. It should be thus possible for participants in the project to understand the stucture of our tests and add tests for their components.

All committers

ongoing effort

Extensible XML configuration files

The DOMConfigurator is complex and not very flexible. It can only deal with elements that the developer knew about at compilation time. This has been an important drawback in the design of several appenders such as the the SMTPAppender and the RollingFileAppenders and its variants. These appenders need to delegate certain task to sub-components which are configured separately.

The new JoranConfigurator being created by Ceki Gülcü will be based on a new 'module' know as Joran, which can convert XML files into other objects based on rules. You can read more abouth Joran here

Ceki Gülcü

Significantly progressed

Log4j Domains | This is a very powerful and innovative concept that extends the notion of hierarchical loggers. It will also allow dynamic logging with pin-point accuracy. It was first suggested to me by Scott Stark of JBoss fame. | Ceki Gülcü | design board
Multiple implementations of Logger | Based on `RepositorySelectors` introduced in log4j 1.2, the user will be able to replace the `Logger` implementation. Several implementations will be provided offering different properties and functionality although none of the implementations will add new public methods. | ? | vaporware

Plugins/Receivers

A Plugin framework has been designed and implemented.

All of the currently developed plugins are "Receivers", which can be thought of as the reverse of an appender; something that accepts LoggingEvents from some external source.

This has proven particulaly useful with the log4j ports, with the addition of the XML-based Receivers able to accept LoggingEvents generated from other languages (see "Overture to other programming languages" below)

All

Significantly progressed

Improvements to Chainsaw | Chainsaw v2 development has now progressed to the point where the main developers of it and many other members of the logging community are using it daily. It's still pre-alpha but only because we keep thinking up things to add. | Scott Deboy and Paul Smith | Significantly progressed
Custom conversion characters in PatternLayout | Users often want to add new conversions characters or override the existing ones. This should be made easy using new configuration directives. This feature would use the extensions to XML configuration language mentioned above. | Ceki Gülcü | Completed, still testing

Overture to other programming languages

It is higly desriable to allow log4j ports in other languages to access log4j services in a language independent way.

The use of a standard XML format to represent a LoggingEvent has been established and many of the related logging projects from non-Java languages have begun to support it. In fact, a number of the log4j ports have volunteered to join Apache!

Scott Deboy has completed work to create a fex XML-based Receiver classes that can accept logging events from an external source, and 'import' them into the local log4j environment.

Ceki Gülcü, Scott Deboy

Significantly Progressed (if not completed)

Strategy based rollovers

Contrary to our own DailyRollingFileAppender, Avalon's logkit has a nice and clean implementation for rolling files. See the `org.apache.log.output.io.rotate` package for exact details.

Their implementation is based on strategies which are sub-components of appender. We will be able to configure such sub-components with the new XML configuration scripts.

Ceki Gülcü

Significantly Progressed

Redesign of configure and watch architecture in configurators

This is a very useful feature and the current architecture is not very good.

Contributions have been received by Mark Womack and others.

See

         http://www.mail-archive.com/log4j-dev@jakarta.apache.org/msg01390.html
         http://www.mail-archive.com/log4j-user@jakarta.apache.org/msg00666.html
         http://marc.theaimsgroup.com/?t=101010070500002&r=1&w=2

Mark Womack

initial implementation

Performance improvements to LoggingEvent serialization | Ole Dalgaard has shown that by implementing the java.io.Externalizable interface instead of java.io.Serializable in the LoggingEvent class, the speed of serialiazation is increased by a factor of 4 or more. | Ole Dalgaard? | initial implementation

Copyright © 1999-2005, Apache Software Foundation