Page History

...

• FQCN -- Fully-qualified class name which is used as the name of the logger that is declared at the top of the class or the class’s root ancestor. Example:

final Logger log = LogManager.getLogger(getClass());

...

final Logger log = LogManager.getLogger(); // automatically uses getClass()

• MDC -- Mapped Diagnostic Context which is an optional ThreadLocal map of value(s) that can be used for detailed debugging and tracing

...

6.3 Log statements should be updated to use Log4J 2’s parameterization:

if (log.isDebugEnabled()) {   
  log.debug("Hi, " + string1 + " " + string2);
}

 Becomes:

log.debug("Hi, {} {}", string1, string2);

See 7.6. for more details.

6.4 Markers will be used to further organize logging by component or service layer in order to facilitate filtering and debugging beyond what is already provided by fully-qualified class name categories. Markers can extend other Markers, but a log statement cannot specify two unrelated Markers. I propose adding an interface to com.gemstone.gemfire.logging which defines all of our product Markers with extensive javadocs so that users can a) be aware of the Markers so they know what they can filter on, b) log with our Markers if they so desire. TODO: specify a possible set of Markers in section 6

...

7 Architectural Description

7.1 Overview of Architecture

GemFire product code will be updated to use a private static Logger defined in every class using the fully-qualified class name as the name of its Logger. Example:

...

private static final Logger log = LogService.getLogger();

...

In some special cases it might be beneficial to define a non-static Logger in a superclass and allow subclasses to use it:

protected final Logger log = LogService.getLogger(getClass());

...

Customer APIs that return LogWriter will be deprecated and return an instance of LogWriterLogger which delegates to a Logger named “com.gemstone.gemfire”.

If the deprecated logging configuration log-file, log-file-size-limit, log-disk-space-limit are set, then GemFire will register a LogWriterAppender that is configured with these properties.

Everything in this overview will be detailed further below.

7.2 Configuration of Log4J 2

GemFire will be using Log4J 2 and will simply allow Logging to be configured in the way that users configure Log4J 2, which is done with a log4j2.xml file.

Default log4j2.xml for GemFire will maintain the pre-existing format of logging messages.

Logging will append to stdout and one or more Appenders that GemFire registers internally for Alerting, legacy “log-” logging, Security, etc. By default Log4J 2 will not be logging to a file. This can be enabled by replacing or editing the log4j2.xml file. The legacy logging properties “log-” will configure the LogWriterAppender which uses the ManagerLogWriter to log to file.

User documentation will specify and provide examples of recommended log4j2.xml settings.

Documentation should recommend file rolling will be enabled “OnStartup” using OnStartupTriggeringPolicy. This means that at process startup, log file will roll to create a new one which will have the banner logged to it same as always. Additional trigger policy and rolling details as provided by Log4J 2 should be covered.

Appenders section in default log4j2.xml is simple:

...

<Appenders>
 <Console name="STDOUT" target="SYSTEM_OUT">
   <PatternLayout pattern="${gemfire-pattern}"/>
 </Console>
</Appenders>

PatternLayout requires a custom com.gemstone.gemfire.logging.internal.log4j.ThreadIdPatternConverter class that extends LogEventPatternConverter so that we can provide the ThreadId which is part of the log line of the old LogWriter format.

The default GemFire PatternLayout looks like (TODO: add in Marker and LoggerName):

...

<Property name="gemfire-pattern">[%level{lowerCase=true} %date{yyyy/MM/dd HH:mm:ss.SSS z} &lt;%thread&gt; tid=%tid] %message%n%throwable%n</Property>

...

The legacy GemFire PatternLayout is only used for LogWriterAppender when “log-” properties are configured and looks like:

...

<Property name="logwriter-gemfire-pattern">[%level{TRACE=finer, DEBUG=fine, INFO=info, WARN=warning, ERROR=error, FATAL=severe} %date{yyyy/MM/dd HH:mm:ss.SSS z} &lt;%thread&gt; tid=%tid] %message%n%throwable%n</Property>

The default Loggers section for GemFire loggers looks like:

...

<Logger name="com.gemstone.gemfire" level="INFO" additivity="false">
 <AppenderRef ref="STDOUT"/>
</Logger>

...

Example of adding a log4j2 RollingFileAppender to enable logging to a file with rolling support instead of relying on the LogWriterAppender that provides backwards compatibility:

<RollingFile name="ROLLINGFILE" fileName="server1.log"
    filePattern="server1-%i.log">
 <PatternLayout>
   <pattern>${gemfire-pattern}</pattern>
 </PatternLayout>
 <Policies>
   <OnStartupTriggeringPolicy />
   <SizeBasedTriggeringPolicy size="2 GB"/>
 </Policies>
 <DefaultRolloverStrategy max="20"/>
</RollingFile>

...

GFSH command “alter runtime” allows the “log-level” and several other gemfire properties to be altered at runtime. This will control the “log-level” of the LogWriterAppender only.

New GFSH command “alter logging” will need to be introduced eventually that will allow either remote manipulation of a process’s log4j2.xml or the log4j2 MBean. This would allow the user to enable/disable markers and filters as well as altering logging level per appenders or categories. I think this is not absolutely required for initial release but is a nice-to-have if there is time.

7.3 Deprecated Logging Configuration

...