THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Wiki Markup Bug 31286 _\[logging\] Memory leaks in JBoss due to LogFactory cache_
Wiki Markup Bug 32618 _\[logging\] Enterprise Commons Logging : Globalization & more_
- IBM's (through Richard) proposal which seems too much for this release.
Wiki Markup Bug 35774 _\[logging\] TCCL problem in J2EE Container_
Wiki Markup Bug 36041 _\[logging\] Include class loader information when Log{{`Factory}}{{Impl throws Log}}{{Configuration}}`Exception._- Reporter has been asked if it's OK to close this issue.
Wiki Markup 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.
Wiki Markup Bug 36927 _\[logging\] Disabling of TCCL_
Wiki Markup Bug 37067 _\[logging\] enhancement : add support for ant task logger_
- Waiting for someone to create a patch.
Wiki Markup 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.
Wiki Markup Bug 37427 _\[logging\] Redirect stdout and stderr to logging system_
- Simon and Robert agrees that this should not go into commons logging.
Wiki Markup Bug 37484 _\[logging\] call to getClassLoader() in Log{{`Factory}}`Impl not checked for null_- Might have been solved already.
- Might have been solved already.
Bug
...
Fixes
Design decisions
- Do we remove the Servlet{{`Context}}`Cleaner?
- It's obviously too controversial. Maybe the code could be put in the documentation somewhere, or on the wiki.
- It's obviously too 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?
- Rename Log4{{`J12}}`Logger.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.
- 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.
- 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?
Test Compatibility
Verify that trace level logging works correctly with TRACE support works for Log4J 1.2.12+. DONE
Release Notes
...