You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Ralph Goers (JIRA)" <ji...@apache.org> on 2018/09/06 21:36:00 UTC

[jira] [Commented] (LOG4J2-2435) Unrecognized conversion specifier [logger] from Junit5 with Java 10 and locale C

    [ https://issues.apache.org/jira/browse/LOG4J2-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16606419#comment-16606419 ] 

Ralph Goers commented on LOG4J2-2435:
-------------------------------------

From your log it looks like you are suffering from an endless loop and a stack overflow error. The constructor of the Date pattern converter is calling the Calendar class. That ends up calling the PlatformLogger and you have that redirected to Log4j. So Log4j is not able to successfully initialize becaues when PlatformLogger calls Log4j there is no LoggerContext yet. We try to create one, which causes initialization, which calls the Calendar class and on and on it goes.

> Unrecognized conversion specifier [logger] from Junit5 with Java 10 and locale C
> --------------------------------------------------------------------------------
>
>                 Key: LOG4J2-2435
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-2435
>             Project: Log4j 2
>          Issue Type: Bug
>    Affects Versions: 2.11.0, 2.11.1
>         Environment: * Linux (Ubuntu 18.04 with kernel 4.15),
>  * OpenJDK 10.0.2,
>  * Log4J 2.11.1,
>  * Log4J as JUL LogManager,
>  * Junit 5.2.0,
>  * LC_ALL="C.UTF-8"
>            Reporter: Benedykt Jaworski
>            Priority: Major
>
> I am not really sure whether it's a problem in Log4j2, or Junit, or Java 10 - looks like Log4J2 one to me, but I don't know how to reproduce it outside of Junit tests.
> When one runs Junit5 tests with
>  * locale set to {{C.UTF-8}},
>  * on a Linux system,
>  * using OpenJDK 10.0.2,
>  * setting a property {{java.util.logging.manager}} to {{org.apache.logging.log4j.jul.LogManager}},
>  * having {{log4j2}} config with {{%logger}} in a pattern layout,
> one gets a very long litany of logging errors before test results, like those:
> {noformat}
> 2018-09-06 14:41:53,535 main ERROR Unrecognized conversion specifier [logger] starting at position 47 in conversion pattern.
> 2018-09-06 14:41:53,538 main ERROR Error creating converter for logger java.lang.reflect.InvocationTargetException
> 	at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> 	at org.apache.logging.log4j.core.pattern.PatternParser.createConverter(PatternParser.java:583)
> 	at org.apache.logging.log4j.core.pattern.PatternParser.finalizeConverter(PatternParser.java:639)
> 	at org.apache.logging.log4j.core.pattern.PatternParser.parse(PatternParser.java:415)
> 	at org.apache.logging.log4j.core.pattern.PatternParser.parse(PatternParser.java:177)
> [ ... VERY LONG STACK TRACE ... ]
> 	at java.base/jdk.internal.logger.DefaultLoggerFinder.getLogger(DefaultLoggerFinder.java:157)
> 	at java.base/jdk.internal.logger.LazyLoggers.getLoggerFromFinder(LazyLoggers.java:389)
> 	at java.base/jdk.internal.logger.LazyLoggers.getLazyLogger(LazyLoggers.java:444)
> 	at java.base/sun.util.logging.PlatformLogger.getLogger(PlatformLogger.java:297)
> 	at java.base/sun.util.locale.provider.LocaleServiceProviderPool.config(LocaleServiceProviderPool.java:125)
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.apache.logging.log4j.core.pattern.LoggerPatternConverter
> 	... 1024 more
> {noformat}
> The full log can be seen there: [https://gist.github.com/silmeth/240930b6fe1d5fbf1c690566ab80e8b3]
> Here is the repo in which the issue is reproduced: [https://github.com/silmeth/logger-test]
> To reproduce it locally, clone it and then run on JDK 10:
> {noformat}
> $ LC_ALL="C.UTF-8" ./gradlew test
> {noformat}
> The same errors are seen if the class {{JupiterTest}} is run within IntelliJ Junit test runner with environment variable {{LC_ALL}} set to {{C.UTF-8}} and {{-Djava.util.logging.manager="org.apache.logging.log4j.jul.LogManager"}} passed to the JVM.
> I cannot reproduce it outside of Junit5. If one runs the {{Main}} class, it behaves correctly:
> {noformat}
> $ LC_ALL="C.UTF-8" ./gradlew run                                     
> > Task :run
> 2018-09-06 15:28:32,580 main INFO Registered Log4j as the java.util.logging.LogManager.
> 15:28:32.737 [main] INFO  test.Main - Locale: en, JVM: 10.0.2
> Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0.
> Use '--warning-mode all' to show the individual deprecation warnings.
> See https://docs.gradle.org/4.10/userguide/command_line_interface.html#sec:command_line_warnings
> BUILD SUCCESSFUL in 2s
> 3 actionable tasks: 2 executed, 1 up-to-date
> {noformat}
> and:
> {noformat}
> $ LC_ALL="C.UTF-8" java -Djava.util.logging.manager="org.apache.logging.log4j.jul.LogManager" -jar ./build/libs/logger-test-all.jar
> 2018-09-06 15:31:00,942 main INFO Registered Log4j as the java.util.logging.LogManager.
> 15:31:01.140 [main] INFO  test.Main - Locale: en, JVM: 10.0.2
> {noformat}
> Also running the tests on non-C locale (I tried both {{en_US.UTF-8}} and {{pl_PL.UTF-8}}) shows correct behaviour inside the Junit5:
> {noformat}
> $ LC_ALL="en_US.UTF-8" ./gradlew test
> > Task :test
> 15:35:16.665 [Test worker] INFO  test.JupiterTest - JupiterTest - Locale: en_US, JVM: 10.0.2
> 15:35:16.757 [Test worker] INFO  test.VintageTest - VintageTest - Locale: en_US, JVM: 10.0.2
> Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0.
> Use '--warning-mode all' to show the individual deprecation warnings.
> See https://docs.gradle.org/4.10/userguide/command_line_interface.html#sec:command_line_warnings
> BUILD SUCCESSFUL in 9s
> 5 actionable tasks: 5 executed
> {noformat}
> I also couldn't reproduce it on Java 8, so it seems to be Java 10 (or perhaps Java 9) related.
> This is a problem for a company I work for, because we run our gradle tests in a docker image {{library/openjdk}} which has locale set to {{C.UTF-8}} by default.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)