It sounds like a pretty generic feature though. And making life easier for log4j1 migratory users is a huge bonus IMO.
How about contributing this as a patch? Gary On Feb 10, 2016 1:32 PM, "Ralph Goers" <[email protected]> wrote: > 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] > >
