On Thu, Jan 26, 2012 at 12:40 PM, Ralph Goers <[email protected]> wrote: > Keep up the good work, Christian. I'm hoping interest will pick up once 2.0 > becomes more public. If you have an interest in helping with that you are > more than welcome! >
Thanks Ralph :-) I have a local checkout for a good while already, just need to find some time to get into :-) Cheers > Ralph > > Sent from my iPad > > On Jan 26, 2012, at 6:31 AM, Christian Grobmeier <[email protected]> wrote: > >> OK. So it seems you are fine we move on with the release. >> Will prepare it for the weekend. >> >> Thanks for your support! >> A pity, nobody else did comment here. >> >> On Thu, Jan 26, 2012 at 3:46 AM, Ralph Goers <[email protected]> >> wrote: >>> I see no harm in it as the next put will just create a new Hashtable, which >>> shouldn't be all that expensive in new JVMs. I really am not crazy about >>> it using Hashtable as I really don't see why a Map with synchronized >>> methods is required. But it is probably best to just leave well enough >>> alone on that issue and it isn't necessary to fix this problem. FWIW, >>> Logback doesn't call remove() when the map is empty and at the moment >>> neither does Log4j 2, but I think I'm going to change it to do it. >>> >>> Ralph >>> >>> >>> On Jan 25, 2012, at 2:33 PM, Christian Grobmeier wrote: >>> >>>> Hello fellow devs, >>>> >>>> can one of you give me a hint on this? As you know i am just helping >>>> out with log4j and so I am glad about comments from more experienced >>>> people, esp, in this case. I really would like to close this issue >>>> now. >>>> >>>> Is it possible to let remove() call clear()? >>>> >>>> Cheers >>>> Christian >>>> >>>> On Wed, Jan 25, 2012 at 11:10 PM, <[email protected]> wrote: >>>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50486 >>>>> >>>>> --- Comment #12 from [email protected] 2012-01-25 22:10:41 UTC --- >>>>> Ok, the patch was accepted, modified and applied I get that. >>>>> a) Shouldn't this ticket be marked as 'resolved'? >>>>> b) What's the ETA for 1.2.17? >>>>> >>>>> Also, I believe there's a second issue. The way it's implemented right >>>>> know >>>>> clients must explicitly call MDC.clear(). Couldn't/shouldn't remove() call >>>>> clear() internally once the last item was removed()? >>>>> How do clients know when to call clear()? In a request processing chain >>>>> (e.g. >>>>> Servlet filter) several parties may write items and each one of them is >>>>> responsible to call remove() for the items it added. On the way it items >>>>> are >>>>> added, on the way out they're removed in reverse order. And the last guy >>>>> closes >>>>> the door i.e. calls clear(). However, how does a client know that he's the >>>>> last? >>>>> >>>>> -- >>>>> Configure bugmail: >>>>> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email >>>>> ------- You are receiving this mail because: ------- >>>>> You are the assignee for the bug. >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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] >>>> >>> >>> >>> --------------------------------------------------------------------- >>> 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] >> > > --------------------------------------------------------------------- > 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]
