v yang | 3 May 18:29 2016

uncaught exception with log4j2

Hello list,

I'm looking for a way to log any uncaught exceptions to a file.  I'm currently running Wildfly 9.0.2 server
and all uncaught exceptions are printing to console.  I'd like to use log4j2 log those exceptions. Can
anyone point me in the right direction.


Dehan de Croos | 3 May 07:03 2016

RE: JDK 1.4 Support

Thanks for the update Ralph. I have a requirement to work with JDK 1.4 and that's why I needed this clarified
because I was unable to find any compatibility info in the release notes.
Going forward with 1.2.17 is there anything I should be mindful when working with it or any fatal issues that
I should be aware of? 

-----Original Message-----
From: Ralph Goers [mailto:ralph.goers <at> dslextreme.com] 
Sent: Friday, April 29, 2016 6:57 PM
To: Log4J Users List <log4j-user <at> logging.apache.org>
Subject: Re: JDK 1.4 Support

You would have to use Log4j 1.2.17.   No Log4j 2 version has ever supported 1.4.


> On Apr 29, 2016, at 3:26 AM, Dehan de Croos <ddcroos <at> virtusapolaris.com> wrote:
> Hi User Mailing List,
> What is the final supported release of Log4j with JDK 1.4 support?
> Thanks & Regards,
> Dehan de Croos,
> Virtusa (Pvt) Ltd.
> 752, Dr. Danister De Silva Mawatha
> Colombo 9
> Sri Lanka
> Phone:  +114605500
>  <http://www.virtusa.com/>  <http://www.virtusa.com/blog/>  <https://twitter.com/VirtusaCorp> 
(Continue reading)

Matt Sicker | 27 Apr 17:54 2016

What pattern or feature would you use to pass along the MDC between worker threads?

Is there any way to do this without manually passing along the context map
manually? These threads may be in a thread pool and execute asynchronous
callbacks, so I don't think using inheritable thread locals will help.

I can provide more details on framework usage and whatnot if it helps.


Matt Sicker <boards <at> gmail.com>
Benjamin Jaton | 27 Apr 01:58 2016

Log4j2 ThreadContext for child threads

Hi all,

I am using the ThreadContext a lot, but I am sometimes in a situation where
I would need to set some variable for a task that runs in a thread that
might spawn children threads. I need that logging variable to be also
available to those child threads.

Unless I create the sub threads manually and pass the variable myself, it's
not possible for a thread to know where it comes from and grab the variable
from its ancestors right?

Just asking because maybe someone has run into the same problem.

Jochen Wiedmann | 15 Apr 11:02 2016

Dynamically creating loggers


I've got an application, where I would like to obtain loggers on the
fly, because the logger name isn't known in advance. (Think of it as a
logging server, which will be used by remote clients.)

Now, creating a Logger might be an expensive operation. Thus, my question:

- Would you recommend to always invoke LogManager.getLogger(String)
and use the result?
- Or would it be better to maintain a Map<String,Logger> with the
logger name as key?




The next time you hear: "Don't reinvent the wheel!"

Steven Yang | 12 Apr 12:40 2016

Separate appender for each application in same Tomcat


I am trying to deploy 2 applications in to one tomcat (originally in 2
separate tomcat).
And I use -Dlog4j.configurationFile to specify my log4j configuration.
However, if I do that both applications will write to the same file.
I want each application to write to there own files.
Both applications have very similar packages and share many common
libraries developed in-house, so using package name to separate logs will
not be what we want.

What is the best solution/practice to this kind of problem?

(using log4j 2.5)

John Bush | 11 Apr 22:53 2016

jsonlayout contextMap

If you are frustrated by how the ootb JsonLayout handles context data, see

I've published how I worked around it here:
Maple Wang | 7 Apr 08:13 2016

how to disable recursive check for appender in log4j2.5


We are implementing a function with self-defined appender in log4j2.x, in
this appender, we forward LogEvent to other function modules,  and in those
function modules we also log some messages to this appender , so you must
understand that recursive call will happen sometimes. For current
implementation of log4j2.5, this kind of recursive call will be totally
blocked from appender, but this is not what we expect. Actually, we are
aware of this recursive call situation and we will handle it in appender by
ourselves to meet function requirement, it worked in log4j1.x, but it's not
working in  log4j2.x because of recursive call check for appender, is it
possible to disable it? Or at least to disable recursive call check for
specific appender.

Best regards.

Vyom Jain | 4 Apr 14:23 2016

Example RegexFilter using Pattern support added in LOG4J2-696

Hello Everyone!

Has anyone tried the feature implemented in LOG4J2-696
<https://issues.apache.org/jira/browse/LOG4J2-696> and would be interested
in sharing an example configuration which worked?

I've tried
<RegexFilter regex=".*test.*" onMatch="ACCEPT" onMismatch="DENY"

which gives an error ERROR RegexFilter contains an invalid element or
attribute "PatternFlags" during JVM startup.

Following doesn't work either -
<RegexFilter regex=".*test.*" onMatch="ACCEPT" onMismatch="DENY">

Also this information could be added in

Greg Thomas | 1 Apr 12:16 2016

ThreadContext - auto-closable?

I was looking at the ThreadContext section of the API  <at> 
http://logging.apache.org/log4j/2.x/manual/thread-context.html -
particularly the Thread Context Map

Given it's important to remember to clear the map at the "end" of
processing, would this be a good case for an auto-closeable, so you
could do something like (based on the documented example) ...

try (final CloseableThreadContext ctc = new
CloseableThreadContext("id", UUID.randomUUID().toString(),
"ipAddress", request.getRemoteAddr())) {

    logger.debug("Message 1");
    logger.debug("Message 2");

i.e. creating the object adds the key/value pairs to the Thread
Context Map, and when the object is auto-closed they are automatically
removed from the Thread Context Map (or returned to their original

Have I missed anything?

(and as I finished writing this, it strikes me that I don't need any
changes to the API, I can do this independently, but it may be worth

(Continue reading)

Simon Chan | 31 Mar 22:14 2016

rolled log file continues to grow unbound


Hope someone has heard of the problem below or can suggest workarounds or
how to debug this thing.

- After rolling, the old (rotated) log file continues to pick up entries
and grows.
  The new log file picks up WARN and INFO level logs. The old/rolled file
  up ERROR level logs.
- After max rotations, the filename no longer visible to "ls". But the Java
  still has 2 file descriptors pointing at the deleted file. The file will
  growing until it eats up all disk space.
- Only a handful systems have this problem. We have about 20 systems
  in the lab and most of them rotate correctly.
  One system has this bug happening 100% of the time, meaning after
restarting the
  Java process, the rotation problem appears at the first rollover.
  It is our stress test system and generates quit a bit of log entries
(busy but not
  ridiculously busy).
- 3 other systems entered the above state after moderate effort to
  filled the log file to trigger rolling.

Other Symtoms:
(Continue reading)