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 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 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

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>> wrote:
> On Wed, Aug 26, 2015 at 9:19 AM, Nicholas Duane <nickdu <at> <mailto:nickdu <at>>> 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>
>>> From: xen <at>
(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>
> To: log4j-user <at>
> On Wed, Aug 26, 2015 at 9:19 AM, Nicholas Duane <nickdu <at>> 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)

Nicholas Duane | 25 Aug 21:42 2015

redefining existing levels?

Can existing log4j2 levels be redefined?  I'm able to do this in log4net.  I have yet to see any documentation
telling me that I can do it, however, there was none telling me I could do it for .NET either.  I just happen to
stumble upon a post which eluded to it.  Here is what I've done in a log4net config file:

         <name value="Off"/>
         <value value="40000"/>
         <name value="Business"/>
         <value value="130000"/>

As you can see I created my own 'Business' level.  I also redefined Off to 40000 which happens to be the INFO
level.  This makes it such that if they set the level to Off they will still receive INFO and higher level events.

Can the same thing be done in log4j2?
(Continue reading)

Nicholas Duane | 25 Aug 21:36 2015

range filter?

I'm looking for a range filter in log4j2.  I see there is on in log4net and it appears there was one written by
someone for log4j 1.  Just wondering if there is something 'out of the box' in log4j2 that will accomplish
the same?  I was wondering whether this could be accomplished with the CompositeFilter with two ThresholdFilter?

kusmanjali | 24 Aug 11:38 2015

Fields In NoSQL Appender


Is there a way to configure the fields in getting logged through Log4j2
NoSQL appender.
For example, if we chose not to log loggerName or source, then is there a
way to disable this.


with regards
Kusmanjali Jenamoni
Jinhong Lu | 14 Aug 07:08 2015

java.lang.NoSuchFieldError: errorHandler

I met this exception when using syslogappender.

my log4j version is 1.2.16.

Any idea?  thanks.

java.lang.NoSuchFieldError: errorHandler
	at com.netease.sytopology.util.MySysLogger.<init>(
	at com.netease.sytopology.util.MySysLogger.getInstance(
	at com.netease.sytopology.bolt.FilterFunction.prepare(
	at storm.trident.planner.processor.EachProcessor.prepare(
	at storm.trident.planner.SubtopologyBolt.prepare(
	at storm.trident.topology.TridentBoltExecutor.prepare(
	at backtype.storm.daemon.executor$fn__4722$fn__4734.invoke(executor.clj:692)
	at backtype.storm.util$async_loop$fn__458.invoke(util.clj:461)
	at [clojure-1.5.1.jar:na]
	at [na:1.7.0_67]

And here is my code:

(Continue reading)

Xen | 11 Aug 20:11 2015

my results thus far

Hi, I just wanted to give a little back of what I've been doing.

I can say programmatic configuration the way it is is *really* hard.

Mostly it is hard because of

- having to import a million different things from different packages, 
and you can never guess or remember which package it is going to be
- the creator methods take a million parameters
- appenders need to be added twice
- if you create an appender with the same name it will not add it but 
give no error
- various static methods from different classes do important things, but 
it is not centralized.
- maybe there is too much static in any case, but yeah.

JAnsi works. I'm doing stuff JAnsi does, and there is already an entire 
package that does everything I would want or need to do :P. Go figure. 
Now it is even included with my application just to make it work on 
Windows, and I don't really want to use it with my default application 
;-). (Maybe I'll have to, given that). Ooh but it doesn't do input 
processing/filtering, I might even use it. (My library parses ANSI tokens).

Anyway to cut it short now, here is a screenshot of what I've been doing:

The first field is the thread in blue, there are three threads (thread 
types): main, server and client. Every client thread gets numbered from 
a pool that gets refilled when a thread exits (just a Set I take numbers 
(Continue reading)

Xen | 10 Aug 20:08 2015

programmatic config (not working)

Hi again.

So. I managed to get a new ConfigurationFactory running (just so as to 
avoid the ERROR level message given by the StatusLogger when no config 
file is found) that returns a DefaultConfiguration() for now.

I happened to have overriden the wrong method. 
"getConfiguration(ConfigurationSource)" is not directly called and when 
configLocation is null, it will never be called. So I overrode 
getConfiguration(String, URI) instead, and then it worked.

So now I'm trying to -- outside of any Configuration class or subclass 
-- to get a modest change to the configuration going. I am just trying 
to add Two Loggers with associeted LoggerConfig, that will inherit the 
Appender from the RootLogger.

However, I am failing and I don't know why.

ConfigurationFactory.setConfigurationFactory(new DefaultNoErrorFactory());
LoggerContext lc = (LoggerContext)LogManager.getContext();
Configuration conf = lc.getConfiguration();
addLogger(conf, thunderbolt.Server.class, Level.TRACE, true);
addLogger(conf, telnet.Negotiator.class, Level.DEBUG, true);

My "addLogger" method simply does either one of two things:

1. call configuration.addLogger("name", new LoggerConfig("name", level, 
2. call configuration.addLogger("name", LoggerConfig.createLogger("" + 
(Continue reading)