robert burrell donkin wrote:
On Sat, 2005-11-12 at 08:05 +1300, Simon Kitching wrote:
On Thu, 2005-11-10 at 22:40 +0000, robert burrell donkin wrote:
On Thu, 2005-11-10 at 21:04 +1300, Simon Kitching wrote:
<snip>
Can a new release of CL rule out all the classloading problems
people had before?
What's currently in SVN head will probably fix 90% of the problems, and
is about 99% backwards compatible. I would love to see it released, so
that the debate could then move on to a "JCL 2.0" which I think is quite
likely to take the alternative approach described above. Oh for a few
more hours in the day!
what work's required for a release (above the actual code cutting)?
* Remove the ServletCleanupContextListener (this might not be exactly
the right class name). It's obviously too controversial. Maybe the code
could be put in the documentation somewhere, or on the wiki.
i'm +1 for the class to be distributed. my main concern was about the
best way to do this sympathetically.
IMHO the real decisions needed are:
1 our jar distribution strategy (in particular, whether we ship the
optional jar or not)
2 how we give downstream packagers and users a fair view of the actual
JCL dependencies
i'll move these two important and related issues to a separate thread.
* 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.
this is a tough call :-/
but probably want to add that code in any case
i'm learning towards distributing a more limited number of more easily
understood standard jars (more on this in the other thread). probably
need to work through the shape of the distribution first.
* Sort out whether we split Log4JLogger into two classes or not.
yep needs sorting :-/
There is one more thing to consider here. If we choose two classes, how
should we name them? This has to do with backward compatibility.
In SVN there are currently two classes named Log4J12Logger.java and
Log4J13Logger.java. In configuration terms this means that if a user
that uses a configuration file to select the logging implementation, and
wants to upgrade from JCL 1.0.4 to the new version, will need to
change their configuration. How do we feel about this? In my book that
means that the new version of JCL is not a drop-in replacement for the
previous version and would warrant it a 1.1 version number. Thoughts?
One idea would be to 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.
opinions?
I like the idea of two files. A while back I did a quick analysis of
what changes has been done in Log4J between 1.2 and 1.3. I could not
find a way to make it work with just one logging implementation file in JCL.
* Verify that TRACE support works for log4j's latest releases.
+1
volunteers?
I can help out with this.
Which versions are we talking about here? Here's a rundown of the ones
that should be considered:
1.2.6 seems to be what is required for running JCL
1.2.9 is mentioned in build.xml
1.2.12 implements trace support and is the compilation dependency
version in project.xml
1.2.13rc1 was tagged three weeks ago and contains fixes related to TRACE
level
1.3.0 is only found in build.xml but it has mention of a more specific
version. 1.3alpha-7 is the latest tag I found in Log4Js SVN.
If it were up to me I'd pick these:
1.2.6 make sure TRACE goes to debug
1.2.12 make sure TRACE goes to trace
1.3alpha-7 make sure TRACE goes to trace
What do you think?
* Consider Joerg Schaible/Joerg Hohwiller's "getChildLogger" proposal.
I'm tempted not to include this, though. Getting a release out is
probably the highest priority.
IMHO i need to be certain that everything's exactly right before i'm
willing to commit it. i was trying to work through the issues and making
sure i understood them but this went a bit quiet.
either of the two Joerg's around to advocate it's inclusion?
- robert
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
