Differences between revisions 8 and 9
Revision 8 as of 2006-02-18 11:06:22
Size: 7728
Editor: 222-152-104-239
Comment: Fix spelling of Ceki Gulcu's name. Other minor fixes.
Revision 9 as of 2009-09-20 23:48:23
Size: 7749
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 34: Line 34:
 * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=31286 31286] ''[logging] Memory leaks in JBoss due to Log``Factory cache'' '''FIXED'''
 * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=32618 32618] ''[logging] Enterprise Commons Logging : Globalization & more''
 * Bug [[http://issues.apache.org/bugzilla/show_bug.cgi?id=31286|31286]] ''[logging] Memory leaks in JBoss due to Log``Factory cache'' '''FIXED'''
 * Bug [[http://issues.apache.org/bugzilla/show_bug.cgi?id=32618|32618]] ''[logging] Enterprise Commons Logging : Globalization & more''
Line 37: Line 37:
 * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=35774 35774] ''[logging] TCCL problem in J2EE Container''
 * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=36041 36041] ''[logging] Include class loader information when Log``Factory``Impl throws Log``Configuration``Exception.'' '''FIXED'''
 * Bug [[http://issues.apache.org/bugzilla/show_bug.cgi?id=35774|35774]] ''[logging] TCCL problem in J2EE Container''
 * Bug [[http://issues.apache.org/bugzilla/show_bug.cgi?id=36041|36041]] ''[logging] Include class loader information when Log``Factory``Impl throws Log``Configuration``Exception.'' '''FIXED'''
Line 40: Line 40:
 * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=36062 36062] ''[logging] extended API: getChildLogger(String)''  * Bug [[http://issues.apache.org/bugzilla/show_bug.cgi?id=36062|36062]] ''[logging] extended API: getChildLogger(String)''
Line 42: Line 42:
 * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=36927 36927] ''[logging] Disabling of TCCL'' '''Implemented, needs testing'''
 * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=37067 37067] ''[logging] enhancement : add support for ant task logger''
 * Bug [[http://issues.apache.org/bugzilla/show_bug.cgi?id=36927|36927]] ''[logging] Disabling of TCCL'' '''Implemented, needs testing'''
 * Bug [[http://issues.apache.org/bugzilla/show_bug.cgi?id=37067|37067]] ''[logging] enhancement : add support for ant task logger''
Line 45: Line 45:
 * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=37420 37420] ''[logging] Online JCL 1.0.4 API Javadoc missing''  * Bug [[http://issues.apache.org/bugzilla/show_bug.cgi?id=37420|37420]] ''[logging] Online JCL 1.0.4 API Javadoc missing''
Line 47: Line 47:
 * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=37427 37427] ''[logging] Redirect stdout and stderr to logging system''  * Bug [[http://issues.apache.org/bugzilla/show_bug.cgi?id=37427|37427]] ''[logging] Redirect stdout and stderr to logging system''
Line 49: Line 49:
 * Bug [http://issues.apache.org/bugzilla/show_bug.cgi?id=37484 37484] ''[logging] call to getClassLoader() in Log``Factory``Impl not checked for null''  * Bug [[http://issues.apache.org/bugzilla/show_bug.cgi?id=37484|37484]] ''[logging] call to getClassLoader() in Log``Factory``Impl not checked for null''
Line 133: Line 133:
Up to [:Logging] Up to [[Logging]]

Commons Logging 1.1.0 ReleasePlan

Background

This is an important release: JCL is very widely used in production but a combination of new specifications and widespread failures from vendors to adhere to the Java 2 classloading model have resulted in majors problems for the JCL 1.0.x series of releases.

Thanks to constructive criticism from Ceki Gülcü and new energy from new developers, changes have been made to the discovery model used by JCL. The current codebase is now more specification agnostic: it no longer insists on compliance with the classloader models introduced in Java 1.2 and in the servlet specification. It is believed by the team that the current codebase should solve those problems which can be solved given the design approach taken by JCL.

Status

Preparations for Alpha 1

Release Process

Most commons components use a release that uses multiple release candidates. Once the release is up to the technical standards required for Jakarta Commons releases, it is approved and released.

JCL 1.1.0 is an important release. Not only is JCL very widely used but the limitations of the 1.0.x series of releases has been widely reported. It is important that the 1.1 release not only resolves these problems but also does not introduce any new ones. It is also tricky to unit test situations involving exotic classloaders, so help from users of JCL is needed to verify that this new release works in unusual circumstances.

I'd therefore like to propose the following additions to the process. Release candidates will be produced as normal until one satisfies the standards required for commons releases. At that stage, though, the release will be dubbed commons-logging-1.1-alpha1. An announcement will be made requesting that users, developers and committers test this release. If there are no problems then a subsequent VOTE will be held to promote this release.

The release will be recut each time but no code modifications will be made without resetting the process.


Pre-Release Tasks

Anyone who wants to volunteer for a task, just add something

Documentation Review

Bug Review

  • Bug 31286 [logging] Memory leaks in JBoss due to LogFactory cache FIXED

  • Bug 32618 [logging] Enterprise Commons Logging : Globalization & more

    • IBM's (through Richard) proposal which seems too much for this release.
  • Bug 35774 [logging] TCCL problem in J2EE Container

  • Bug 36041 [logging] Include class loader information when LogFactoryImpl throws LogConfigurationException. FIXED

    • Reporter has been asked if it's OK to close this issue.
  • Bug 36062 [logging] extended API: getChildLogger(String)

    • The two Joergs have said on the dev-list that they are willing to wait until a later release with this one.
  • Bug 36927 [logging] Disabling of TCCL Implemented, needs testing

  • Bug 37067 [logging] enhancement : add support for ant task logger

    • Waiting for someone to create a patch.
  • Bug 37420 [logging] Online JCL 1.0.4 API Javadoc missing

    • This is a website issue. Someone needs to change a link. The process of copying the api-docs for a previous release should be documented, if it isn't already. FIXED

  • Bug 37427 [logging] Redirect stdout and stderr to logging system

    • Simon and Robert agrees that this should not go into commons logging. WONTFIX

  • Bug 37484 [logging] call to getClassLoader() in LogFactoryImpl not checked for null

    • Might have been solved already.

Bug Fixes

Design decisions

  • Do we remove the ServletContextCleaner?

    1. It's obviously controversial. Maybe the code could be put in the documentation somewhere, or on the wiki.
  • Decide whether to merge the weak-hash-map stuff into the main trunk or leave it in an "optional" jar. If we merge it, we can do away with the optional jar completely which is good. However it does mean that if there is a bug in it people can't disable it. If bundled in the main jar there might need to be a little extra code to just ignore it when it throws an exception on load for java < 1.3.

  • Sort out whether we split Log4JLogger into two classes or not. If we choose two classes, how should we name them?
    1. Rename Log4J12Logger.java back to Log4JLogger.java. That would make the upgrade transparent for the previous use-case. But there is the chance that this will not work at all for a user that is currently using JCL 1.0.4 together with log4jalpha-something and a configuration file stating that Log4JLogger should be used.

    2. Users who configure JCL to use Log4JLogger might reasonably expect JCL to guess the log4j version and use the correct logger. so, perhaps one option would be to create a delegating implementation.
    3. Same as #1 but kick out Log4J13Logger, because Log4J 1.3 has not been released.

  • Decide our jar distribution strategy (in particular, whether we ship the optional jar or not).
  • How do we give downstream packagers and users a fair view of the actual JCL dependencies?

Work To Resolve Design Issues

  • eliminate optional jar DONE

sub-components don't work very well. in particular, i think too many users are going to get too confused by yet another jar. WeakHashMap will go into the base distribution, other classes will be moved into contrib. perhaps another component (logging-extras) would be good or perhaps moving them off shore.

  • clean up source DONE

demonstration will be moved into contrib

  • improve support for downstream packagers

add an ant task that creates a distribution with minimal dependencies. create guide to help people understand the distribution with section on dependencies.

  • log4j loggers

log4j 1.3 is still not released. the new JCL release cannot depend on unreleased code. the 1.3 implementation will be moved into contrib. Log4JLogger and Log4J12Logger will be shipped with notes that direct use of log4jlogger is deprecated and will be replaced by a logical logger when log4j 1.3 ships.

  • ServletContextCleaner

this will be shipped. The critical issue was that projects which repackage JCL (eg by compiling with gcj) may not have an implementation of javax.servlet to compile against. However the commons-logging-api.jar project now contains all the stand-alone loggers, and this should be enough for most circumstances. Because such "repackagers" can create and distribute commons-logging-api.jar, it has been decided that it is acceptable for the commons-logging.jar to have a compile dependency on javax.servlet.

  • IoC friendly design postponed

Test Compatibility

Verify that TRACE support works for Log4J 1.2.12+. DONE

Release Notes


Release Plan

Repository

Release Notes

Approval Process

Release Candidate


Post Release

Process Bugs Marked Later


Comments


Up to Logging

Logging/1.1.0ReleasePlan (last edited 2009-09-20 23:48:23 by localhost)