Bill Okara | 22 Jul 20:18 2016

Fwd: is it possible to set container shared lib to use custom loggerContext


Following is my deployment env:

    |- lib/sharedLib12.jar   // shared lib  used by webapp1 and webapp2
    |- lib/slf4j-api-1.7.7.jar, log4j-api-2.3.jar, log4j-core-2.3.jar,
    |- webapps
         |                                 lib/log4j-web-2.3.jar
         |                                 lib/log4j-web-2.3.jar

 With servlet 3.0+ and default ClassLoaderContextSelector, it was
quite simple (awesome!) to config so that log output from each webapp
will be sent to it's own log file (webapp1.log, webapp2.log)

But the problem is that log output from the sharedLib jar will always
goto to the first loaded webapp, because:
----------> Parent Classloader:
org.apache.catalina.loader.StandardClassLoader <at> 59717824

the parent classloader (the one sharedLib is loaded) will be assigned
to the loggerContext of the first loaded webapp (which kinda makes

is there a way to config so that jars inside the tomcat/lib can be
(Continue reading)

Melissa Warnkin | 18 Jul 21:17 2016

ApacheCon: Getting the word out internally

ApacheCon: Getting the word out internally
Dear Apache Enthusiast,

As you are no doubt already aware, we will be holding ApacheCon in
Seville, Spain, the week of November 14th, 2016. The call for papers
(CFP) for this event is now open, and will remain open until
September 9th.

The event is divided into two parts, each with its own CFP. The first
part of the event, called Apache Big Data, focuses on Big Data
projects and related technologies.


The second part, called ApacheCon Europe, focuses on the Apache
Software Foundation as a whole, covering all projects, community
issues, governance, and so on.


ApacheCon is the official conference of the Apache Software
Foundation, and is the best place to meet members of your project and
other ASF projects, and strengthen your project's community.

If your organization is interested in sponsoring ApacheCon, contact Rich Bowen
at evp <at>  ApacheCon is a great place to find the brightest
developers in the world, and experts on a huge range of technologies.
(Continue reading)

Laurent Hasson | 13 Jul 14:44 2016

Add a pattern to the first rolling file created...


I would like to be able to add a pattern to the main logging file so that a new file is created each time my server
is re-started. This is the guts of our config file:

		<Property name="log-path">C:\Projects\TomcatDevServer\logs\</Property>
		<Property name="now">${sys:startup}</Property>
		<RollingFile name="FILES" fileName="${log-path}/capsico.log" filePattern="${log-path}/capsico.${now}.%i.log.gz">
                <pattern>%d{MMdd.HHmmss.SSS}#%-3t %level{length=1} %15.15c{1}|  %m%ex{20}%n</pattern>
				<SizeBasedTriggeringPolicy size="100 MB" />
			<DefaultRolloverStrategy max="99999" compressionLevel="9"/>
		<Async name="ASYNC">
			<AppenderRef ref="FILES" />

I have tried to add a pattern to the "filename" property for <RollingFile> but without success. This means
that right now, if the server is re-started, the logging continues right into the existing file
(everything else regarding the rolling logic works as expected).

All I'd want is for a simple timestamp to be added, like the filePattern, and if possibly, have the same
timestamp of the system start reused. I think I am missing something quite basic here? I am on log4J 2.5 on
(Continue reading)

Emi | 11 Jul 16:23 2016

2.6.2 minSize; reload tomcat - html log did not show correctly


upgraded to 2.6.2 with minSize setup, when reload tomcat, debug.html are 
not shown correctly.


       <RollingFile name="debug_html"
                    filePattern=" <at> log4j.debug.html <at> -%i.html">
          <HTMLLayout charset="UTF-8" title="title" />

             <OnStartupTriggeringPolicy minSize="10 MB"/>
             <SizeBasedTriggeringPolicy size="10 MB" />


Start tomcat7, Log message, reload tomcat7: debug.html are not shown 


" are shown twice (attached debug.html log file).

May I know is there anything I didn't set correctly please?
(Continue reading)

Cheryl_Mrozienski | 7 Jul 21:26 2016

defer creation of RollingFileAppender log files when Logger and/or AppenderRef level attribute has a value of "OFF"?

Dell - Internal Use - Confidential

I am currently using Log4j version 2.3, but might be able to update to a newer version if that would help.

I have a log4j2.xml file containing more than thirty RollingFileAppenders (one per product component). 
Most of these RollingFileAppenders will not be written to until the user turns on logging via our
product's user interface.  By default, the AppenderRefs that reference these RollingFileAppenders
have the "level" attribute set to a value of "OFF".  Once the user turns on logging from the user interface,
the "level" attribute will be updated with a value of "INFO", "DEBUG", etc.  And, once the updated
log4j2.xml file is persisted, the code will then call LoggerContext.reconfigure() to get Log4j to read
in the new log4j2.xml file, so the new log levels take effect.

My question is whether there is a way to tell Log4j to defer log file creation when nothing will initially
write to the file (e.g. all references to the Appender have a level of "OFF")?  Having lots of zero sized log
files is not that big of an issue, although not completely optimal.  However, having too many open file
handles that are not doing anything, could potentially become an issue.  Note that I do not have control
over the number of Appenders configured for the product.  Each product component team contributes its
Appender and Loggers to log4j2.xml.

To work around the open file handle issue at server startup time, I am currently using the Log4j2 private
core API calls to loop through the AppenderRefs to determine which ones are "OFF", and then I'm calling the
RollingFileAppender.stop() method to close the output stream.  If anyone has any ideas that would avoid
creating and opening the log files in the first place, I'd love to hear your thoughts.

Thanks and regards,


p.s. for reference, the relevant log4j2.xml snippets follow:
(Continue reading)

Leon Finker | 5 Jul 21:14 2016

Logging stopped, but Log4j2-AsyncLogger is RUNNABLE and maybe stuck in ThrowableProxy.toExtendedStackTrace


Using log4j2 runtime args with 2.6.1:

On CentOS 6.7 and Java 1.8.0_60.

We noticed that at some point the process has stopped logging to the log file (during startup). When doing 7
thread dumps over 8 minutes the AsyncLogger thread is Runnable, but always in the below stack trace. And
all the other threads are TIMED_WAITING to publish new log events RingBuffer.publishEvent. Has anyone
seen this before? There was no log entries for at least 25 minutes till we killed the process and restarted
it without problems. If AsyncLogger was progressing properly, something would appear in the log file
(RollingRandomAccessFile is configured with immediateFlush=true). It's hard to know how big the stack
length was in the ThrowableProxy.toExtendedStackTrace. But the threas is not BLOCKED, it's RUNNABLE.
Also it doesn't look like there is a way to limit the stack depth for th
 e toExtendedStackTrace?

"Log4j2-AsyncLogger[AsyncContext <at> 18b4aac2]1" #16 daemon prio=5 os_prio=0 tid=0x00007ff870c7b000
nid=0x79f3 in Object.wait() [0x00007ff839142000]
   java.lang.Thread.State: RUNNABLE
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(
        at org.apache.logging.log4j.core.util.Loader.initializeClass(
        at org.apache.logging.log4j.core.impl.ThrowableProxy.loadClass(
        at org.apache.logging.log4j.core.impl.ThrowableProxy.toExtendedStackTrace(
        at org.apache.logging.log4j.core.impl.ThrowableProxy.<init>(
        at org.apache.logging.log4j.core.impl.ThrowableProxy.<init>(
        at org.apache.logging.log4j.core.async.RingBufferLogEvent.getThrownProxy(
        at org.apache.logging.log4j.core.pattern.ExtendedThrowablePatternConverter.format(
(Continue reading)

Enric Jaen | 1 Jul 17:38 2016

Disabling Garbage-free not working

In our tomcat application we have a memory problem with logs kept in heap.I tried using log4j 1.6 and
log4j2.enable.threadlocals = false but without effect, what can be the reason?
Hartthaler, Thomas | 1 Jul 14:23 2016

How to modify the level of a ThresholdFilter programmatically?

Hi. I need to set the level of a ThresholdFilter programmatically. How can I do this? The whole description
of my problem is placed on stackoverflow under
Maybe somebody can give me a hint?

Thanks in advance,
Benjamin Jaton | 30 Jun 00:00 2016

Sharing common log4j2 configuration

Hello again,

Is there a way to define a set appenders/logger/props and use them in
several log4j2 configuration files?

I define sub-conf C
Then I create conf A that "imports" C,
and conf B that "imports" C as well.

I know about x:include (,
I was wondering if there were anything like it for JSON?

If not, would that be something that can be done programmatically?

David Leonhartsberger | 29 Jun 21:10 2016

Why is AsyncLogger#shutdown time not configurable?

I was just looking at the AsyncLoggerDistruptor#stop() and figured out that
the shutdown time is not configurable and it even could be blocking forever
waiting that the Disruptor backlog has been processed.

// Calling Disruptor.shutdown() will wait until all enqueued events are
fully processed,
// but this waiting happens in a busy-spin. To avoid (postpone) wasting CPU,
// we sleep in short chunks, up to 10 seconds, waiting for the ringbuffer
to drain.
for (int i = 0; hasBacklog(temp) && i < MAX_DRAIN_ATTEMPTS_BEFORE_SHUTDOWN;
i++) {
try {
Thread.sleep(SLEEP_MILLIS_BETWEEN_DRAIN_ATTEMPTS); // give up the CPU for a
} catch (final InterruptedException e) { // ignored
temp.shutdown(); // busy-spins until all events currently in the disruptor
have been processed

I was wondering why the "temp.shutdown()" call does not use a
(configurable) timeout?
Was this a design decision or was it just overlooked?

Benjamin Jaton | 27 Jun 20:17 2016

Reloading appender after property value changes


I have a simple appender like:

        "type" : "smtp",
        "name" : "EmailAppender",
        "subject" : "${email.subject}",
        "to" : "${email.recipient}",
        "from" : "${email.from}",
        "smtpProtocol" : "${email.smtp.protocol}",
        "smtpHost" : "${}",
        "smtpPort" : "${email.smtp.port}",
        "smtpUsername" : "${email.smtp.username}",
        "smtpPassword" : "${email.smtp.password}"

When I have a updated value for one of those property (for example
${email.subject} has changed, what's the simplest way to reload the
appender so that it takes that new value?
Do we have to force a full reconfiguration?