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 <[email protected]>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 <[email protected]> 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 <[email protected]> wrote: > >>> On Thu, Mar 15, 2012 at 3:04 PM, Christian Grobmeier > >>> <[email protected]>wrote: > >>> > >>>> On Thu, Mar 15, 2012 at 5:58 PM, Jacob Kjome <[email protected]> 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 <[email protected]> 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 <[email protected]> > >>>>>> Date: Thu, Mar 15, 2012 at 2:25 PM > >>>>>> Subject: Re: Log4J patch > >>>>>> To: Christian Grobmeier <[email protected]> > >>>>>> > >>>>>> > >>>>>> On Thu, Mar 15, 2012 at 5:46 AM, Christian Grobmeier > >>>>>> <[email protected]> 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 > >>>>>>> <[email protected]> > >>>>>>> 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: [email protected] > >>>>>> For additional commands, e-mail: [email protected] > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [email protected] > >>>>> For additional commands, e-mail: [email protected] > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> http://www.grobmeier.de > >>>> https://www.timeandbill.de > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>>> > >>>> > >>> > >>> > >>> -- > >>> E-Mail: [email protected] | [email protected] > >>> 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: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > -- > > Sent from my mobile device > > > > Regards > > Tushar Kapila > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- E-Mail: [email protected] | [email protected] 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>
