apurtell commented on a change in pull request #4096:
URL: https://github.com/apache/hbase/pull/4096#discussion_r801012711
##########
File path: bin/hbase
##########
@@ -751,8 +751,8 @@ elif [ "$COMMAND" = "hbtop" ] ; then
done
fi
- if [ -f "${HBASE_HOME}/conf/log4j-hbtop.properties" ] ; then
- HBASE_HBTOP_OPTS="${HBASE_HBTOP_OPTS}
-Dlog4j.configuration=file:${HBASE_HOME}/conf/log4j-hbtop.properties"
+ if [ -f "${HBASE_HOME}/conf/log4j2-hbtop.properties" ] ; then
+ HBASE_HBTOP_OPTS="${HBASE_HBTOP_OPTS}
-Dlog4j2.configurationFile=file:${HBASE_HOME}/conf/log4j2-hbtop.properties"
Review comment:
Maybe this work will resolve the issue I see starting hbtop with latest
branch-2 HEAD
Exception in thread "main" java.lang.NoClassDefFoundError:
org/slf4j/bridge/SLF4JBridgeHandler
at
org.apache.hadoop.hbase.logging.JulToSlf4jInitializer.<clinit>(JulToSlf4jInitializer.java:36)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
This can be "fixed" by removing the JUL to SLF4J bridge stuff from default
HBASE_OPTS. Seems not appropriate as a generic option for all processes.
I wonder if hbtop should have logging system properties set at all. It is a
curses based command line application, not a daemon. If it has anything to
log/print, it should go to the console.
##########
File path: conf/log4j2.properties
##########
@@ -0,0 +1,135 @@
+#/**
Review comment:
Why can't we continue to use the existing properties file that ships in
HEAD of branch-2? It is because even with the Log4J 1 compatibility stuff we
still can't make it compatible with the log4j1 properties files?
For operational compatibility in minor releases, after users upgrade their
existing logging configuration should still work. It's fine to recommend that
they make changes, like a switch to the XML format, to gain access to
improvements, but it would appear log4j has decided to make arbitrary changes
that break existing configurations still, so logging wouldn't work if the user
doesn't port.
Here are the first few lines from log4j.properties in branch-2.
# Define some default values that can be overridden by system properties
hbase.root.logger=INFO,console
hbase.security.logger=INFO,console
hbase.log.dir=.
hbase.log.file=hbase.log
hbase.log.level=INFO
# Define the root logger to the system property "hbase.root.logger".
log4j.rootLogger=${hbase.root.logger}
# Logging Threshold
log4j.threshold=ALL
#
# Daily Rolling File Appender
#
log4j.appender.DRFA=org.apache.log4j.DailyRollingFileAppender
log4j.appender.DRFA.File=${hbase.log.dir}/${hbase.log.file}
It looks like the new properties file format drops the "log4j" prefix? Can
we keep it?
Or, we could implement logic in the launch script that looks at the user's
existing log4j properties file and rewrites it, and uses the rewritten version,
if it detects this?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
