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 Christian Grobmeier <gr...@gmail.com> on 2012/03/15 15:41:12 UTC
Jdk 1.3 fails, lets upgrade to jdk 1.4. && Maintenance
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 <ga...@gmail.com>
Date: Thu, Mar 15, 2012 at 2:25 PM
Subject: Re: Log4J patch
To: Christian Grobmeier <gr...@gmail.com>
On Thu, Mar 15, 2012 at 5:46 AM, Christian Grobmeier
<gr...@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 <ga...@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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Jdk 1.3 fails, lets upgrade to jdk 1.4. && Maintenance
Posted by Christian Grobmeier <gr...@gmail.com>.
On Fri, Mar 16, 2012 at 1:58 AM, Ralph Goers <ra...@dslextreme.com> wrote:
> I'm indifferent on this issue except I really don't think much time should be invested in Log4j 1.x and, of course, I would like to see most of the energy focused on 2.0. While minor issues can and should be addressed, I would like to have an alpha release of Log4j2 as soon as the build and web site can allow it. That will be my primary focus over the coming weeks.
I fully understand this and we should make sure that people know log4j
2.0 is the way to go. But we still have to maintain log4j 1 series...
it will take ages until 1-users will migrate to 2-series.
The fix i made recently was a memory leak (which is only fixable for
1.4 onwards). Guess this should be done. When the maintainer has some
time to clean up I think this is fine.
Anyway, can we discuss a roadmap of log4j2 in a second thread? Can you
take the initiative here?
>
> Ralph
>
> On Mar 15, 2012, at 5:34 PM, Tushar Kapila wrote:
>
>> +1 Love to see new log 4j with java 1.4 or 1.5 is fine. We do bank
>> apps (3d secure) but good automated and human testing gave us
>> confidence to use java 6. Even fixed a socket issue we had with 4 and
>> 5. I know of our bank customers in India use 1.5 too.
>> And for laggers can do smaller fixes.
>>
>> On 2012-03-16, Jacob Kjome <ho...@visi.com> wrote:
>>>
>>> I'll +1 the move to 1.4, if that's what's deemed necessary. I accept your
>>> arguments that the advantages of moving to Java 1.4 are significant enough
>>> to
>>> be worth it while maintaining compatibility with older environments that
>>> are,
>>> most likely, at least Java 1.4 these days. And Java 1.3 users can just
>>> continue to use the older releases (or upgrade their environment).
>>>
>>> Unless someone else objects, go ahead with the changes (ideally with lf4 and
>>> chainsaw 1.x moved to separate jars, if that's not too much trouble).
>>>
>>>
>>> Jake
>>>
>>> On Thu, 15 Mar 2012 15:14:29 -0400
>>> Gary Gregory <gg...@apache.org> wrote:
>>>> On Thu, Mar 15, 2012 at 3:04 PM, Christian Grobmeier
>>>> <gr...@gmail.com>wrote:
>>>>
>>>>> On Thu, Mar 15, 2012 at 5:58 PM, Jacob Kjome <ho...@visi.com> wrote:
>>>>>> 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.
>>>>>
>>>>> +1... honestly I did not knew it was build into this jar
>>>>>
>>>>>> 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+.
>>>>>
>>>>> i have tried to bump jdk requirement to 1.5 before a while. The answer
>>>>> was: we have log4j 2.0, lets stick with an older jdk for 1.2 series. I
>>>>> am ok with that, just think, we really don't need 1.3 anymore.
>>>>>
>>>>> Example: the latest patch I applied needed some tunings... for example
>>>>> I needed to check if a specific method is avail (via reflection).
>>>>> Annoying enough. But this fix will not work for jdk 1.3, because there
>>>>> is no such a method. And now all jdk 1.3 users are suffering from a
>>>>> memory leak which is likely never fixed. That being said, if we decide
>>>>> to drop 1.3 but want to support oldschoolers, the next option is 1.4.
>>>>> I think 1.4 is really old enough to even support banks.
>>>>>
>>>>
>>>> Recall that no one is forcing anyone to upgrade to 1.4.
>>>>
>>>> If I want to use a new version of a jar, it comes with label that says "my
>>>> requirements are...".
>>>>
>>>> If I want a bug fix in 1.2.x bad enough, I'll submit a patch for it and
>>>> either hope for a release or do one internally for my app.
>>>>
>>>> If we do a Log4J 1.4 that requires Java 4/5/6, then that is quite fine
>>>> with
>>>> me.
>>>>
>>>> In the case of Log4J 2.0, it's not out yet and I see no indication of when
>>>> that will happen.
>>>>
>>>> Right now, I am patching 1.2.x, it is a real release that can be moved
>>>> along, little by little, as we see fit.
>>>>
>>>> Gary
>>>>
>>>>
>>>>>
>>>>> Anyway, I would be glad to go with 1.5 of course. Its just, we have
>>>>> log4j2 which supports 1.5 and it would be good that people use that,
>>>>> when they have 1.5.
>>>>>
>>>>> Cheers
>>>>> Christian
>>>>>
>>>>>>
>>>>>>
>>>>>> Jake
>>>>>>
>>>>>>
>>>>>> On Thu, 15 Mar 2012 15:41:12 +0100
>>>>>> Christian Grobmeier <gr...@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 <ga...@gmail.com>
>>>>>>> Date: Thu, Mar 15, 2012 at 2:25 PM
>>>>>>> Subject: Re: Log4J patch
>>>>>>> To: Christian Grobmeier <gr...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Mar 15, 2012 at 5:46 AM, Christian Grobmeier
>>>>>>> <gr...@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
>>>>>>>> <ga...@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-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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://www.grobmeier.de
>>>>> https://www.timeandbill.de
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>>>> Spring Batch in Action: http://bit.ly/bqpbCK
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>>
>>
>> --
>> Sent from my mobile device
>>
>> Regards
>> Tushar Kapila
>>
>> ---------------------------------------------------------------------
>> 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
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Jdk 1.3 fails, lets upgrade to jdk 1.4. && Maintenance
Posted by Gary Gregory <gg...@apache.org>.
Make it java 5.0 and use generics in code like: Logger.getRootLogger().
getAllAppenders();
Gary
On Thu, Mar 15, 2012 at 8:58 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> I'm indifferent on this issue except I really don't think much time should
> be invested in Log4j 1.x and, of course, I would like to see most of the
> energy focused on 2.0. While minor issues can and should be addressed, I
> would like to have an alpha release of Log4j2 as soon as the build and web
> site can allow it. That will be my primary focus over the coming weeks.
>
> Ralph
>
> On Mar 15, 2012, at 5:34 PM, Tushar Kapila wrote:
>
> > +1 Love to see new log 4j with java 1.4 or 1.5 is fine. We do bank
> > apps (3d secure) but good automated and human testing gave us
> > confidence to use java 6. Even fixed a socket issue we had with 4 and
> > 5. I know of our bank customers in India use 1.5 too.
> > And for laggers can do smaller fixes.
> >
> > On 2012-03-16, Jacob Kjome <ho...@visi.com> wrote:
> >>
> >> I'll +1 the move to 1.4, if that's what's deemed necessary. I accept
> your
> >> arguments that the advantages of moving to Java 1.4 are significant
> enough
> >> to
> >> be worth it while maintaining compatibility with older environments that
> >> are,
> >> most likely, at least Java 1.4 these days. And Java 1.3 users can just
> >> continue to use the older releases (or upgrade their environment).
> >>
> >> Unless someone else objects, go ahead with the changes (ideally with
> lf4 and
> >> chainsaw 1.x moved to separate jars, if that's not too much trouble).
> >>
> >>
> >> Jake
> >>
> >> On Thu, 15 Mar 2012 15:14:29 -0400
> >> Gary Gregory <gg...@apache.org> wrote:
> >>> On Thu, Mar 15, 2012 at 3:04 PM, Christian Grobmeier
> >>> <gr...@gmail.com>wrote:
> >>>
> >>>> On Thu, Mar 15, 2012 at 5:58 PM, Jacob Kjome <ho...@visi.com> wrote:
> >>>>> 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.
> >>>>
> >>>> +1... honestly I did not knew it was build into this jar
> >>>>
> >>>>> 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+.
> >>>>
> >>>> i have tried to bump jdk requirement to 1.5 before a while. The answer
> >>>> was: we have log4j 2.0, lets stick with an older jdk for 1.2 series. I
> >>>> am ok with that, just think, we really don't need 1.3 anymore.
> >>>>
> >>>> Example: the latest patch I applied needed some tunings... for example
> >>>> I needed to check if a specific method is avail (via reflection).
> >>>> Annoying enough. But this fix will not work for jdk 1.3, because there
> >>>> is no such a method. And now all jdk 1.3 users are suffering from a
> >>>> memory leak which is likely never fixed. That being said, if we decide
> >>>> to drop 1.3 but want to support oldschoolers, the next option is 1.4.
> >>>> I think 1.4 is really old enough to even support banks.
> >>>>
> >>>
> >>> Recall that no one is forcing anyone to upgrade to 1.4.
> >>>
> >>> If I want to use a new version of a jar, it comes with label that says
> "my
> >>> requirements are...".
> >>>
> >>> If I want a bug fix in 1.2.x bad enough, I'll submit a patch for it and
> >>> either hope for a release or do one internally for my app.
> >>>
> >>> If we do a Log4J 1.4 that requires Java 4/5/6, then that is quite fine
> >>> with
> >>> me.
> >>>
> >>> In the case of Log4J 2.0, it's not out yet and I see no indication of
> when
> >>> that will happen.
> >>>
> >>> Right now, I am patching 1.2.x, it is a real release that can be moved
> >>> along, little by little, as we see fit.
> >>>
> >>> Gary
> >>>
> >>>
> >>>>
> >>>> Anyway, I would be glad to go with 1.5 of course. Its just, we have
> >>>> log4j2 which supports 1.5 and it would be good that people use that,
> >>>> when they have 1.5.
> >>>>
> >>>> Cheers
> >>>> Christian
> >>>>
> >>>>>
> >>>>>
> >>>>> Jake
> >>>>>
> >>>>>
> >>>>> On Thu, 15 Mar 2012 15:41:12 +0100
> >>>>> Christian Grobmeier <gr...@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 <ga...@gmail.com>
> >>>>>> Date: Thu, Mar 15, 2012 at 2:25 PM
> >>>>>> Subject: Re: Log4J patch
> >>>>>> To: Christian Grobmeier <gr...@gmail.com>
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Mar 15, 2012 at 5:46 AM, Christian Grobmeier
> >>>>>> <gr...@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
> >>>>>>> <ga...@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-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
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> http://www.grobmeier.de
> >>>> https://www.timeandbill.de
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> >>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> >>> Spring Batch in Action: http://bit.ly/bqpbCK
> >>> Blog: http://garygregory.wordpress.com
> >>> Home: http://garygregory.com/
> >>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>
> >>
> >
> > --
> > Sent from my mobile device
> >
> > Regards
> > Tushar Kapila
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
Re: Jdk 1.3 fails, lets upgrade to jdk 1.4. && Maintenance
Posted by Ralph Goers <ra...@dslextreme.com>.
I'm indifferent on this issue except I really don't think much time should be invested in Log4j 1.x and, of course, I would like to see most of the energy focused on 2.0. While minor issues can and should be addressed, I would like to have an alpha release of Log4j2 as soon as the build and web site can allow it. That will be my primary focus over the coming weeks.
Ralph
On Mar 15, 2012, at 5:34 PM, Tushar Kapila wrote:
> +1 Love to see new log 4j with java 1.4 or 1.5 is fine. We do bank
> apps (3d secure) but good automated and human testing gave us
> confidence to use java 6. Even fixed a socket issue we had with 4 and
> 5. I know of our bank customers in India use 1.5 too.
> And for laggers can do smaller fixes.
>
> On 2012-03-16, Jacob Kjome <ho...@visi.com> wrote:
>>
>> I'll +1 the move to 1.4, if that's what's deemed necessary. I accept your
>> arguments that the advantages of moving to Java 1.4 are significant enough
>> to
>> be worth it while maintaining compatibility with older environments that
>> are,
>> most likely, at least Java 1.4 these days. And Java 1.3 users can just
>> continue to use the older releases (or upgrade their environment).
>>
>> Unless someone else objects, go ahead with the changes (ideally with lf4 and
>> chainsaw 1.x moved to separate jars, if that's not too much trouble).
>>
>>
>> Jake
>>
>> On Thu, 15 Mar 2012 15:14:29 -0400
>> Gary Gregory <gg...@apache.org> wrote:
>>> On Thu, Mar 15, 2012 at 3:04 PM, Christian Grobmeier
>>> <gr...@gmail.com>wrote:
>>>
>>>> On Thu, Mar 15, 2012 at 5:58 PM, Jacob Kjome <ho...@visi.com> wrote:
>>>>> 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.
>>>>
>>>> +1... honestly I did not knew it was build into this jar
>>>>
>>>>> 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+.
>>>>
>>>> i have tried to bump jdk requirement to 1.5 before a while. The answer
>>>> was: we have log4j 2.0, lets stick with an older jdk for 1.2 series. I
>>>> am ok with that, just think, we really don't need 1.3 anymore.
>>>>
>>>> Example: the latest patch I applied needed some tunings... for example
>>>> I needed to check if a specific method is avail (via reflection).
>>>> Annoying enough. But this fix will not work for jdk 1.3, because there
>>>> is no such a method. And now all jdk 1.3 users are suffering from a
>>>> memory leak which is likely never fixed. That being said, if we decide
>>>> to drop 1.3 but want to support oldschoolers, the next option is 1.4.
>>>> I think 1.4 is really old enough to even support banks.
>>>>
>>>
>>> Recall that no one is forcing anyone to upgrade to 1.4.
>>>
>>> If I want to use a new version of a jar, it comes with label that says "my
>>> requirements are...".
>>>
>>> If I want a bug fix in 1.2.x bad enough, I'll submit a patch for it and
>>> either hope for a release or do one internally for my app.
>>>
>>> If we do a Log4J 1.4 that requires Java 4/5/6, then that is quite fine
>>> with
>>> me.
>>>
>>> In the case of Log4J 2.0, it's not out yet and I see no indication of when
>>> that will happen.
>>>
>>> Right now, I am patching 1.2.x, it is a real release that can be moved
>>> along, little by little, as we see fit.
>>>
>>> Gary
>>>
>>>
>>>>
>>>> Anyway, I would be glad to go with 1.5 of course. Its just, we have
>>>> log4j2 which supports 1.5 and it would be good that people use that,
>>>> when they have 1.5.
>>>>
>>>> Cheers
>>>> Christian
>>>>
>>>>>
>>>>>
>>>>> Jake
>>>>>
>>>>>
>>>>> On Thu, 15 Mar 2012 15:41:12 +0100
>>>>> Christian Grobmeier <gr...@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 <ga...@gmail.com>
>>>>>> Date: Thu, Mar 15, 2012 at 2:25 PM
>>>>>> Subject: Re: Log4J patch
>>>>>> To: Christian Grobmeier <gr...@gmail.com>
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 15, 2012 at 5:46 AM, Christian Grobmeier
>>>>>> <gr...@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
>>>>>>> <ga...@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-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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.grobmeier.de
>>>> https://www.timeandbill.de
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>>> Spring Batch in Action: http://bit.ly/bqpbCK
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>
> --
> Sent from my mobile device
>
> Regards
> Tushar Kapila
>
> ---------------------------------------------------------------------
> 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
Re: Jdk 1.3 fails, lets upgrade to jdk 1.4. && Maintenance
Posted by Tushar Kapila <tg...@gmail.com>.
+1 Love to see new log 4j with java 1.4 or 1.5 is fine. We do bank
apps (3d secure) but good automated and human testing gave us
confidence to use java 6. Even fixed a socket issue we had with 4 and
5. I know of our bank customers in India use 1.5 too.
And for laggers can do smaller fixes.
On 2012-03-16, Jacob Kjome <ho...@visi.com> wrote:
>
> I'll +1 the move to 1.4, if that's what's deemed necessary. I accept your
> arguments that the advantages of moving to Java 1.4 are significant enough
> to
> be worth it while maintaining compatibility with older environments that
> are,
> most likely, at least Java 1.4 these days. And Java 1.3 users can just
> continue to use the older releases (or upgrade their environment).
>
> Unless someone else objects, go ahead with the changes (ideally with lf4 and
> chainsaw 1.x moved to separate jars, if that's not too much trouble).
>
>
> Jake
>
> On Thu, 15 Mar 2012 15:14:29 -0400
> Gary Gregory <gg...@apache.org> wrote:
>> On Thu, Mar 15, 2012 at 3:04 PM, Christian Grobmeier
>><gr...@gmail.com>wrote:
>>
>>> On Thu, Mar 15, 2012 at 5:58 PM, Jacob Kjome <ho...@visi.com> wrote:
>>> > 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.
>>>
>>> +1... honestly I did not knew it was build into this jar
>>>
>>> > 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+.
>>>
>>> i have tried to bump jdk requirement to 1.5 before a while. The answer
>>> was: we have log4j 2.0, lets stick with an older jdk for 1.2 series. I
>>> am ok with that, just think, we really don't need 1.3 anymore.
>>>
>>> Example: the latest patch I applied needed some tunings... for example
>>> I needed to check if a specific method is avail (via reflection).
>>> Annoying enough. But this fix will not work for jdk 1.3, because there
>>> is no such a method. And now all jdk 1.3 users are suffering from a
>>> memory leak which is likely never fixed. That being said, if we decide
>>> to drop 1.3 but want to support oldschoolers, the next option is 1.4.
>>> I think 1.4 is really old enough to even support banks.
>>>
>>
>> Recall that no one is forcing anyone to upgrade to 1.4.
>>
>> If I want to use a new version of a jar, it comes with label that says "my
>> requirements are...".
>>
>> If I want a bug fix in 1.2.x bad enough, I'll submit a patch for it and
>> either hope for a release or do one internally for my app.
>>
>> If we do a Log4J 1.4 that requires Java 4/5/6, then that is quite fine
>> with
>> me.
>>
>> In the case of Log4J 2.0, it's not out yet and I see no indication of when
>> that will happen.
>>
>> Right now, I am patching 1.2.x, it is a real release that can be moved
>> along, little by little, as we see fit.
>>
>> Gary
>>
>>
>>>
>>> Anyway, I would be glad to go with 1.5 of course. Its just, we have
>>> log4j2 which supports 1.5 and it would be good that people use that,
>>> when they have 1.5.
>>>
>>> Cheers
>>> Christian
>>>
>>> >
>>> >
>>> > Jake
>>> >
>>> >
>>> > On Thu, 15 Mar 2012 15:41:12 +0100
>>> > Christian Grobmeier <gr...@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 <ga...@gmail.com>
>>> >> Date: Thu, Mar 15, 2012 at 2:25 PM
>>> >> Subject: Re: Log4J patch
>>> >> To: Christian Grobmeier <gr...@gmail.com>
>>> >>
>>> >>
>>> >> On Thu, Mar 15, 2012 at 5:46 AM, Christian Grobmeier
>>> >> <gr...@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
>>> >>> <ga...@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-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
>>> >
>>>
>>>
>>>
>>> --
>>> http://www.grobmeier.de
>>> https://www.timeandbill.de
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
Sent from my mobile device
Regards
Tushar Kapila
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Jdk 1.3 fails, lets upgrade to jdk 1.4. && Maintenance
Posted by Jacob Kjome <ho...@visi.com>.
I'll +1 the move to 1.4, if that's what's deemed necessary. I accept your
arguments that the advantages of moving to Java 1.4 are significant enough to
be worth it while maintaining compatibility with older environments that are,
most likely, at least Java 1.4 these days. And Java 1.3 users can just
continue to use the older releases (or upgrade their environment).
Unless someone else objects, go ahead with the changes (ideally with lf4 and
chainsaw 1.x moved to separate jars, if that's not too much trouble).
Jake
On Thu, 15 Mar 2012 15:14:29 -0400
Gary Gregory <gg...@apache.org> wrote:
> On Thu, Mar 15, 2012 at 3:04 PM, Christian Grobmeier
><gr...@gmail.com>wrote:
>
>> On Thu, Mar 15, 2012 at 5:58 PM, Jacob Kjome <ho...@visi.com> wrote:
>> > 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.
>>
>> +1... honestly I did not knew it was build into this jar
>>
>> > 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+.
>>
>> i have tried to bump jdk requirement to 1.5 before a while. The answer
>> was: we have log4j 2.0, lets stick with an older jdk for 1.2 series. I
>> am ok with that, just think, we really don't need 1.3 anymore.
>>
>> Example: the latest patch I applied needed some tunings... for example
>> I needed to check if a specific method is avail (via reflection).
>> Annoying enough. But this fix will not work for jdk 1.3, because there
>> is no such a method. And now all jdk 1.3 users are suffering from a
>> memory leak which is likely never fixed. That being said, if we decide
>> to drop 1.3 but want to support oldschoolers, the next option is 1.4.
>> I think 1.4 is really old enough to even support banks.
>>
>
> Recall that no one is forcing anyone to upgrade to 1.4.
>
> If I want to use a new version of a jar, it comes with label that says "my
> requirements are...".
>
> If I want a bug fix in 1.2.x bad enough, I'll submit a patch for it and
> either hope for a release or do one internally for my app.
>
> If we do a Log4J 1.4 that requires Java 4/5/6, then that is quite fine with
> me.
>
> In the case of Log4J 2.0, it's not out yet and I see no indication of when
> that will happen.
>
> Right now, I am patching 1.2.x, it is a real release that can be moved
> along, little by little, as we see fit.
>
> Gary
>
>
>>
>> Anyway, I would be glad to go with 1.5 of course. Its just, we have
>> log4j2 which supports 1.5 and it would be good that people use that,
>> when they have 1.5.
>>
>> Cheers
>> Christian
>>
>> >
>> >
>> > Jake
>> >
>> >
>> > On Thu, 15 Mar 2012 15:41:12 +0100
>> > Christian Grobmeier <gr...@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 <ga...@gmail.com>
>> >> Date: Thu, Mar 15, 2012 at 2:25 PM
>> >> Subject: Re: Log4J patch
>> >> To: Christian Grobmeier <gr...@gmail.com>
>> >>
>> >>
>> >> On Thu, Mar 15, 2012 at 5:46 AM, Christian Grobmeier
>> >> <gr...@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 <ga...@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-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
>> >
>>
>>
>>
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Jdk 1.3 fails, lets upgrade to jdk 1.4. && Maintenance
Posted by Gary Gregory <gg...@apache.org>.
On Thu, Mar 15, 2012 at 3:04 PM, Christian Grobmeier <gr...@gmail.com>wrote:
> On Thu, Mar 15, 2012 at 5:58 PM, Jacob Kjome <ho...@visi.com> wrote:
> > 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.
>
> +1... honestly I did not knew it was build into this jar
>
> > 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+.
>
> i have tried to bump jdk requirement to 1.5 before a while. The answer
> was: we have log4j 2.0, lets stick with an older jdk for 1.2 series. I
> am ok with that, just think, we really don't need 1.3 anymore.
>
> Example: the latest patch I applied needed some tunings... for example
> I needed to check if a specific method is avail (via reflection).
> Annoying enough. But this fix will not work for jdk 1.3, because there
> is no such a method. And now all jdk 1.3 users are suffering from a
> memory leak which is likely never fixed. That being said, if we decide
> to drop 1.3 but want to support oldschoolers, the next option is 1.4.
> I think 1.4 is really old enough to even support banks.
>
Recall that no one is forcing anyone to upgrade to 1.4.
If I want to use a new version of a jar, it comes with label that says "my
requirements are...".
If I want a bug fix in 1.2.x bad enough, I'll submit a patch for it and
either hope for a release or do one internally for my app.
If we do a Log4J 1.4 that requires Java 4/5/6, then that is quite fine with
me.
In the case of Log4J 2.0, it's not out yet and I see no indication of when
that will happen.
Right now, I am patching 1.2.x, it is a real release that can be moved
along, little by little, as we see fit.
Gary
>
> Anyway, I would be glad to go with 1.5 of course. Its just, we have
> log4j2 which supports 1.5 and it would be good that people use that,
> when they have 1.5.
>
> Cheers
> Christian
>
> >
> >
> > Jake
> >
> >
> > On Thu, 15 Mar 2012 15:41:12 +0100
> > Christian Grobmeier <gr...@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 <ga...@gmail.com>
> >> Date: Thu, Mar 15, 2012 at 2:25 PM
> >> Subject: Re: Log4J patch
> >> To: Christian Grobmeier <gr...@gmail.com>
> >>
> >>
> >> On Thu, Mar 15, 2012 at 5:46 AM, Christian Grobmeier
> >> <gr...@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 <ga...@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-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
> >
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
Re: Jdk 1.3 fails, lets upgrade to jdk 1.4. && Maintenance
Posted by Christian Grobmeier <gr...@gmail.com>.
On Thu, Mar 15, 2012 at 5:58 PM, Jacob Kjome <ho...@visi.com> wrote:
> 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.
+1... honestly I did not knew it was build into this jar
> 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+.
i have tried to bump jdk requirement to 1.5 before a while. The answer
was: we have log4j 2.0, lets stick with an older jdk for 1.2 series. I
am ok with that, just think, we really don't need 1.3 anymore.
Example: the latest patch I applied needed some tunings... for example
I needed to check if a specific method is avail (via reflection).
Annoying enough. But this fix will not work for jdk 1.3, because there
is no such a method. And now all jdk 1.3 users are suffering from a
memory leak which is likely never fixed. That being said, if we decide
to drop 1.3 but want to support oldschoolers, the next option is 1.4.
I think 1.4 is really old enough to even support banks.
Anyway, I would be glad to go with 1.5 of course. Its just, we have
log4j2 which supports 1.5 and it would be good that people use that,
when they have 1.5.
Cheers
Christian
>
>
> Jake
>
>
> On Thu, 15 Mar 2012 15:41:12 +0100
> Christian Grobmeier <gr...@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 <ga...@gmail.com>
>> Date: Thu, Mar 15, 2012 at 2:25 PM
>> Subject: Re: Log4J patch
>> To: Christian Grobmeier <gr...@gmail.com>
>>
>>
>> On Thu, Mar 15, 2012 at 5:46 AM, Christian Grobmeier
>> <gr...@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 <ga...@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-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
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Jdk 1.3 fails, lets upgrade to jdk 1.4. && Maintenance
Posted by Jacob Kjome <ho...@visi.com>.
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 <gr...@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 <ga...@gmail.com>
> Date: Thu, Mar 15, 2012 at 2:25 PM
> Subject: Re: Log4J patch
> To: Christian Grobmeier <gr...@gmail.com>
>
>
> On Thu, Mar 15, 2012 at 5:46 AM, Christian Grobmeier
> <gr...@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 <ga...@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-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
Re: Jdk 1.3 fails, lets upgrade to jdk 1.4. && Maintenance
Posted by Scott Deboy <sc...@gmail.com>.
I think advertising 1.4 or higher is fine. FYI I ported trunk and
extras to PBP (basically 1.4) with a few changes.
Scott
On Mar 15, 2012, at 10:41 AM, Christian Grobmeier
<gr...@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 <ga...@gmail.com>
> Date: Thu, Mar 15, 2012 at 2:25 PM
> Subject: Re: Log4J patch
> To: Christian Grobmeier <gr...@gmail.com>
>
>
> On Thu, Mar 15, 2012 at 5:46 AM, Christian Grobmeier
> <gr...@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
>> <ga...@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-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