On Fri, Mar 16, 2012 at 1:58 AM, Ralph Goers <ralph.go...@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 <h...@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 <ggreg...@apache.org> wrote: >>>> On Thu, Mar 15, 2012 at 3:04 PM, Christian Grobmeier >>>> <grobme...@gmail.com>wrote: >>>> >>>>> On Thu, Mar 15, 2012 at 5:58 PM, Jacob Kjome <h...@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 <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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> E-Mail: garydgreg...@gmail.com | ggreg...@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-unsubscr...@logging.apache.org >>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>> >>> >> >> -- >> Sent from my mobile device >> >> Regards >> Tushar Kapila >> >> --------------------------------------------------------------------- >> 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 > -- 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
