We already support this with two variables. But if they only want to pass one then we have two options: 1. Modify PropertiesConfiguration to support a new element that allows a Level and AppenderRef which then gets split internally. 2. Create a Lookup that extracts the relevant portion of the data.
Ralph > On Jan 9, 2022, at 3:08 PM, Gary Gregory <[email protected]> wrote: > > I think it is reasonable to say we can support this through 2 instead of 1 > variable. > > Duo? > > Gary > > On Sun, Jan 9, 2022, 16:24 Ralph Goers <[email protected]> wrote: > >> I’m looking at this and have a couple of concerns. The script has >> >> >> HADOOP_ROOT_LOGGER=${HADOOP_ROOT_LOGGER:-${HADOOP_LOGLEVEL},console} >> >> HADOOP_DAEMON_ROOT_LOGGER=${HADOOP_DAEMON_ROOT_LOGGER:-${HADOOP_LOGLEVEL},RFA} >> HADOOP_SECURITY_LOGGER=${HADOOP_SECURITY_LOGGER:-INFO,NullAppender} >> >> So it seems you need this for more than just the root logger. >> >> Second, you are asking us to accept “level, appender” as the value and >> under the covers split the >> value and assign the level to the level attribute and the appender name to >> the AppenderRef. >> >> While this certainly can be done it seems like it would be just as easy to >> do the split in the script >> and create two different variables for the logging configuration to pick >> up. Is there a reason that >> you can’t do this - for example perhaps users have hacked your scripts and >> now you can’t >> change them without breaking them? If so, was this “supported”? >> >> Ralph >> >> >> >>> On Jan 9, 2022, at 8:01 AM, 张铎(Duo Zhang) <[email protected]> wrote: >>> >>> I brought this up in the incubator mailing list, and was suggested to >>> report directly to the log4j community. >>> >>> https://issues.apache.org/jira/browse/HADOOP-16206 >>> >>> In hadoop we started to try migrating to log4j2 long ago, but it is not >>> easy. For now, one of the most blocker issues is the lack of support of >>> 'log4j.rootLogger=INFO,Console' grammar. Notice that we do not want to >> stay >>> on the bridge api, we want to fully migrate to log4j2 finally, so >>> supporting the above grammar in log4j1 bridge is not enough. >>> >>> This is the main log4j configuration file for hadoop >>> >>> >> https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/conf/log4j.properties >>> >>> We have this in the file >>> >>> # Define the root logger to the system property "hadoop.root.logger". >>>> log4j.rootLogger=${hadoop.root.logger} >>> >>> >>> So our users could simply pass -Dhadoop.root.logger to control the level >>> and appender. >>> >>> >> https://github.com/apache/hadoop/blob/39efbc6b6fe53abed15f5639edcbaaa2a9dda6d2/hadoop-common-project/hadoop-common/src/main/bin/hadoop-functions.sh#L904 >>> >>> Here we use an environment variable in our start up scripts. And I >> believe >>> there are lots of other hadoop deployment systems which will have their >> own >>> start scripts. >>> >>> So in general, it is just impossible for us to drop the >>> -Dhadoop.root.logger way of configuring our logging system. >>> >>> So here I want to ask if it is possible for log4j2 to still support the >>> 'log4j.rootLogger=INFO,Console' grammar. I'm not saying you must add it >>> back with no change, we just need a way to configure the level and >> appeners >>> at once, so something like >>> 'log4j2.rootLogger.levelAndAppender=INFO,Console' is also OK. >>> >>> Thanks. >> >>
