Yeah, we'd need a list of fixed issues to backport before we maintained a separate branch. A lot of new features depend on Java 1.7 APIs that would have to be backported.
On 17 December 2015 at 18:08, Gary Gregory <garydgreg...@gmail.com> wrote: > FYI: I'm pretty sure we will not see a 2.3 branch maintained at parity with > master, I do not see anyone here so far that has expressed interest in such > an effort. If you'd like to help out, you are more than welcome to do so. > There is a possibility for a 2.3.x branch to backport selected fixes > though, again, help wanted. Aside from that my efforts focus on master. > > Gary > > On Thu, Dec 17, 2015 at 4:04 PM, Dave Glasser <dglas...@pobox.com> wrote: > > > The bugs don't matter, because, as I mentioned, the main blocker for me > in > > the 2.x branch is that I need to ability to programmatically configure > > log4j, and change the configuration at runtime. It might get there, in > fact > > 2.5 might be there, but Java 1.7 is a no-go for me. > > If you guys are going to actively maintain a Java 1.6-compatible branch > > that's forked from log4j 2.3, my suggestion would be to keep all the bug > > fixes and functionality aligned with the main branch, except for the > lamda > > stuff that doesn't work under Java 1.6. But that's just a suggestion. > I'll > > be sticking with the 1.2.x branch for the foreseeable future. > > > > > > > > From: Gary Gregory <garydgreg...@gmail.com> > > To: Log4J Users List <log4j-user@logging.apache.org>; Dave Glasser < > > dglas...@pobox.com> > > Sent: Thursday, December 17, 2015 6:32 PM > > Subject: Re: still: Memoryleak - org.apache.log4j.helpers.ThreadLocalMap > > > > Can you list which bugs in JIRA you'd like to have in what could possibly > > be a 2.3.1 release? > > > > Gary > > > > On Thu, Dec 17, 2015 at 2:57 PM, Dave Glasser <dglas...@pobox.com> > wrote: > > > > > Unfortunately, in addition to the bugs in 2.3, there is missing > > > functionality that precluded me from using it. (The programmatic > > > configuration features I posted about in the last week or so.) > > > If there isn't currently any actively maintained branch that supports > > 1.6, > > > I'll have to work around it some other way. > > > > > > > > > > > > From: Gary Gregory <garydgreg...@gmail.com> > > > To: Dave Glasser <dglas...@pobox.com>; Log4J Users List < > > > log4j-user@logging.apache.org> > > > Sent: Thursday, December 17, 2015 3:16 PM > > > Subject: Re: still: Memoryleak - > org.apache.log4j.helpers.ThreadLocalMap > > > > > > Hello, > > > > > > Log4j 1 has reached EOL. For Java 6 support you can use 2.3. > > > > > > Gary > > > On Dec 17, 2015 11:30 AM, "Dave Glasser" <dglas...@pobox.com> wrote: > > > > > > > To any Log4j devs on the list, if Veit has found a bug in 1.2.17, > > please, > > > > please, fix it and release 1.2.18. I cannot use 2.5 because my code > has > > > to > > > > run under Java 1.6. I suspect that is the case with a lot of > developers > > > who > > > > deploy on WebSphere or WebLogic. > > > > > > > > > > > > > > > > From: Veit Guna <veit.g...@gmx.de> > > > > To: log4j-user@logging.apache.org > > > > Sent: Thursday, December 17, 2015 12:36 PM > > > > Subject: still: Memoryleak - org.apache.log4j.helpers.ThreadLocalMap > > > > > > > > Hi. > > > > > > > > We're developing a Jersey 2(.22.1) REST service with JDK8, log4j > 1.2.16 > > > > and SLF4J 1.7.7 using Tomcat 8.0.23. > > > > > > > > Recently I stumbled across the problem mentioned here: > > > > > > > > https://bz.apache.org/bugzilla/show_bug.cgi?id=50486 > > > > > > > > Where Tomcat complains about left behind ThreadLocalMaps. > > > > > > > > I updated to 1.2.17 which claims to fix the mentioned problem. > > > > On first sight, it did. Starting the server and immediately stopping > it > > > > showed no warning anymore - before it did. Yay! > > > > > > > > But then I drove some loadtests against our REST service and after > > > > stopping it the same message appeared again :(. > > > > > > > > I double checked that our MDC put/remove is performed within a > > > > try/finally within a http filter. I also logged, what values > > > > were put and removed from the MDC - everyting as expected. > > > > I also made sure, that the key was really removed after > > > > MDC.remove() by getting the key from the MDC again: null. > > > > > > > > Tomcat complained about a specific key/value in the ThreadLocalMap. > > > > I checked, that this key/value was logged before - and it was > > > > logged as "removed". So somehow it wasn't _really_ removed. > > > > > > > > I digged deeper into the rabbit hole and found this peace of code: > > > > > > > > --cut here-- > > > > final public class ThreadLocalMap extends InheritableThreadLocal { > > > > > > > > public > > > > final > > > > Object childValue(Object parentValue) { > > > > Hashtable ht = (Hashtable) parentValue; > > > > if(ht != null) { > > > > return ht.clone(); > > > > } else { > > > > return null; > > > > } > > > > } > > > > } > > > > --cut here-- > > > > > > > > At this point, the hashtable containing the key/values is cloned > > > > when a child thread is spawned. That would explain, why I see that > > > > the complained key/value still exists, although I removed it from the > > > > MDC. It still exists in the cloned instance on the spawned child > thread > > > > I guess! > > > > > > > > I verified it by debugging within eclipse and set a breakpoint there, > > > > simply returning null instead of ht.clone(). And voila: no > complaining > > > > anymore when shutting down. > > > > > > > > Since I'm not too deep into log4j, could someone of the devs please > > > > shed some light on this, please? > > > > > > > > I'm wondering, who will remove the ThreadLocalMap on the spawned > child > > > > threads? Since MDC.remove() will do this only on my parent thread > > > > manually kicked by the filter. > > > > > > > > Or, maybe I'm completely wrong with this :). > > > > > > > > Thanks > > > > Veit > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > > > > For additional commands, e-mail: log4j-user-h...@logging.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > > Java Persistence with Hibernate, Second Edition > > <http://www.manning.com/bauer3/> > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > > Spring Batch in Action <http://www.manning.com/templier/> > > Blog: http://garygregory.wordpress.com > > Home: http://garygregory.com/ > > Tweet! http://twitter.com/GaryGregory > > > > > > > > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- Matt Sicker <boa...@gmail.com>
