Yes, they are discrete attributes in Log4j2. However, you should be able to
handle this using your own Lookup. For example you could do:
<root level=“${zoo:rootLevel}>
<appenderRef ref=“${zoo:rootAppender}”/>
</root>
Then implement ZooLookup to parse the zookeeper.root.logger environment
variable and return the values for rootLevel and rootAppender.
Ralph
> On Feb 10, 2016, at 2:20 PM, Chris Nauroth <[email protected]> wrote:
>
> 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]:
>
> nohup "$JAVA" $ZOO_DATADIR_AUTOCREATE
> "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" \
> "-Dzookeeper.log.file=${ZOO_LOG_FILE}"
> "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
> -XX:+HeapDumpOnOutOfMemoryError -XX:OnOutOfMemoryError='kill -9 %p' \
> -cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT"
> 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
> ...
> log4j.rootLogger=${zookeeper.root.logger}
>
> 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
> here?
>
> Thank you!
>
> --Chris Nauroth
>
> [1] https://issues.apache.org/jira/browse/ZOOKEEPER-2342
> [2]
> https://github.com/apache/zookeeper/blob/release-3.5.1/bin/zkServer.sh#L148
> -L151
> [3]
> https://github.com/apache/zookeeper/blob/release-3.5.1/conf/log4j.propertie
> s#L20-L33
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
