THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Thanks to constructive criticism from Ceki Guici 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 adnosticagnostic: it no longer insists on complience 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 deisgn design approach taken by JCL.
Status
...
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 invovling 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.
...
- 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.
- Same as #1 but kick out Log4{{`J13}}
Logger, because Log4`J 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?
...
- Servlet{{`Context}}`Cleaner
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
...