You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Curt Arnold <ca...@apache.org> on 2005/08/20 04:25:40 UTC
Yet another release candidate
I've posted an log4j 1.2.12 release candidate log4j-1.2.12rc4 to
http://people.apache.org/~carnold/logging-log4j-1.2.12rc4.zip and
http://people.apache.org/~carnold/logging-log4j-1.2.12rc4.tar.gz.
This is not explicitly not an official release and should not be used
for anything other than test in preparation of the eventual
log4j-1.2.12. Since I hope we are getting close to a real release,
this RC has no internal markers that it is not a release and if
accepted as the release after an appropriate vote (which I'm not
calling for), the archives could simply be renamed and signed. The
CVS for logging-cvs and logging-site have been tagged with v1_2_12_rc4.
The major different between rc4 and the previous rc3 and rcTEST-
jdk1.2 is that this rc4 was build with JDK 1.3 (Sun JDK 1.3.1_15 on
Windows 2000 to be more specific). I've been a better part of the
last two days building and rebuilding log4j distributions on multiple
JDK's on clean virtual machines and comparing them with previous
releases and running them on earlier JVM's. I think JDK 1.3 is the
right answer.
There is no explicit statement on the compilers used to prepare
earlier editions of log4j and the class files do not provide any
obvious clues to the compiler that emitted them. There are two
distinguishing characteristics in the generated Javadoc that allow
you to reasonably determine the version of javadoc used. JDK 1.2 and
1.3 generated Javadoc use "frameset.dtd", JDK 1.4 and later use
"loose.dtd". JDK 1.2 uses <FONT ID="..."> to specify a font, and JDK
1.3 and later use <FONT CLASS="...">. These clues suggest
log4j-1.2.9 and 1.2.5 were both built with a JDK 1.3 and that
log4j-1.2.11 was built with a JDK 1.4.
The JIT error that has been annoying us lately seems to be specific
to JDK 1.4 and later compilers. With the recent modifications, log4j
can be built and tested (on the same JDK) using any version from 1.2
to 1.5. Building on 1.2 requires rebuilding apache-ant-1.6.5 since
it seems to have also been build with a JDK 1.4 compiler.
The JDK 1.2 and 1.3 builds could be successfully tested with a subset
of the unit tests on JDK 1.1. Neither Ant 1.6.x or jakarta-oro
support JDK 1.1. To work around this a batch file was created to run
a subset of the tests that would have been run by tests/build.xml.
jakarta-oro only used JDK 1.2 specific classes and substituting
Hashtable for HashMap and Vector for ArrayList and rebuilding (again
using JDK 1.3) was sufficient to run the unit tests.
A few unit tests are known and expected to fail on JDK 1.1.
LevelTest.testDeserializeINFO will fail since the readResolve method
that replaces the freshly created level object with the Level.INFO is
not invoked. FileAppenderTest.testDirectoryCreation also fails which
suggest that log4j will not be able to create missing directories
when running on JDK 1.1. Also, tests involving the MDC will fail on
JDK 1.1 since MDC is JDK 1.2 specific.
http://people.apache.org/~carnold/rcTEST_vs_rc4.txt contains a diff
of rc4 with rcTEST-jdk1.2 (omitting Javadoc differences) and is
fairly short. Most of the recent changes were in the test suite
which is not included in the distribution.
build.properties.sample was update to reflect currently available
versions of support jars.
build.xml had the "release" target and javac.* properties added.
All the example/*.class are different. The jars are named
differently (and I expect are different internally).
docs/HISTORY.txt has a speculative release date for 1.2.12 of next
Friday. I've also removed the "release" notices for the earlier
rcs. Since they will not be available in the archives, I don't think
it has much value to describe a distribution that is not available.
In addition, "release" is inappropriate to describe the earlier rcs
since none of them were ever accepted as a LS release. You could say
"prepared" or something like that, if they must be mentioned.
A link to FAQ.html was fixed.
The LF5 documentation that was in log4j-1.2.9 was restored.
log4j-1.2.11 and the 1.2.12rcs had the LF5 graphics but not the HTML
pages. build.xml did not rebuild the LF5 document, but did not clean
it either, so I'm guessing that it was using stale copies from a
previous build.
A broken link to chainsaw.html was replaced to a link to http://
logging.apache.org.
rcTEST had reverted the CategoryKey changes which I assume was a
production artifact.
The missing directory creation in FileAppender did not check that the
getParent() was not null. This caused a NullPointerException in JDK
1.1 in the unit tests. The same fix needs to be propagated to the
CVS HEAD.
The change in LoggerRepository avoids a Jikes compiler bug. I had
not intended to commit the change but compiling under Jikes is a good
thing to support.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Yet another release candidate
Posted by Mark Womack <mw...@apache.org>.
I set up my environment to use jdk 1.3.1_16 and all of the jars listed in
the new build.properties.sample. I did a build locally (rc4+) and then
diff'd the result with Curt's rc4.
Only differences of note (beyond the javadoc timestamps) were:
1) The build.xml changes to fix the jmx issue Curt found after building his
rc4.
2) Some linefeed differences in the example java files.
3) And a difference in the CategoryKey.java file around the fix applied to
remove the String.intern() call. I believe that my current version from cvs
is the correct version. Not sure what was up with your version, Curt?
diff -r logging-log4j-1.2.12rc4/src/java/org/apache/log4j/CategoryKey.java
logging-log4j-1.2.12rc4+/src/java/org/apache/log4j/CategoryKey.java
20c20,21
< CategoryKey is heavily used internally to accelerate hash table
searches.
---
> CategoryKey is a wrapper for String that apparently accellerated
> hash table lookup in early JVM's.
29c30
< this.name = name.intern();
---
> this.name = name;
46c47
< return name == ((CategoryKey)rArg ).name;
---
> return name.equals(((CategoryKey)rArg ).name);
I would say that we are good to go for an rc5 (and hopefully last rc for the
1.2.12 release).
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: Yet another release candidate
Posted by Mark Womack <wo...@adobe.com>.
Curt,
Thanks for all of this hard work around this. I want to try this out on my
machine, so I may have some comments and questions after this evening.
-Mark
> -----Original Message-----
> From: Curt Arnold [mailto:carnold@apache.org]
> Sent: Friday, August 19, 2005 7:26 PM
> To: Log4J Developers List
> Subject: Yet another release candidate
>
> I've posted an log4j 1.2.12 release candidate log4j-1.2.12rc4 to
> http://people.apache.org/~carnold/logging-log4j-1.2.12rc4.zip and
> http://people.apache.org/~carnold/logging-log4j-1.2.12rc4.tar.gz.
> This is not explicitly not an official release and should not be used
> for anything other than test in preparation of the eventual
> log4j-1.2.12. Since I hope we are getting close to a real release,
> this RC has no internal markers that it is not a release and if
> accepted as the release after an appropriate vote (which I'm not
> calling for), the archives could simply be renamed and signed. The
> CVS for logging-cvs and logging-site have been tagged with v1_2_12_rc4.
>
> The major different between rc4 and the previous rc3 and rcTEST-
> jdk1.2 is that this rc4 was build with JDK 1.3 (Sun JDK 1.3.1_15 on
> Windows 2000 to be more specific). I've been a better part of the
> last two days building and rebuilding log4j distributions on multiple
> JDK's on clean virtual machines and comparing them with previous
> releases and running them on earlier JVM's. I think JDK 1.3 is the
> right answer.
>
> There is no explicit statement on the compilers used to prepare
> earlier editions of log4j and the class files do not provide any
> obvious clues to the compiler that emitted them. There are two
> distinguishing characteristics in the generated Javadoc that allow
> you to reasonably determine the version of javadoc used. JDK 1.2 and
> 1.3 generated Javadoc use "frameset.dtd", JDK 1.4 and later use
> "loose.dtd". JDK 1.2 uses <FONT ID="..."> to specify a font, and JDK
> 1.3 and later use <FONT CLASS="...">. These clues suggest
> log4j-1.2.9 and 1.2.5 were both built with a JDK 1.3 and that
> log4j-1.2.11 was built with a JDK 1.4.
>
> The JIT error that has been annoying us lately seems to be specific
> to JDK 1.4 and later compilers. With the recent modifications, log4j
> can be built and tested (on the same JDK) using any version from 1.2
> to 1.5. Building on 1.2 requires rebuilding apache-ant-1.6.5 since
> it seems to have also been build with a JDK 1.4 compiler.
>
> The JDK 1.2 and 1.3 builds could be successfully tested with a subset
> of the unit tests on JDK 1.1. Neither Ant 1.6.x or jakarta-oro
> support JDK 1.1. To work around this a batch file was created to run
> a subset of the tests that would have been run by tests/build.xml.
> jakarta-oro only used JDK 1.2 specific classes and substituting
> Hashtable for HashMap and Vector for ArrayList and rebuilding (again
> using JDK 1.3) was sufficient to run the unit tests.
>
> A few unit tests are known and expected to fail on JDK 1.1.
> LevelTest.testDeserializeINFO will fail since the readResolve method
> that replaces the freshly created level object with the Level.INFO is
> not invoked. FileAppenderTest.testDirectoryCreation also fails which
> suggest that log4j will not be able to create missing directories
> when running on JDK 1.1. Also, tests involving the MDC will fail on
> JDK 1.1 since MDC is JDK 1.2 specific.
>
> http://people.apache.org/~carnold/rcTEST_vs_rc4.txt contains a diff
> of rc4 with rcTEST-jdk1.2 (omitting Javadoc differences) and is
> fairly short. Most of the recent changes were in the test suite
> which is not included in the distribution.
>
> build.properties.sample was update to reflect currently available
> versions of support jars.
>
> build.xml had the "release" target and javac.* properties added.
>
> All the example/*.class are different. The jars are named
> differently (and I expect are different internally).
>
> docs/HISTORY.txt has a speculative release date for 1.2.12 of next
> Friday. I've also removed the "release" notices for the earlier
> rcs. Since they will not be available in the archives, I don't think
> it has much value to describe a distribution that is not available.
> In addition, "release" is inappropriate to describe the earlier rcs
> since none of them were ever accepted as a LS release. You could say
> "prepared" or something like that, if they must be mentioned.
>
> A link to FAQ.html was fixed.
>
> The LF5 documentation that was in log4j-1.2.9 was restored.
> log4j-1.2.11 and the 1.2.12rcs had the LF5 graphics but not the HTML
> pages. build.xml did not rebuild the LF5 document, but did not clean
> it either, so I'm guessing that it was using stale copies from a
> previous build.
>
> A broken link to chainsaw.html was replaced to a link to http://
> logging.apache.org.
>
> rcTEST had reverted the CategoryKey changes which I assume was a
> production artifact.
>
> The missing directory creation in FileAppender did not check that the
> getParent() was not null. This caused a NullPointerException in JDK
> 1.1 in the unit tests. The same fix needs to be propagated to the
> CVS HEAD.
>
> The change in LoggerRepository avoids a Jikes compiler bug. I had
> not intended to commit the change but compiling under Jikes is a good
> thing to support.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org