kusmanjali | 16 Sep 14:12 2015

Source field in NoSQLAppender

We have a wrapper for log4j 2 APIs. So instead of directly calling the
function we call custom class to do the logging. The problem with this
aproach is the 'source' field stored in database has details of the custom
log class and not the class which is calling it i.e all my fileName ,
linenumber have details of the custom class. Is there a way to update the
'source' field?


with regards
Kusmanjali Jenamoni
Nicholas Duane | 16 Sep 04:25 2015


I was about to starting writing a sample to see how markers work and to see if they could be used for logging
business events instead of using a custom level.  While I might have mentioned log4net in passing, we're
trying to capture these business events using existing logging frameworks.  The thinking is that we'd use
log4net on windows and log4j(2) on linux (no facade).  Ideally the design would be similar across both
platforms.  That being said, I'm surprised at how different log4net is from log4j(2).  It appears log4net
doesn't support markers.  While we don't have to have the same solution for both platforms, it would be nice
if the solutions were the same or similar.

I also looked at the EventLogger and that class doesn't have any overloads which take a marker, just a static
marker property.  I guess the EventLogger can be assigned only a single marker?


Ralph Goers | 12 Sep 01:23 2015

Re: approach for defining loggers

> On Sep 11, 2015, at 3:50 PM, Gary Gregory <garydgregory <at> gmail.com> wrote:
> This updated text I hope will help:
> "No new loggers needed, just an additional parameter to your log call,
> <em>regardless</em> of the level API used.
> Now, I can configure Log4j to log only events that contain the marker DOOR
> (if that level is enabled).”

This isn’t necessarily true.  If you have a global filter that accepts the event then the log level of the
appropriate logger will not be checked. However, other filters on the AppenderRef and Appenders will
still be checked.


Priya Ahuja | 10 Sep 20:38 2015

Custom Markers


I am currently using log4j2.0 and I have implemented Marker (SYSLOG_MARKER)
for deciding the destination of a log to be localfile log or syslog. But
with this approach all the existing logs in the system (~5000) will need
manual decision and addition of marker to every single log. Is there a
better way to filter logs at INFO level? I don't want to introduce a new

        <Root level="INFO">
            <AppenderRef ref="RFC5424">
                    <MarkerFilter marker="SYSLOG" onMatch="ACCEPT"
            <AppenderRef ref="LOGFILE"/>

Priya Ahuja
Boyang(Jerry) Peng | 3 Sep 00:06 2015

Question about RollingFileAppender

I am using RollingFileAppender to limit the number of log files.  Is there a way to use the
Default Rollover Strategy with a time %d{yyyy-MM-dd-HH-mm-ss} with a <SizeBasedTriggeringPolicy
size="100 MB"/> and set <DefaultRolloverStrategy max="9"/>?  How can use a time based format for the
name of my log but limit the number of logs to a certain number and after the limit is reached the oldest log
gets deleted? Is there a way to do this?

Sharath Gururaj | 1 Sep 19:50 2015

FileAppender append="false" does not truncate the file on startup

        <File name="MyFile" fileName="app.log" append="false" >

            <PatternLayout pattern="%d{HH:mm:ss.SSS} %-5level %l - %msg%n"


I expect app.log to be truncated on my application startup.

This is not the case. It is never truncated. Please help


Nicholas Duane | 30 Aug 04:44 2015

approach for defining loggers

I'm curious if there is a prescribed approach to defining loggers.  Let me state what my assumption is.  I
assume that normally if some piece of code wants to log events/messages that it should create a logger for
itself.  I guess a reasonable name to use is the class name itself.  In terms of logger configuration I would
expect that no loggers are specified in the log4j configuration UNLESS is needs settings other than the
default.  The root logger would specify the default settings, eg. level and appenders.  If some piece of
code tied to a logger needs to enable tracing in order to debug an issue then you would add that logger to the
configuration and set the level less specific for that logger.  Is this a typical and reasonable approach?

I asked because we have the need for a new type of event.  To have this event flow to where we want it to flow the
plan is to have a custom level and have all events at that level captured by a specific appender.  My
assumption was that for existing applications we'd just need to add our appender to the root and add our
custom level.  The app would need to be modified to log our new event at the custom level.  However, someone
suggested that we could also create a separate logger for this event.  My thinking is that while we don't
ever want to turn off logging of this event, loggers represent "event sources", e.g the code raising the
events and thus having multiple different pieces of code use the same logger wouldn't allow you to turn
on/off logging from those different sections of code independently.  I think the current configuration
includes all the loggers.  Normally I would expect there to be many, on the order of 10's or 100's, loggers
within an application.  However, in the case I was given there were only a handful because I think this
handful is shared.  So as I mentioned, this doesn't sound like an ideal design as you have less granularity
on what you can turn on/off.

Nicholas Duane | 27 Aug 20:51 2015


I've got a couple questions regarding plugins I'm hoping someone might be able to help me with.  I checked the
docs and it's still not quite clear.

1. I'm unsure what to set printObject to in my Plugin annotation.  From
http://logging.apache.org/log4j/2.x/manual/extending.html it says:

"Specifying the printObject attribute with a value of "true" indicates that a call to toString will format
the arguments to the filter as the configuration is being processed."

which unfortunately doesn't clear things up any.  I looked at the docs for printObject and that doesn't say
anything other than it's a Boolean and its default is false.

2. I created a LevelRangeFiler and I'm trying to figure out how to get it loaded by log4j.  I read over the
instructions on plugins located at http://logging.apache.org/log4j/2.x/manual/plugins.html but
since I'm a java noob I'm still a bit lost.  I'm wondering, if I just have a .java class which I compile to a
.class file, can that be used?  If so, how?

Below is the filter I wrote based on looking at the threshold filter example at http://logging.apache.org/log4j/2.x/manual/extending.html.

import org.apache.logging.log4j.core.filter.AbstractFilter;
import org.apache.logging.log4j.core.Filter;
import org.apache.logging.log4j.core.config.plugins.Plugin;
import org.apache.logging.log4j.core.config.plugins.PluginAttribute;
import org.apache.logging.log4j.core.config.plugins.PluginFactory;
import org.apache.logging.log4j.Level;
import org.apache.logging.log4j.core.LogEvent;
import org.apache.logging.log4j.core.Logger;
import org.apache.logging.log4j.Marker;
import org.apache.logging.log4j.message.Message;
(Continue reading)

Nicholas Duane | 26 Aug 20:19 2015

custom levels via configuration

On to my next problem.  I'm trying to define a custom level in configuration.  Not sure if it's working or not. 
However, when I attempt to get the level for that custom level I get back null, which I wasn't expecting. 
Here is the log4j2.xml config file:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="trace" verbose="true">
    <CustomLevel name="INFOM1" intLevel="399"/>
    <CustomLevel name="INFOP1" intLevel="401"/>
    <File name="info" fileName="info.log">
    <Pattern>%d %p %c{1.} [%t] %m%n</Pattern>
    <ThresholdFilter level="INFOM1" onMatch="DENY" onMismatch="NEUTRAL"/>
    <ThresholdFilter level="INFO" onMatch="ACCEPT" onMismatch="DENY"/>
    <Logger name="HelloWorld" level="ALL">
      <AppenderRef ref="info"/>
(Continue reading)

Ralph Goers | 26 Aug 18:29 2015

Re: redefining existing levels?

Well, I suppose we could add a minimum logging level system property and if someone tries to set the level
lower than that then the minimum level gets used instead.  But I’m not really crazy about that as it could
cause all kinds of “unexpected” consequences when processing the configuration.

It seems to me that the real issue is that people have access to your production machines who probably shouldn’t.


> On Aug 26, 2015, at 9:24 AM, Gary Gregory <garydgregory <at> gmail.com> wrote:
> On Wed, Aug 26, 2015 at 9:19 AM, Nicholas Duane <nickdu <at> msn.com <mailto:nickdu <at> msn.com>> wrote:
>> I guess the main use case we're trying to solve is someone, maybe some
>> admin or maybe a developer asking the admin, thinking they should turn
>> logging off and thus sets the level to "OFF".  We always want INFO and more
>> critical levels to be on no matter what.
> But if a user gets in a config file and sets the root level to off, how can
> you stop him or her from removing your filters and custom levels?
> Gary
>> Thanks,
>> Nick
>>> Subject: Re: redefining existing levels?
>>> To: log4j-user <at> logging.apache.org
>>> From: xen <at> dds.nl
(Continue reading)

Nicholas Duane | 26 Aug 18:27 2015

RE: redefining existing levels?

Maybe what I'm trying to do is not that useful.  However, I'm guessing the person mucking around with things
would probably feel uncomfortable deleting entries in the config.  If they are familiar with log4j they
might feel comfortable setting the level if they think they should be turning things off.

Basically, we have what we'll call "always on" or "24x7" logging.  This is about always having INFO and more
critical turned on.  I'm just looking for ways to help enforce that.


> Date: Wed, 26 Aug 2015 09:24:07 -0700
> Subject: Re: redefining existing levels?
> From: garydgregory <at> gmail.com
> To: log4j-user <at> logging.apache.org
> On Wed, Aug 26, 2015 at 9:19 AM, Nicholas Duane <nickdu <at> msn.com> wrote:
> > I guess the main use case we're trying to solve is someone, maybe some
> > admin or maybe a developer asking the admin, thinking they should turn
> > logging off and thus sets the level to "OFF".  We always want INFO and more
> > critical levels to be on no matter what.
> >
> But if a user gets in a config file and sets the root level to off, how can
> you stop him or her from removing your filters and custom levels?
> Gary
> >
> > Thanks,
(Continue reading)