On Apr 24, 2007, at 1:50 AM, Paul Smith wrote:
Sorry about the line-endings, hopefully I did better this time. I
was able to simplify the dependencies so that only one file
(jmxtools) needs to be manually downloaded and installed to build
log4j 1.2 on Java SE 5. I added explicit specifications to target
Java 1.3 or later and only accept Java 1.3 language features. I
specified the working directory for the unit tests which allowed
things to get started, but there are a decent number of failures.
Some are due to the tests not stripping out Maven's entries in the
stack traces. I cut and pasted some of the site reporting code
from one of the plugins. I thought, but refrained, from copying
over src/site and src/changes from one of the other projects, but
I am pretty tempted to make a shot at moving to a Maven generated
site and documentation.
I can't remember what exactly used to be the case, but was the
log4j 1.2 tree supposed to work on JDK 1.1+ I noticed just as you
posted that the new constructor in LoggingEvent takes a
java.util.Map, which was introduced in JDK 1.2. I just wouldn't
want us to completely break down compatibility. But perhaps that
already happened before? I dunno. I can't see too many people
being effected by this, but it's something to keep in mind.
Wasn't intentional, but I don't think we need to change it (at least
at the moment).
The LoggingEvent methods (getProperties, getPropertyKeySet) copied
over from log4j 1.3 already used Map and Set, so it would not be
possible to compile on JDK 1.1 without changing the return types, but
the 1.1 and 1.2 javac's haven't been able to compile log4j for a long
time due to compiler bugs. I don't think that you'd get a
ClassNotFoundException unless you called one of these methods and
they aren't used internally within log4j 1.2, so it should not affect
any hypothetical JDK 1.1 user.
It does look like the new implementation of AsyncAppender (since
1.2.14) uses ArrayList and HashMap in its implementation would not
work on JDK 1.1 where the older implementation might have. Nobody
has reported it. The JDK 1.2 classes could be replaced with JDK 1.1
equivalents without changing the signature.
The only viable JDK 1.1 compatible environment is Microsoft Visual J#
and maybe it would be good to see where we are with that. I'd
suspect that you'd have to stub a lot of things out since I'm
guessing that javamail, JMS and the like aren't available for Visual
J#. If you were using Visual J#, you could use log4net.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
