My $0.02...
Extract LF5 and chainsaw 1.x from log4j.jar and release them as separate jars,
thus removing bloat from the Log4j library. They are not libraries, but
desktop tools, and can depend on the absolute latest version of Java for all I
care.
Log4j proper, the logging library, on the other hand, should depend upon the
minimum JVM it claims to support. Clearly whoever made those 1.4 specific
additions to TelnetAppender and NameAbbreviator weren't using proper due
diligence in developing against Java 1.3 nor testing compilation under Java
1.3.
Unless it is impossible to simulate the 1.4-specific actions using Java 1.3
API, we should make these 1.3 compatible. If it is determined that we simply
can't replicate these actions using Java 1.3, then we might as well jump to
Java 1.5. Java 1.4 isn't a significant enough improvement in capability to
warrant the new dependency. If we make the move, then lets move to something
that provides real value, and that's Java 1.5+.
Regarding building using Maven, as long as due diligence has been taken to
successfully compile at least once against Java 1.3 (using Ant or IDE), then
building under Maven and JDK1.4, or even a later JDK, should be fine for
release. Just make sure javac source/target values have been set to 1.3 (or
whatever minimum version of Java we decide we should support).
Jake
On Thu, 15 Mar 2012 15:41:12 +0100
Christian Grobmeier <grobme...@gmail.com> wrote:
Fellows,
Gary Gregory, our mate over from Commons-Land (et al) has created a new
feature:
https://issues.apache.org/bugzilla/show_bug.cgi?id=52913
I asked him if it would conform to jdk 1.3. He tested and said his
change would, but there are errors on other components. Please see
below. Basically this error says log4j is working with jdk 1.4 only.
Can anybody comment?
I would like to propose 2 things... (again):
1) drop jdk 1.3 support. It is pita. It is very unlikely that anybody
out there uses 1.3. Please lets kick it. I have not run into the error
below, I am not even sure jdk 1.3 is testable. Drop it and take 1.4 as
a minimum.
2) Optional: level release number from 1.2.16 to 1.4.0. 1.3.0 is
taken, lets bury it. 1.4 is nice, because it can be taken as indicator
for support of jdk 1.4.2. Optional, because we should try to keep bc,
just level the jdk.
3) allow reformatting of source code and others. As it seems we are
supporting 1.2.x/1.4.x a long time, we should take it serious and
improve readability. It would help lots and probably we can have some
help from other community when they look at a 21st century code
formatting.
Thoughts?
Cheers
Christian
---------- Forwarded message ----------
From: Gary Gregory <garydgreg...@gmail.com>
Date: Thu, Mar 15, 2012 at 2:25 PM
Subject: Re: Log4J patch
To: Christian Grobmeier <grobme...@gmail.com>
On Thu, Mar 15, 2012 at 5:46 AM, Christian Grobmeier
<grobme...@gmail.com> wrote:
Gary, thanks for the patch.
I have not looked at it in detail, but I am willing to commit it. My
plan is to get a release candidate done pretty soon (probably this
weekend).
One thing to know: is this patch good with jdk 1.3 (no joke)? If not I
can't patch it and you should look at log4j2.0
If you could tell me that, you would save me some time :-)
The compiler does not complain about my bit but there are other parts
of log4j that do not compile with Ant 1.6.5 and Java 1.3.1_28:
build.core:
[javac] Compiling 197 source files to
C:\svn\org\apache\log4j\trunk\dist\classes
[javac]
C:\svn\org\apache\log4j\trunk\src\main\java\org\apache\log4j\lf5\viewer\LogBrokerMonitor.java:1277:
warning: getFontList() in java.awt.Toolkit has b
een deprecated
[javac] fonts = tk.getFontList();
[javac] ^
[javac]
C:\svn\org\apache\log4j\trunk\src\main\java\org\apache\log4j\net\TelnetAppender.java:194:
cannot resolve symbol
[javac] symbol : method isClosed ()
[javac] location: class java.net.ServerSocket
[javac] while(!serverSocket.isClosed()) {
[javac] ^
[javac]
C:\svn\org\apache\log4j\trunk\src\main\java\org\apache\log4j\net\TelnetAppender.java:215:
cannot resolve symbol
[javac] symbol : method isClosed ()
[javac] location: class java.net.ServerSocket
[javac] if (!serverSocket.isClosed()) {
[javac] ^
[javac]
C:\svn\org\apache\log4j\trunk\src\main\java\org\apache\log4j\pattern\NameAbbreviator.java:230:
cannot resolve symbol
[javac] symbol : method indexOf (java.lang.String,int)
[javac] location: class java.lang.StringBuffer
[javac] for(int pos = buf.indexOf(".", nameStart);
[javac] ^
[javac]
C:\svn\org\apache\log4j\trunk\src\main\java\org\apache\log4j\pattern\NameAbbreviator.java:232:
cannot resolve symbol
[javac] symbol : method indexOf (java.lang.String,int)
[javac] location: class java.lang.StringBuffer
[javac] pos = buf.indexOf(".", pos + 1)) {
[javac] ^
[javac] 4 errors
[javac] 1 warning
I could not use Maven 2.2.1 or 3.0.4 with Java 1.3.1_28.
Running 'ant javadoc' generate 180 warnings.
...
Under Java 1.4.2_19, I get 100 javadoc warnings, 1 javadoc error and 2
compiler warnings. Then the build fails with:
Execute failed: java.io.IOException: CreateProcess: mvn site error=2
I assume because it found Maven 3.0.4. If I point MAVEN_HOME to 2.2.1
it blows up the same. With Maven 2.0.11, same problem.
Running Maven 2.0.11 on Java 1.4.2 with 'm2 clean test' shows all
sorts of errors.
At this point, I give trying with old dead Java versions.
Gary
Cheers
Christian
On Thu, Mar 15, 2012 at 2:47 AM, Gary Gregory <garydgreg...@gmail.com>
wrote:
> Hi Christian:
>
> I just created and patched
> https://issues.apache.org/bugzilla/show_bug.cgi?id=52913
>
> What do you think are the odds of getting this in 1.2.17?
>
> Thank you,
> Gary
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
