|
|
|
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.
Expected timeframe: None
No more releases on the 1.2.X codebase are currently planned. Efforts will now be focused on getting the 1.3 version shipped. However, if a critical bug fix is needed, another version will be released.
Expected timeframe: mid 2006
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
|
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 |
? | 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
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 |