Log4j Project

- Introduction
- Download
- Documentation
- Plan
- Wiki
- Contact us
- Contributors
- History

Jakarta (parent project)

- Home page
- News
- Mission
- Guidelines
- FAQs

Translations

- Korean
- Japanese

Plan? What plan?

> 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.

Workplan for log4j 1.3

> 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 are gradually being 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 support for extensible configuration files will be based on the code in commons-digester authored by Craig McClanahan and Scott Sanders. They graciously granted permission for the modification of their code and its inclusion in log4j.

> Ceki

> design board

> 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 `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
> Improvements to Chainsaw | Visualisation and dynamic filtering of logging event is bound to be a very important area of activity in the future. A number of important improvements to chainsaw have been suggested. | Oliver Burn | under discusison
> 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. | ? | not started
> 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. | ? | not started

> 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.

> Kevin Steppe

> not started

> 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

Workplan for log4j 1.2

> Here is workplan for the 1.2 release.

> Label | Comment | Volunteer | Status
> --- | --- | --- | ---
> More test cases | We need more automated test cases to catch bugs as early is possible.It is highly recommended to add a new test case with each new feature or component. | All committers | ongoing effort
> Removal of deprecated methods | Deprecated `setOption` and `getOption` methods in appender and layouts should be removed. | Ceki | done
> JDBCAppender | We currently have two competing JDBCAppenders: one by Thomas Fenner and the other by Kevin Steppe. Kevin Steppe stood up and did it. | Kevin Steppe | done
> Log4j in applets | In order to minimize network traffic, the size of log4j-core.jar needs to be reduced to at most 50KB. Log4jME has been released. It's less than 20KB. | Ceki | done
> Improved documentation | Log4j documentation needs to be enhanced with configuration examples and much more hand-holding. | Ceki | ongoing effort

> Mapped Diagnostic Contexts

> Mapped Diagnostic Contexts are similar to the NDC except that the MDC is a string to string map instead of a stack that the user sets when entering a special context. The `PatternLayout` has to be enhanced to support this by extending the %x pattern to accept an argument. Here is an example:

>         ConversionPattern=3D%d %p %c %x{server} %x{host} - %m%n

> User code:

>         {
>            MDC.put("server", "totoServer");
>            MDC.put("host", "someHost");

>            logger.debug("Hello");

>         }

> will print:

>     2000-01-24 10:00:00,000 DEBUG totoServer someHost - Hello

> To make MDCs truly user friendly `ThreadLocal` variables are required. This will allow the MDC to be inherited by child threads. `ThreadLocal` are only supported under JDK 1.2 and above. In JDK 1.1, the MDC will not work but won't harm the user application either.

> Ceki

> done

> Enhanced variable substitution support in DOMConfigurator |  | Ceki | done
> FallbackErrorHandler | The FallbackErrorHandler implements the ErrorHandler interface such that a secondary appender may be specified. This secondary appender takes over if the primary appender fails for whatever reason. The DOMConfigurator needs to be extended to support the FallbackErrorHandler | Ceki | implemented, requires further testing

> Ensure backward compatibility of LoggingEvent objects

> To avoid deployment problems we must ensure that LoggingEvent objects are compatible between 1.2 and 1.1.3.

> Robert Bushman has proposed a very innovative way for solving this problem. See http://www.mail-archive.com/log4j-dev@jakarta.apache.org/msg01397.html for further details.

> Ceki

> implemented, manually tested, requires automated test cases

Copyright © 1999-2003, Apache Software Foundation