logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Nauroth <cnaur...@hortonworks.com>
Subject Log4J 2 configuration: parameterizing appender via environment variable
Date Wed, 10 Feb 2016 21:20:01 GMT
Hello Log4J community,

I'm currently investigating possible migration from Log4J 1 to Log4J 2 for
Apache ZooKeeper.  For full context, please see Apache JIRA issue
ZOOKEEPER-2342 [1].  I'm struggling with how to preserve one particular
capability that we have already given to administrators for controlling
their logging settings.  I can't find a way to achieve the same thing in
Log4J 2, and I'd like to get your advice.

The ZooKeeper launch scripts support controlling the root logger by
setting an environment variable named ZOO_LOG4J_PROP.  The value gets
passed to the launched process as a -Dzookeeper.root.logger argument [2]:

"-Dzookeeper.log.dir=${ZOO_LOG_DIR}" \
"-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
    -XX:+HeapDumpOnOutOfMemoryError -XX:OnOutOfMemoryError='kill -9 %p' \
2>&1 < /dev/null &

We have a Log4J 1 log4j.properties file that includes a default value for
zookeeper.root.logger in case it is unspecified at process launch, and
then the variable gets substituted into the declaration of
log4j.rootLogger [3]:

zookeeper.root.logger=INFO, CONSOLE

The net effect of this is that it gives the administrator the capability
to parameterize the appender at process launch time without needing to
edit the log4j.properties file.  For example, they could run
"ZOO_LOG4J_PROP=DEBUG,ROLLINGFILE; bin/zkServer.sh start".

I have not been able to replicate this functionality in Log4J 2.  From
what I can tell, Log4J 2 configuration is more structured, so there are
specific individual settings for things like rootLogger.level and
rootLogger.appenderRefs.  There isn't a centralized spot where I can
substitute in "DEBUG,ROLLINGFILE" or similar as a single string to toggle
the settings.  That means that we'd have to advise administrators to
switch to a model of editing their log4j2.properties file to achieve this
instead of controlling it with the environment variable.  That would be
seen as a backwards-incompatible change from the administrator's
perspective.  I suppose an alternative could be to preserve the current
functionality by trying to implement our own logic to parse things like
"DEBUG,ROLLINGFILE" and translate to what Log4J 2 expects, but given the
amount of flexibility that was possible, I expect attempting to do this
would be brittle.

Does anyone have other suggestions for how to implement this?  Is there a
Log4J 2 configuration feature that I failed to find that would be helpful

Thank you!

--Chris Nauroth

[1] https://issues.apache.org/jira/browse/ZOOKEEPER-2342

To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message