Package org.apache.solr.util

Class StartupLoggingUtils

  • public final class StartupLoggingUtils
extends Object
    Handles programmatic modification of logging during startup

    WARNING: This class should only be used during startup. For modifying log levels etc during runtime, SLF4J and LogWatcher must be used.

    • Constructor Detail

      • StartupLoggingUtils

        public StartupLoggingUtils()

    • Method Detail

      • checkLogDir

        public static void checkLogDir()
        Checks whether mandatory log dir is given

      • getLoggerImplStr

        public static String getLoggerImplStr()

      • muteConsole

        public static boolean muteConsole()
        Disables all log4j2 ConsoleAppender's by modifying log4j configuration dynamically. Must only be used during early startup
        Returns:
        true if ok or else false if something happened, e.g. log4j2 classes were not in classpath

      • changeLogLevel

        public static boolean changeLogLevel​(String logLevel)
        Dynamically change log4j log level through property solr.log.level
        Parameters:
        logLevel - String with level, should be one of the supported, e.g. TRACE, DEBUG, INFO, WARN, ERROR...
        Returns:
        true if ok or else false if something happened, e.g. log4j classes were not in classpath

      • shutdown

        public static void shutdown()
        Perhaps odd to put in startup utils, but this is where the logging-init code is so it seems logical to put the shutdown here too.

        Tests are particularly sensitive to this call or the object release tracker will report "lmax.disruptor" not terminating when asynch logging (new default as of 8.1) is enabled.

        Expert, there are rarely good reasons for this to be called outside of the test framework. If you are tempted to call this for running Solr, you should probably be using synchronous logging.

      • flushAllLoggers

        public static void flushAllLoggers()
        This is primarily for tests to insure that log messages don't bleed from one test case to another, see: SOLR-13268.

        However, if there are situations where we want to insure that all log messages for all loggers are flushed, this method can be called by anyone. It should _not_ affect Solr in any way except, perhaps, a slight delay while messages are being flushed.

        Expert, there are rarely good reasons for this to be called outside of the test framework. If you are tempted to call this for running Solr, you should probably be using synchronous logging.

      • getLogLevelString

        public static String getLogLevelString()
        Return a string representing the current static ROOT logging level
        Returns:
        a string TRACE, DEBUG, WARN, ERROR or INFO representing current log level. Default is INFO

      • checkRequestLogging

        public static void checkRequestLogging()
        Check whether Jetty request logging is enabled and log info about it. The property "solr.log.requestlog.enabled is set in solr/server/etc/jetty-requestlog.xml