[LOG4J2-2945] Better validation and messaging for classpath issues

• Type: Improvement
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: 2.13.3
• Component/s: Boot, Core
• Assignee: Carter Kozak
• Reporter: Michiel Graat
• Created: 13/Oct/20 15:09
• Updated: 13/Oct/20 15:11

Description

Hi,

Carter Kozak suggested I created an issue for this on the mailing list. While migrating from Log4J 1.x to Log4J2 I accidently left a stray Log4J 1.x JAR in my application artifact (and thus on the classpath). This lead to some strange behavior: the logging to the root appender worked, but the other loggers I defined where ignored (that is, the files were created but they remained empty). 

It was never clear there was a classpath issue, even the Log4J2 trace logging gave no further information.

So this is a request to improve the validation and messaging on this issue.

Carter suggested the following as a starting point:

I've written similar validation for slf4j bindings elsewhere that we may be able to leverage (though the general case has many edge cases that I haven't thought through yet):

/**
* Validate that there is only one slf4j binding present. If there are multiple distinct bindings logging will
* disappear into the void depending on classpath order.
*/
private static void validateSlf4jBindings() {
    try {
        List<URL> slf4jBindings = Collections.list(
                getClassLoader().getResources("org/slf4j/impl/StaticLoggerBinder.class"));
        if (slf4jBindings.size() > 1) {
            String message = "Detected multiple Slf4j bindings: " + slf4jBindings;
            // Write to standard streams, if the exception is caught and logged, it may not be recorded.
            System.err.println(message);
            throw new IllegalStateException(message);
        }
    } catch (IOException e) {
        throw new IllegalStateException("Failed to discover slf4j bindings", e);
    }
}

Cheers,

Michiel