I was actually thinking that we might create a lookup that parses the results from other lookups. I’m just not sure what the syntax would be.
Ralph > On Feb 10, 2016, at 2:49 PM, Gary Gregory <[email protected]> wrote: > > 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
