Page History

...

• Do we remove the Servlet{{`Context}}`Cleaner?
  1. 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?
  1. 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.
  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.
     
• 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
  

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.

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

1 ServletContextCleaner this will be shipped

1 IoC friendly design postponed

Test Compatibility

Verify that TRACE support works for Log4J 1.2.12+. DONE

...