Replace Jetty Logging

[joakime]

Proposal

Drop org.eclipse.jetty.util.log

The entire package org.eclipse.jetty.util.log is deleted

Create jetty-slf4j-impl module

A new module called jetty-slf4j-impl is created.

This module performs the equivalent to Jetty's StdErrLog.

• Same output formatting as StdErrLog in 9.x
• Supports jetty-logging.properties for configuring logging levels

It has a META-INF/services/org.slf4j.spi.SLF4JServiceProvider

A package space of org.eclipse.jetty.logging
A JPMS of jetty-logging ?

This new module would be included as a <scope>test</scope>
across the other Jetty modules that need it for testing.

Migrate logging properties

Existing properties

• org.eclipse.jetty.util.log.class (classname, default "org.eclipse.jetty.util.log.Slf4jLog") - use to select the logger
• org.eclipse.jetty.util.log.announce (boolean, default "true") - used to control announcement text "Logging to {} via {}"
• org.eclipse.jetty.util.log.IGNORED (boolean, default "false") - used to control if Log.ignored() should be shown or not
• org.eclipse.jetty.util.log.StdErrLog.TAG_PAD (number, default "0") - used for minimum padding width of the Thread.name
• org.eclipse.jetty.util.log.SOURCE (boolean, default "false") - used as default for showing of source (filename and line number) in stacktraces
• org.eclipse.jetty.util.log.stderr.SOURCE (boolean, default "false") - used for showing of source (filename and line number) in stacktraces
• org.eclipse.jetty.util.log.stderr.LONG (boolean, default "false") - used for condensing the logger name package
• org.eclipse.jetty.util.log.stderr.ESCAPE (boolean, default "true") - used for escaping the output of the logger message.

Dropped properties

• org.eclipse.jetty.util.log.class - controlled by slf4j-api now
• org.eclipse.jetty.util.log.announce - controlled by slf4j-api now
• org.eclipse.jetty.util.log.SOURCE - we only have 1 logger now.

Renamed properties

• org.eclipse.jetty.logging.IGNORED (boolean, default "true") - used to control if Log.ignored() should be shown or not
• org.eclipse.jetty.logging.THREAD_PADDING (number, default "0") - used for minimum padding width of the Thread.name
• org.eclipse.jetty.logging.SOURCE (boolean, default "false") - used for showing of source (filename and line number) in stacktraces
• org.eclipse.jetty.logging.NAME_CONDENSE (boolean, default "true") - used for condensing the logger name package
• org.eclipse.jetty.logging.MESSAGE_ESCAPE (boolean, default "true") - used for escaping the output of the logger message

Migrate source to use slf4j

Migrate code from ...

import org.eclipse.jetty.util.log.Log;
import org.eclipse.jetty.util.log.Logger;

private static final Logger LOG = Log.getLogger(DoSFilter.class);

... to ...

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

private static final Logger LOG = LoggerFactory.getLogger(DoSFilter.class);

The usage of Log.ignore(Throwable) would need to be migrated as well.

LOG.trace("IGNORED", cause);

The org.eclipse.jetty.util.StacklessLogging would be moved to
org.eclipse.jetty.logging.StacklessLogging (in the new jetty-slf4j-impl
module) to provide the same behaviors as before for testing.

New logging modules for jetty-home

The existing logging modules in Jetty 9.4.x are ...

• console-capture.mod
• jcl-slf4j.mod
• jul-impl.mod
• jul-slf4j.mod
• log4j2-api.mod
• log4j2-impl.mod
• log4j2-slf4j.mod
• log4j-impl.mod
• logback-impl.mod
• logging-jetty.mod
• logging-jul.mod
• logging-log4j.mod
• logging-log4j2.mod
• logging-logback.mod
• logging-slf4j.mod
• slf4j-api.mod
• slf4j-jul.mod
• slf4j-log4j.mod
• slf4j-log4j2.mod
• slf4j-logback.mod
• slf4j-simple-impl.mod

We would simplify this a great deal to just ...

• console-capture.mod
• logging-jetty.mod
• logging-jul.mod
• logging-log4j.mod
• logging-log4j2.mod
• logging-logback.mod

Where each logging module captures all logging implementations
via the various slf4j bridge jars, and enables the appropriate
slf4j implementation jar based on your logging module selection.

The new modules would also no longer force a forking of a JVM.

Originally posted by @joakime in #4567 (comment)

[gregw]

While I think the number of users that program directly to our logging API is small, I'm not sure it is zero. So it probably needs to be deprecated rather than dropped.
But we should be able to simply keep the module that maps the deprecated API to slf4j and make it use the new implementation there.

[joakime]

Opened PR #4997 to address TODO on TAG_PAD