To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project logging-log4j-12 has an issue affecting its community integration.
This is
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
--- Comment #54 from Patric Rufflar ---
>If a thread doesn't clean up behind itself it leaves it up for someone else to
>>do the dirty work - not nice.
I totally agree - that's way it should be.
Unfortunately this seems not clear for every
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project logging-log4j-12 has an issue affecting its community integration.
This is
Looks like we either need to remove the examples from compilation, or at least
remove the lf5 examples from the main build along with the removal of the lf5
and chainsaw1 packages.
BTW, when you say "remove" lf5 and chainsaw1, you mean "move", right? They
should be provided in a separate op
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
--- Comment #53 from mar...@frightanic.com ---
(In reply to comment #52)
> From a real-world perspective, all we need is one method which cares about
> all threads.
I claim to live in the same real world as you but my perspective is still
d
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
--- Comment #52 from Patric Rufflar ---
>Where should the shutdown method reside? In MDC?
Within MDC would be ok, but for a matter of good design I would put this on an
higher level, e.g. inside LogManager.shutdown()
>What is the benefi
On May 30, 2012, at 1:47, Christian Grobmeier wrote:
> Hello,
>
> currently Maven uses Ant. But Ant is also available for a full build
> of log4j (not tested). Imho this is one of the reasons our build is so
> complex: you cannot change Maven without looking at Ant and vice
> versa.
>
> I propose
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
--- Comment #51 from grobmeier ---
@Patric:
yes I missed your question. Calling MDC.clear() does clear all values from the
underlying hashtable and afterwards calls the remove method (if available,
which is from java > 1.4). So yes, it sho
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
--- Comment #50 from Patric Rufflar ---
@grobmeier
You missed a question in my last comment:
Is calling MDC.clear() at the end of doFilter() of a servlet filter sufficient?
IMHO (just took a quick look at the source), a shutdown() method
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
--- Comment #49 from grobmeier ---
You can receive all the keys with doing:
MDC.getContext();
It returns a Hashmap. For each key in the Hashmap, call remove(key).
If you have ideas for such a shutdown() Method, please propose it on log4j
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
--- Comment #48 from Patric Rufflar ---
What if you do not know which key/value pairs have been put to the MDC (if you
think of 3rd party libraries, runtime dependent logic etc.)?
Is calling MDC.clear() at the end of doFilter() of a servle
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
grobmeier changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
--- Comment #46 from smarkwal ---
I can confirm that the memory leak has been fixed for our product after
upgrading to 1.2.17. I tested with Tomcat 7.0.26 running on an Oracle JVM
1.6.0_23 on Windows 7.
Thanks to all the people contributin
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
--- Comment #45 from mar...@frightanic.com ---
(In reply to comment #44)
> Thanks Stephan, I agree with you guys. I will use your code snippet for the
> FAQ.
While Stephan's code certainly is correct (actually, log4j could provide that
filt
On May 29, 2012, at 11:36 PM, Christian Grobmeier wrote:
> On Wed, May 30, 2012 at 7:59 AM, Ralph Goers
> wrote:
>> As I see it, the problem is that at least some of the users seem to be
>> expecting Log4j to magically know when to call clear. It can't. The
>> application has to do it.
>>
>> A
On May 29, 2012, at 11:39 PM, Christian Grobmeier wrote:
> On Wed, May 30, 2012 at 8:36 AM, Christian Grobmeier
> wrote:
>> On Wed, May 30, 2012 at 7:59 AM, Ralph Goers
>> wrote:
>>> As I see it, the problem is that at least some of the users seem to be
>>> expecting Log4j to magically know wh
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
--- Comment #44 from grobmeier ---
Thanks Stephan, I agree with you guys. I will use your code snippet for the
FAQ.
Thanks Marcel for confirming the change.
Once the FAQ entry is ready, I will close this issue again with the appropriate
l
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
--- Comment #43 from mar...@frightanic.com ---
In reply to comment #42)
> Yes, looks good to me. I just mentioned it again because calling clean() in
> Servlet#destroy() doesn't make sense in my opinion. In fact, clients
> shouldn't have to
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
--- Comment #42 from mar...@frightanic.com ---
(In reply to comment #40)
> Hi Marcel,
>
> this patch is actually applied (slightly modified):
>
> http://svn.apache.org/repos/asf/logging/log4j/trunk/src/main/java/org/apache/
> log4j/MDC.jav
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
--- Comment #41 from smarkwal ---
(In reply to comment #38)
> [...] In a servlet environment, you might want to put
> this code into the Servlet.destroy() method:
I don't think that calling the clear method in the servlet's destroy method
https://issues.apache.org/bugzilla/show_bug.cgi?id=50486
--- Comment #40 from grobmeier ---
Hi Marcel,
this patch is actually applied (slightly modified):
http://svn.apache.org/repos/asf/logging/log4j/trunk/src/main/java/org/apache/log4j/MDC.java
private void remove0(String key) {
if
21 matches
Mail list logo
