|
|
|
The following paragragh was adapted from the Cactus project's roadmap with the author's permission.
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.
The workplan for log4j 1.3 is not final. It is included here to give you an idea of the future. The items are not listed in any particular order. As always, there is no scheduled release date. The lack of schedule suprises and disturbs some people. Writing good software, like good cooking, takes time. If we make you wait, it is to create a better and more reliable product.
| 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 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 | 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 | 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 | 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, 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 | 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 |