Changes under consideration for SLF4J version 2.1.0

[ceki]

We are looking for feedback regarding two SLF4J API changes under consideration for version 2.1.0.

The changes under consideration are discussed in separate pages:

• MDCAmbit
• fluent API additions
• MDC + Context Propagation Feature Request
• bump the Java requirement to version 11 instead of Java 8

You can make new requests below.

[michael-o]

As mentioned #379, 2.x should stay on Java 8 for the time being.

[dmatej]

Actually I would vote to go to 17 at least. Even Jakarta EE goes for 21 and just for few projects still supports 17.

[arkamsterdam]

I always include something like the class below into my projects. I would very much like to see this standardised, either as a utility method or directly as an added getLogger method in the LoggerFactory class. Off course, this would need Java 9 as it uses theStackWalker api.

package com.example;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.lang.StackWalker.StackFrame;
import static java.lang.StackWalker.Option.RETAIN_CLASS_REFERENCE;

public abstract class ClassLogger {

    private static final Class<?> DEFAULT_CLASS_LOGGER = ClassLogger.class;

    private ClassLogger() {
    }

    /**
     * Typically inside a class {@code MyClass} one would create a {@code Logger} like
     *  {@code LoggerFactory.getLogger(MyClass.class)}.
     * This utility method allows you to leave out the class parameter. The class that calls this method is then
     * used to create a {@code logger}.
     *
     * @return an SLF4J @{code Logger} with a name that equals the name of the class of the calling method
     */
    public static Logger create() {
        StackWalker walker = StackWalker.getInstance(RETAIN_CLASS_REFERENCE);
        Class<?> callerType = walker.walk(stream -> stream.skip(1).findFirst()
                .map(StackFrame::getDeclaringClass)
                .orElse(DEFAULT_CLASS_LOGGER));
        return LoggerFactory.getLogger(callerType);
    }
}

[ppkarwasz]

Basically you are looking for an equivalent of the LogManager.getLogger() method from the Log4j API?

Such a feature does not require Java 9. It can be implemented with any Java version.

[arkamsterdam]

If one uses Log4j, then yes that method is available. The question however was for new features in Slf4j. I mostly use Slf4j with Logback as implementation.

And yes, the method above could be recreated in any version of Java if one creates an exception and retrieves the class name of the calling class from the stack trace in that exception. But that is not the point. My reply should be read as an implicit 'yes' to the question 'should we bump to Java version 11?'. And that is of course next to the explicit call for this added functionality.

[windmueller]

Such a feature does not require Java 9. It can be implemented with any Java version.

Well, have you seen the implementation as well as the explanation in the Javadoc? Their new implementation also facilitates the StackWalker. In my opinion this is the way to go.

[ppkarwasz]

o.a.l.l.util.StackLocatorUtil is not part of the public API of log4j-api. It is only used by implementations to provide an implementation of the LogManager.getLogger() method.

IMHO this kind of helpers should not be part of a logging API and come at a price: an implementation of Log4j API 2.24 that uses o.a.l.l.util.StackLocatorUtil, will not work with log4j-api version 2.8.2.

[windmueller]

I was not talking about making any locator part of the logger API. This was just a response to your claim that "such a feature does not require Java 9". Yes, it is possible with older Java versions, but only with a lot of hacks.

[cjw129]

Please, add info(String format, Supplier<?>... args) method to Logger class. Here is the guide that my company gave me to modify the code. But slf4j is not supported, so it is difficult to explain to other developers. T^T
https://docs.pmd-code.org/latest/pmd_rules_java_bestpractices.html#guardlogstatement

[ppkarwasz]

SLF4J already supports j.u.f.Supplier in its LoggingEventBuilder interface, e.g.:

log.atDebug().addArgument(this::calculateExpensiveLoggingTest).log("log something expensive: {}");

The example you see on the PMD page only applies to Log4j API (version 2.4 or higher):

log.debug("log something expensive: {}", this::calculateExpensiveLoggingText);

Note: IMHO guard log statements are a bad practice in SLF4J, since they prevent logging backend features such as Logback's turbofilters or Log4j Core's global filters from working correctly: the log statement is skipped before those filters get a chance to evaluate it.

[cjw129]

The example you see on the PMD page only applies to Log4j API (version 2.4 or higher):

So I would like to ask Slf4j to provide the same API to explain to other developers according to the method shown in the guide.

[nemunas-karalius]

It would be nice to have some simple (-er) mechanism to intercept all logging calls through the loggers returned by LoggerFactory (e.g. to be able to filter sensitive data from the logs).

Currently you can create a proxy ILoggerFactory for constructing proxy Loggers. Unfortunately this solution seems cumbersome/complicated:

1. You can register a proxy SLF4JServiceProvider using system property which would return proxy ILoggerFactory. Unfortunately it appears that existing libs/frameworks depend on the specific ILoggerFactory implementations returned by LoggerFactory.getILoggerFactory() to be able to configure the underlying logging system. E.g. Spring application fails to start at all if LoggerFactory.getILoggerFactory returns non-logback (proxy) ILoggerFactory when logback is in the classpath.
2. You could explicitly use your proxy ILoggerFactory everywhere in the code instead of SLF4J LoggerFactory. But such solution defies the purpose of SLF4J to be the single facade for all logging: you’ll need to change lot’s of lines in your application; also such solution is not applicable then logging is done by the libs you do not control.
3. Interception most probably is possible in a specific logging backend. E.g. in logback you could write custom Appenders / Layouts. But you would need separate implementations for each different logging backend (and would need to extend multiple appenders if different appenders are configured by your application).

A probably nicer solution would be to have a built-in possibility to configure some dedicated interceptor/proxy generating class (e.g. LoggerProxyFactory / LoggerCreationInterceptor / ?) with a help of System property and/or ServiceLoader. LoggerProxyFactory could create proxy Logger objects for wrapping Logger objects returned by application ILoggerFactory and would do this only during the calls to org.slf4j.LoggerFactory#getLogger. Therefore we would split (I)LoggerFactory usage into 2 distinct cases:

1. LoggerFactory#getLogger - the method which is usually used by the “business” code to retrieve loggers for actual logging, would return a logger wrapped in an interceptor/proxy.
2. SLF4JServiceProvider#getLoggerFactory , ILoggerFactory#getLogger - methods which usually are used by apps/frameworks to configure underlying logging library/backend, would continue to work as before by returning raw (not proxied) implementations (and so will not break existing libs/frameworks)