You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Michiel Graat (Jira)" <ji...@apache.org> on 2020/10/13 15:11:00 UTC
[jira] [Updated] (LOG4J2-2945) Better validation and messaging for
classpath issues
[ https://issues.apache.org/jira/browse/LOG4J2-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michiel Graat updated LOG4J2-2945:
----------------------------------
Description:
Hi,
[~ckozak] suggested I created an issue for this on the [mailing list|https://lists.apache.org/thread.html/r1de0b24e43b126bc6c05c1b092b18c8bbb3c1418a289c46cb485aa0f%40%3Clog4j-user.logging.apache.org%3E]. 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:
{quote}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):
{code}/**
* 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);
}
}
{code}
{quote}
Cheers,
Michiel
was:
Hi,
[~ckozak] suggested I created an issue for this on the [mailing list|https://lists.apache.org/thread.html/r1de0b24e43b126bc6c05c1b092b18c8bbb3c1418a289c46cb485aa0f%40%3Clog4j-user.logging.apache.org%3E]. 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:
{quote}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);}}
{{ }}}
{{}}}{quote}
Cheers,
Michiel
> Better validation and messaging for classpath issues
> ----------------------------------------------------
>
> Key: LOG4J2-2945
> URL: https://issues.apache.org/jira/browse/LOG4J2-2945
> Project: Log4j 2
> Issue Type: Improvement
> Components: Boot, Core
> Affects Versions: 2.13.3
> Reporter: Michiel Graat
> Priority: Minor
>
> Hi,
> [~ckozak] suggested I created an issue for this on the [mailing list|https://lists.apache.org/thread.html/r1de0b24e43b126bc6c05c1b092b18c8bbb3c1418a289c46cb485aa0f%40%3Clog4j-user.logging.apache.org%3E]. 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:
> {quote}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):
> {code}/**
> * 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);
> }
> }
> {code}
> {quote}
> Cheers,
> Michiel
--
This message was sent by Atlassian Jira
(v8.3.4#803005)