[jira] [Commented] (LOG4J2-3564) NPE in JULLogger.getLevel()
[
https://issues.apache.org/jira/browse/LOG4J2-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608534#comment-17608534
]
ASF subversion and git services commented on LOG4J2-3564:
-
Commit c07927c112e2fa622a4087d5283841dc77c82fbe in logging-log4j2's branch
refs/heads/dependabot/maven/com.github.spotbugs-spotbugs-maven-plugin-4.7.2.0
from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c07927c112 ]
[LOG4J2-3564] Missing changelog
> NPE in JULLogger.getLevel()
> ---
>
> Key: LOG4J2-3564
> URL: https://issues.apache.org/jira/browse/LOG4J2-3564
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-JUL
>Affects Versions: 2.17.2
>Reporter: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> {{JULLogger.getLevel()}} fails with a {{NullPointerException}} if the JUL
> root logger has a {{null}} level. This is a common situation in JDK 8+, since
> {{LogManager$RootLogger}} does not set the log level any more in its
> constructor.
> A practical example where it fails is Tomcat's {{ClassLoaderLogManager}}: cf.
> [BZ 66184|https://bz.apache.org/bugzilla/show_bug.cgi?id=66184].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3188) Concurrent individual LoggerContext initializations cause severe LogEvent drop or incorrect delivery
[
https://issues.apache.org/jira/browse/LOG4J2-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608529#comment-17608529
]
ASF subversion and git services commented on LOG4J2-3188:
-
Commit 5bc48cc9b49b291cb1f41b84fcd1ff2965fa7cf2 in logging-log4j2's branch
refs/heads/dependabot/maven/de.flapdoodle.embed-de.flapdoodle.embed.mongo-3.4.9
from Volkan Yazıcı
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5bc48cc9b4 ]
LOG4J2-3188 Create a fresh LoggerContext in
JsonTemplateLayoutConcurrentEncodeTest.
> Concurrent individual LoggerContext initializations cause severe LogEvent
> drop or incorrect delivery
>
>
> Key: LOG4J2-3188
> URL: https://issues.apache.org/jira/browse/LOG4J2-3188
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> When multiple {{LoggerContext}}'s get initialized concurrently, they affect
> each other causing severe {{LogEvent}} drop and incorrect delivery. Consider
> the following test:
> {code:java}
> @Execution(ExecutionMode.SAME_THREAD)
> class ParallelRunTest {
> @ParameterizedTest
> @ValueSource(chars = {'A', 'B', 'C', 'D'})
> void test(final char letter) {
> // Create the configuration builder.
> final ConfigurationBuilder configBuilder =
> ConfigurationBuilderFactory
> .newConfigurationBuilder()
> .setStatusLevel(Level.ERROR)
> .setConfigurationName("Letter-" + letter);
> // Create the configuration.
> final String appenderName = "File";
> final String appenderFilepath = Paths
> .get(
> System.getProperty("java.io.tmpdir"),
> "ParallelRunTest-" + letter + ".log")
> .toAbsolutePath()
> .toString();
> final Configuration config = configBuilder
> .add(configBuilder
> .newAppender(appenderName, "File")
> .addAttribute("fileName", appenderFilepath)
> .addAttribute("append", false)
> .addAttribute("immediateFlush", false)
> .addAttribute("ignoreExceptions", false)
> .add(configBuilder
> .newLayout("PatternLayout")
> .addAttribute("pattern", "%m\n")))
> .add(configBuilder
> .newRootLogger(Level.ALL)
> .add(configBuilder.newAppenderRef(appenderName)))
> .build(false);
> // Initialize the configuration.
> try (final LoggerContext loggerContext =
> Configurator.initialize(config)) {
> final Logger logger =
> loggerContext.getLogger(ParallelRunTest.class);
> // Write logs.
> final String message = Strings.repeat(String.valueOf(letter),
> 999);
> for (int i = 0; i < 1_000; i++) {
> logger.info(message);
> }
> }
> // Verify the file content.
> final long appenderFileLength = new File(appenderFilepath).length();
> assertThat(appenderFileLength).isEqualTo(1_000_000L);
> }
> }
> {code}
> Above test, given a {{letter}}, creates a {{ParallelRunTest-.log}}
> file, and writes 999 times that letter to each line (ending with a line-feed
> character) for 1,000 lines. The eventual file is expected to be of size
> {{lineLength * lineCount = 1,000 * 1,000 = 1e6}}. These assumptions indeed
> hold after a run:
> {code}
> wc -l /tmp/ParallelRunTest-*
>1000 /tmp/ParallelRunTest-A.log
>1000 /tmp/ParallelRunTest-B.log
>1000 /tmp/ParallelRunTest-C.log
>1000 /tmp/ParallelRunTest-D.log
>4000 total
> for log_file in /tmp/ParallelRunTest-*; do
> echo "file: $log_file"
> echo "line lengths:"
> awk "{print length}" $log_file | sort | uniq
> echo "distinct lines:"
> sort $log_file | uniq
> echo
> done
> file: /tmp/ParallelRunTest-A.log
> line lengths:
> 999
> distinct lines:
> AAA...A
> file: /tmp/ParallelRunTest-B.log
> line lengths:
> 999
> distinct lines:
> BBB...B
> file: /tmp/ParallelRunTest-C.log
> line lengths:
> 999
> distinct lines:
> CCC...C
> file: /tmp/ParallelRunTest-D.log
> line lengths:
> 999
> distinct lines:
> DDD...D
> {code}
> Though when {{ExecutionMode.SAME_THREAD}} is replaced with
> {{ExecutionMode.CONCURRENT}} tests fail due to unexpected
> {{appenderFileLength}}:
> {code}
> wc -l /tmp/ParallelRunTest-*
> 96 /tmp/ParallelRunTest-A.log
> 1 /tmp/ParallelRunTest-B.log
> 96 /tmp/ParallelRunTest-C.log
>3577 /
[jira] [Commented] (LOG4J2-708) Servlet filter claims to support async but doesn't use AsyncContext
[ https://issues.apache.org/jira/browse/LOG4J2-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608533#comment-17608533 ] ASF subversion and git services commented on LOG4J2-708: Commit 432a851f0381a7bf9417a79ea9f9c64748b3020e in logging-log4j2's branch refs/heads/dependabot/maven/com.github.spotbugs-spotbugs-maven-plugin-4.7.2.0 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=432a851f03 ] [LOG4J2-708] Improve `Log4jServletFilter` async behavior The `Log4jServletFilter` filter should run on all the threads a request is run. The current version ignores all async dispatches. > Servlet filter claims to support async but doesn't use AsyncContext > --- > > Key: LOG4J2-708 > URL: https://issues.apache.org/jira/browse/LOG4J2-708 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.0-rc2 > Environment: Servlet 3.0 (Tomcat 7, Jetty 8) or higher >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Minor > Fix For: 2.19.1 > > > In log4j-web, when the ServletContainerInitializer adds the Log4j Filter, it > sets the asyncSupported property to true. However, it's still a synchronous > Filter. > A separate asynchronous Filter should be made for Servlet 3.x support that > doesn't break Servlet 2.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3188) Concurrent individual LoggerContext initializations cause severe LogEvent drop or incorrect delivery
[
https://issues.apache.org/jira/browse/LOG4J2-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608532#comment-17608532
]
ASF subversion and git services commented on LOG4J2-3188:
-
Commit 5bc48cc9b49b291cb1f41b84fcd1ff2965fa7cf2 in logging-log4j2's branch
refs/heads/dependabot/maven/org.hsqldb-hsqldb-2.7.0 from Volkan Yazıcı
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5bc48cc9b4 ]
LOG4J2-3188 Create a fresh LoggerContext in
JsonTemplateLayoutConcurrentEncodeTest.
> Concurrent individual LoggerContext initializations cause severe LogEvent
> drop or incorrect delivery
>
>
> Key: LOG4J2-3188
> URL: https://issues.apache.org/jira/browse/LOG4J2-3188
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> When multiple {{LoggerContext}}'s get initialized concurrently, they affect
> each other causing severe {{LogEvent}} drop and incorrect delivery. Consider
> the following test:
> {code:java}
> @Execution(ExecutionMode.SAME_THREAD)
> class ParallelRunTest {
> @ParameterizedTest
> @ValueSource(chars = {'A', 'B', 'C', 'D'})
> void test(final char letter) {
> // Create the configuration builder.
> final ConfigurationBuilder configBuilder =
> ConfigurationBuilderFactory
> .newConfigurationBuilder()
> .setStatusLevel(Level.ERROR)
> .setConfigurationName("Letter-" + letter);
> // Create the configuration.
> final String appenderName = "File";
> final String appenderFilepath = Paths
> .get(
> System.getProperty("java.io.tmpdir"),
> "ParallelRunTest-" + letter + ".log")
> .toAbsolutePath()
> .toString();
> final Configuration config = configBuilder
> .add(configBuilder
> .newAppender(appenderName, "File")
> .addAttribute("fileName", appenderFilepath)
> .addAttribute("append", false)
> .addAttribute("immediateFlush", false)
> .addAttribute("ignoreExceptions", false)
> .add(configBuilder
> .newLayout("PatternLayout")
> .addAttribute("pattern", "%m\n")))
> .add(configBuilder
> .newRootLogger(Level.ALL)
> .add(configBuilder.newAppenderRef(appenderName)))
> .build(false);
> // Initialize the configuration.
> try (final LoggerContext loggerContext =
> Configurator.initialize(config)) {
> final Logger logger =
> loggerContext.getLogger(ParallelRunTest.class);
> // Write logs.
> final String message = Strings.repeat(String.valueOf(letter),
> 999);
> for (int i = 0; i < 1_000; i++) {
> logger.info(message);
> }
> }
> // Verify the file content.
> final long appenderFileLength = new File(appenderFilepath).length();
> assertThat(appenderFileLength).isEqualTo(1_000_000L);
> }
> }
> {code}
> Above test, given a {{letter}}, creates a {{ParallelRunTest-.log}}
> file, and writes 999 times that letter to each line (ending with a line-feed
> character) for 1,000 lines. The eventual file is expected to be of size
> {{lineLength * lineCount = 1,000 * 1,000 = 1e6}}. These assumptions indeed
> hold after a run:
> {code}
> wc -l /tmp/ParallelRunTest-*
>1000 /tmp/ParallelRunTest-A.log
>1000 /tmp/ParallelRunTest-B.log
>1000 /tmp/ParallelRunTest-C.log
>1000 /tmp/ParallelRunTest-D.log
>4000 total
> for log_file in /tmp/ParallelRunTest-*; do
> echo "file: $log_file"
> echo "line lengths:"
> awk "{print length}" $log_file | sort | uniq
> echo "distinct lines:"
> sort $log_file | uniq
> echo
> done
> file: /tmp/ParallelRunTest-A.log
> line lengths:
> 999
> distinct lines:
> AAA...A
> file: /tmp/ParallelRunTest-B.log
> line lengths:
> 999
> distinct lines:
> BBB...B
> file: /tmp/ParallelRunTest-C.log
> line lengths:
> 999
> distinct lines:
> CCC...C
> file: /tmp/ParallelRunTest-D.log
> line lengths:
> 999
> distinct lines:
> DDD...D
> {code}
> Though when {{ExecutionMode.SAME_THREAD}} is replaced with
> {{ExecutionMode.CONCURRENT}} tests fail due to unexpected
> {{appenderFileLength}}:
> {code}
> wc -l /tmp/ParallelRunTest-*
> 96 /tmp/ParallelRunTest-A.log
> 1 /tmp/ParallelRunTest-B.log
> 96 /tmp/ParallelRunTest-C.log
>3577 /tmp/ParallelRunTest-D.log
>
[jira] [Commented] (LOG4J2-708) Servlet filter claims to support async but doesn't use AsyncContext
[ https://issues.apache.org/jira/browse/LOG4J2-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608530#comment-17608530 ] ASF subversion and git services commented on LOG4J2-708: Commit 432a851f0381a7bf9417a79ea9f9c64748b3020e in logging-log4j2's branch refs/heads/dependabot/maven/org.hsqldb-hsqldb-2.7.0 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=432a851f03 ] [LOG4J2-708] Improve `Log4jServletFilter` async behavior The `Log4jServletFilter` filter should run on all the threads a request is run. The current version ignores all async dispatches. > Servlet filter claims to support async but doesn't use AsyncContext > --- > > Key: LOG4J2-708 > URL: https://issues.apache.org/jira/browse/LOG4J2-708 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.0-rc2 > Environment: Servlet 3.0 (Tomcat 7, Jetty 8) or higher >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Minor > Fix For: 2.19.1 > > > In log4j-web, when the ServletContainerInitializer adds the Log4j Filter, it > sets the asyncSupported property to true. However, it's still a synchronous > Filter. > A separate asynchronous Filter should be made for Servlet 3.x support that > doesn't break Servlet 2.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3564) NPE in JULLogger.getLevel()
[
https://issues.apache.org/jira/browse/LOG4J2-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608531#comment-17608531
]
ASF subversion and git services commented on LOG4J2-3564:
-
Commit c07927c112e2fa622a4087d5283841dc77c82fbe in logging-log4j2's branch
refs/heads/dependabot/maven/org.hsqldb-hsqldb-2.7.0 from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c07927c112 ]
[LOG4J2-3564] Missing changelog
> NPE in JULLogger.getLevel()
> ---
>
> Key: LOG4J2-3564
> URL: https://issues.apache.org/jira/browse/LOG4J2-3564
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-JUL
>Affects Versions: 2.17.2
>Reporter: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> {{JULLogger.getLevel()}} fails with a {{NullPointerException}} if the JUL
> root logger has a {{null}} level. This is a common situation in JDK 8+, since
> {{LogManager$RootLogger}} does not set the log level any more in its
> constructor.
> A practical example where it fails is Tomcat's {{ClassLoaderLogManager}}: cf.
> [BZ 66184|https://bz.apache.org/bugzilla/show_bug.cgi?id=66184].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3188) Concurrent individual LoggerContext initializations cause severe LogEvent drop or incorrect delivery
[
https://issues.apache.org/jira/browse/LOG4J2-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608535#comment-17608535
]
ASF subversion and git services commented on LOG4J2-3188:
-
Commit 5bc48cc9b49b291cb1f41b84fcd1ff2965fa7cf2 in logging-log4j2's branch
refs/heads/dependabot/maven/com.github.spotbugs-spotbugs-maven-plugin-4.7.2.0
from Volkan Yazıcı
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5bc48cc9b4 ]
LOG4J2-3188 Create a fresh LoggerContext in
JsonTemplateLayoutConcurrentEncodeTest.
> Concurrent individual LoggerContext initializations cause severe LogEvent
> drop or incorrect delivery
>
>
> Key: LOG4J2-3188
> URL: https://issues.apache.org/jira/browse/LOG4J2-3188
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> When multiple {{LoggerContext}}'s get initialized concurrently, they affect
> each other causing severe {{LogEvent}} drop and incorrect delivery. Consider
> the following test:
> {code:java}
> @Execution(ExecutionMode.SAME_THREAD)
> class ParallelRunTest {
> @ParameterizedTest
> @ValueSource(chars = {'A', 'B', 'C', 'D'})
> void test(final char letter) {
> // Create the configuration builder.
> final ConfigurationBuilder configBuilder =
> ConfigurationBuilderFactory
> .newConfigurationBuilder()
> .setStatusLevel(Level.ERROR)
> .setConfigurationName("Letter-" + letter);
> // Create the configuration.
> final String appenderName = "File";
> final String appenderFilepath = Paths
> .get(
> System.getProperty("java.io.tmpdir"),
> "ParallelRunTest-" + letter + ".log")
> .toAbsolutePath()
> .toString();
> final Configuration config = configBuilder
> .add(configBuilder
> .newAppender(appenderName, "File")
> .addAttribute("fileName", appenderFilepath)
> .addAttribute("append", false)
> .addAttribute("immediateFlush", false)
> .addAttribute("ignoreExceptions", false)
> .add(configBuilder
> .newLayout("PatternLayout")
> .addAttribute("pattern", "%m\n")))
> .add(configBuilder
> .newRootLogger(Level.ALL)
> .add(configBuilder.newAppenderRef(appenderName)))
> .build(false);
> // Initialize the configuration.
> try (final LoggerContext loggerContext =
> Configurator.initialize(config)) {
> final Logger logger =
> loggerContext.getLogger(ParallelRunTest.class);
> // Write logs.
> final String message = Strings.repeat(String.valueOf(letter),
> 999);
> for (int i = 0; i < 1_000; i++) {
> logger.info(message);
> }
> }
> // Verify the file content.
> final long appenderFileLength = new File(appenderFilepath).length();
> assertThat(appenderFileLength).isEqualTo(1_000_000L);
> }
> }
> {code}
> Above test, given a {{letter}}, creates a {{ParallelRunTest-.log}}
> file, and writes 999 times that letter to each line (ending with a line-feed
> character) for 1,000 lines. The eventual file is expected to be of size
> {{lineLength * lineCount = 1,000 * 1,000 = 1e6}}. These assumptions indeed
> hold after a run:
> {code}
> wc -l /tmp/ParallelRunTest-*
>1000 /tmp/ParallelRunTest-A.log
>1000 /tmp/ParallelRunTest-B.log
>1000 /tmp/ParallelRunTest-C.log
>1000 /tmp/ParallelRunTest-D.log
>4000 total
> for log_file in /tmp/ParallelRunTest-*; do
> echo "file: $log_file"
> echo "line lengths:"
> awk "{print length}" $log_file | sort | uniq
> echo "distinct lines:"
> sort $log_file | uniq
> echo
> done
> file: /tmp/ParallelRunTest-A.log
> line lengths:
> 999
> distinct lines:
> AAA...A
> file: /tmp/ParallelRunTest-B.log
> line lengths:
> 999
> distinct lines:
> BBB...B
> file: /tmp/ParallelRunTest-C.log
> line lengths:
> 999
> distinct lines:
> CCC...C
> file: /tmp/ParallelRunTest-D.log
> line lengths:
> 999
> distinct lines:
> DDD...D
> {code}
> Though when {{ExecutionMode.SAME_THREAD}} is replaced with
> {{ExecutionMode.CONCURRENT}} tests fail due to unexpected
> {{appenderFileLength}}:
> {code}
> wc -l /tmp/ParallelRunTest-*
> 96 /tmp/ParallelRunTest-A.log
> 1 /tmp/ParallelRunTest-B.log
> 96 /tmp/ParallelRunTest-C.log
>3577 /tm
[jira] [Commented] (LOG4J2-708) Servlet filter claims to support async but doesn't use AsyncContext
[ https://issues.apache.org/jira/browse/LOG4J2-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608527#comment-17608527 ] ASF subversion and git services commented on LOG4J2-708: Commit 432a851f0381a7bf9417a79ea9f9c64748b3020e in logging-log4j2's branch refs/heads/dependabot/maven/de.flapdoodle.embed-de.flapdoodle.embed.mongo-3.4.9 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=432a851f03 ] [LOG4J2-708] Improve `Log4jServletFilter` async behavior The `Log4jServletFilter` filter should run on all the threads a request is run. The current version ignores all async dispatches. > Servlet filter claims to support async but doesn't use AsyncContext > --- > > Key: LOG4J2-708 > URL: https://issues.apache.org/jira/browse/LOG4J2-708 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.0-rc2 > Environment: Servlet 3.0 (Tomcat 7, Jetty 8) or higher >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Minor > Fix For: 2.19.1 > > > In log4j-web, when the ServletContainerInitializer adds the Log4j Filter, it > sets the asyncSupported property to true. However, it's still a synchronous > Filter. > A separate asynchronous Filter should be made for Servlet 3.x support that > doesn't break Servlet 2.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3564) NPE in JULLogger.getLevel()
[
https://issues.apache.org/jira/browse/LOG4J2-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608528#comment-17608528
]
ASF subversion and git services commented on LOG4J2-3564:
-
Commit c07927c112e2fa622a4087d5283841dc77c82fbe in logging-log4j2's branch
refs/heads/dependabot/maven/de.flapdoodle.embed-de.flapdoodle.embed.mongo-3.4.9
from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c07927c112 ]
[LOG4J2-3564] Missing changelog
> NPE in JULLogger.getLevel()
> ---
>
> Key: LOG4J2-3564
> URL: https://issues.apache.org/jira/browse/LOG4J2-3564
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-JUL
>Affects Versions: 2.17.2
>Reporter: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> {{JULLogger.getLevel()}} fails with a {{NullPointerException}} if the JUL
> root logger has a {{null}} level. This is a common situation in JDK 8+, since
> {{LogManager$RootLogger}} does not set the log level any more in its
> constructor.
> A practical example where it fails is Tomcat's {{ClassLoaderLogManager}}: cf.
> [BZ 66184|https://bz.apache.org/bugzilla/show_bug.cgi?id=66184].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3188) Concurrent individual LoggerContext initializations cause severe LogEvent drop or incorrect delivery
[
https://issues.apache.org/jira/browse/LOG4J2-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608526#comment-17608526
]
ASF subversion and git services commented on LOG4J2-3188:
-
Commit 5bc48cc9b49b291cb1f41b84fcd1ff2965fa7cf2 in logging-log4j2's branch
refs/heads/dependabot/maven/net.java.dev.jna-jna-5.12.1 from Volkan Yazıcı
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5bc48cc9b4 ]
LOG4J2-3188 Create a fresh LoggerContext in
JsonTemplateLayoutConcurrentEncodeTest.
> Concurrent individual LoggerContext initializations cause severe LogEvent
> drop or incorrect delivery
>
>
> Key: LOG4J2-3188
> URL: https://issues.apache.org/jira/browse/LOG4J2-3188
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> When multiple {{LoggerContext}}'s get initialized concurrently, they affect
> each other causing severe {{LogEvent}} drop and incorrect delivery. Consider
> the following test:
> {code:java}
> @Execution(ExecutionMode.SAME_THREAD)
> class ParallelRunTest {
> @ParameterizedTest
> @ValueSource(chars = {'A', 'B', 'C', 'D'})
> void test(final char letter) {
> // Create the configuration builder.
> final ConfigurationBuilder configBuilder =
> ConfigurationBuilderFactory
> .newConfigurationBuilder()
> .setStatusLevel(Level.ERROR)
> .setConfigurationName("Letter-" + letter);
> // Create the configuration.
> final String appenderName = "File";
> final String appenderFilepath = Paths
> .get(
> System.getProperty("java.io.tmpdir"),
> "ParallelRunTest-" + letter + ".log")
> .toAbsolutePath()
> .toString();
> final Configuration config = configBuilder
> .add(configBuilder
> .newAppender(appenderName, "File")
> .addAttribute("fileName", appenderFilepath)
> .addAttribute("append", false)
> .addAttribute("immediateFlush", false)
> .addAttribute("ignoreExceptions", false)
> .add(configBuilder
> .newLayout("PatternLayout")
> .addAttribute("pattern", "%m\n")))
> .add(configBuilder
> .newRootLogger(Level.ALL)
> .add(configBuilder.newAppenderRef(appenderName)))
> .build(false);
> // Initialize the configuration.
> try (final LoggerContext loggerContext =
> Configurator.initialize(config)) {
> final Logger logger =
> loggerContext.getLogger(ParallelRunTest.class);
> // Write logs.
> final String message = Strings.repeat(String.valueOf(letter),
> 999);
> for (int i = 0; i < 1_000; i++) {
> logger.info(message);
> }
> }
> // Verify the file content.
> final long appenderFileLength = new File(appenderFilepath).length();
> assertThat(appenderFileLength).isEqualTo(1_000_000L);
> }
> }
> {code}
> Above test, given a {{letter}}, creates a {{ParallelRunTest-.log}}
> file, and writes 999 times that letter to each line (ending with a line-feed
> character) for 1,000 lines. The eventual file is expected to be of size
> {{lineLength * lineCount = 1,000 * 1,000 = 1e6}}. These assumptions indeed
> hold after a run:
> {code}
> wc -l /tmp/ParallelRunTest-*
>1000 /tmp/ParallelRunTest-A.log
>1000 /tmp/ParallelRunTest-B.log
>1000 /tmp/ParallelRunTest-C.log
>1000 /tmp/ParallelRunTest-D.log
>4000 total
> for log_file in /tmp/ParallelRunTest-*; do
> echo "file: $log_file"
> echo "line lengths:"
> awk "{print length}" $log_file | sort | uniq
> echo "distinct lines:"
> sort $log_file | uniq
> echo
> done
> file: /tmp/ParallelRunTest-A.log
> line lengths:
> 999
> distinct lines:
> AAA...A
> file: /tmp/ParallelRunTest-B.log
> line lengths:
> 999
> distinct lines:
> BBB...B
> file: /tmp/ParallelRunTest-C.log
> line lengths:
> 999
> distinct lines:
> CCC...C
> file: /tmp/ParallelRunTest-D.log
> line lengths:
> 999
> distinct lines:
> DDD...D
> {code}
> Though when {{ExecutionMode.SAME_THREAD}} is replaced with
> {{ExecutionMode.CONCURRENT}} tests fail due to unexpected
> {{appenderFileLength}}:
> {code}
> wc -l /tmp/ParallelRunTest-*
> 96 /tmp/ParallelRunTest-A.log
> 1 /tmp/ParallelRunTest-B.log
> 96 /tmp/ParallelRunTest-C.log
>3577 /tmp/ParallelRunTest-D.log
[jira] [Commented] (LOG4J2-3564) NPE in JULLogger.getLevel()
[
https://issues.apache.org/jira/browse/LOG4J2-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608518#comment-17608518
]
ASF subversion and git services commented on LOG4J2-3564:
-
Commit c07927c112e2fa622a4087d5283841dc77c82fbe in logging-log4j2's branch
refs/heads/dependabot/maven/surefire.plugin.version-3.0.0-M7 from Piotr P.
Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c07927c112 ]
[LOG4J2-3564] Missing changelog
> NPE in JULLogger.getLevel()
> ---
>
> Key: LOG4J2-3564
> URL: https://issues.apache.org/jira/browse/LOG4J2-3564
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-JUL
>Affects Versions: 2.17.2
>Reporter: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> {{JULLogger.getLevel()}} fails with a {{NullPointerException}} if the JUL
> root logger has a {{null}} level. This is a common situation in JDK 8+, since
> {{LogManager$RootLogger}} does not set the log level any more in its
> constructor.
> A practical example where it fails is Tomcat's {{ClassLoaderLogManager}}: cf.
> [BZ 66184|https://bz.apache.org/bugzilla/show_bug.cgi?id=66184].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3188) Concurrent individual LoggerContext initializations cause severe LogEvent drop or incorrect delivery
[
https://issues.apache.org/jira/browse/LOG4J2-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608523#comment-17608523
]
ASF subversion and git services commented on LOG4J2-3188:
-
Commit 5bc48cc9b49b291cb1f41b84fcd1ff2965fa7cf2 in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven.plugins-maven-site-plugin-3.12.1
from Volkan Yazıcı
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5bc48cc9b4 ]
LOG4J2-3188 Create a fresh LoggerContext in
JsonTemplateLayoutConcurrentEncodeTest.
> Concurrent individual LoggerContext initializations cause severe LogEvent
> drop or incorrect delivery
>
>
> Key: LOG4J2-3188
> URL: https://issues.apache.org/jira/browse/LOG4J2-3188
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> When multiple {{LoggerContext}}'s get initialized concurrently, they affect
> each other causing severe {{LogEvent}} drop and incorrect delivery. Consider
> the following test:
> {code:java}
> @Execution(ExecutionMode.SAME_THREAD)
> class ParallelRunTest {
> @ParameterizedTest
> @ValueSource(chars = {'A', 'B', 'C', 'D'})
> void test(final char letter) {
> // Create the configuration builder.
> final ConfigurationBuilder configBuilder =
> ConfigurationBuilderFactory
> .newConfigurationBuilder()
> .setStatusLevel(Level.ERROR)
> .setConfigurationName("Letter-" + letter);
> // Create the configuration.
> final String appenderName = "File";
> final String appenderFilepath = Paths
> .get(
> System.getProperty("java.io.tmpdir"),
> "ParallelRunTest-" + letter + ".log")
> .toAbsolutePath()
> .toString();
> final Configuration config = configBuilder
> .add(configBuilder
> .newAppender(appenderName, "File")
> .addAttribute("fileName", appenderFilepath)
> .addAttribute("append", false)
> .addAttribute("immediateFlush", false)
> .addAttribute("ignoreExceptions", false)
> .add(configBuilder
> .newLayout("PatternLayout")
> .addAttribute("pattern", "%m\n")))
> .add(configBuilder
> .newRootLogger(Level.ALL)
> .add(configBuilder.newAppenderRef(appenderName)))
> .build(false);
> // Initialize the configuration.
> try (final LoggerContext loggerContext =
> Configurator.initialize(config)) {
> final Logger logger =
> loggerContext.getLogger(ParallelRunTest.class);
> // Write logs.
> final String message = Strings.repeat(String.valueOf(letter),
> 999);
> for (int i = 0; i < 1_000; i++) {
> logger.info(message);
> }
> }
> // Verify the file content.
> final long appenderFileLength = new File(appenderFilepath).length();
> assertThat(appenderFileLength).isEqualTo(1_000_000L);
> }
> }
> {code}
> Above test, given a {{letter}}, creates a {{ParallelRunTest-.log}}
> file, and writes 999 times that letter to each line (ending with a line-feed
> character) for 1,000 lines. The eventual file is expected to be of size
> {{lineLength * lineCount = 1,000 * 1,000 = 1e6}}. These assumptions indeed
> hold after a run:
> {code}
> wc -l /tmp/ParallelRunTest-*
>1000 /tmp/ParallelRunTest-A.log
>1000 /tmp/ParallelRunTest-B.log
>1000 /tmp/ParallelRunTest-C.log
>1000 /tmp/ParallelRunTest-D.log
>4000 total
> for log_file in /tmp/ParallelRunTest-*; do
> echo "file: $log_file"
> echo "line lengths:"
> awk "{print length}" $log_file | sort | uniq
> echo "distinct lines:"
> sort $log_file | uniq
> echo
> done
> file: /tmp/ParallelRunTest-A.log
> line lengths:
> 999
> distinct lines:
> AAA...A
> file: /tmp/ParallelRunTest-B.log
> line lengths:
> 999
> distinct lines:
> BBB...B
> file: /tmp/ParallelRunTest-C.log
> line lengths:
> 999
> distinct lines:
> CCC...C
> file: /tmp/ParallelRunTest-D.log
> line lengths:
> 999
> distinct lines:
> DDD...D
> {code}
> Though when {{ExecutionMode.SAME_THREAD}} is replaced with
> {{ExecutionMode.CONCURRENT}} tests fail due to unexpected
> {{appenderFileLength}}:
> {code}
> wc -l /tmp/ParallelRunTest-*
> 96 /tmp/ParallelRunTest-A.log
> 1 /tmp/ParallelRunTest-B.log
> 96 /tmp/ParallelRunTest-C.log
>3577 /tm
[jira] [Commented] (LOG4J2-708) Servlet filter claims to support async but doesn't use AsyncContext
[ https://issues.apache.org/jira/browse/LOG4J2-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608524#comment-17608524 ] ASF subversion and git services commented on LOG4J2-708: Commit 432a851f0381a7bf9417a79ea9f9c64748b3020e in logging-log4j2's branch refs/heads/dependabot/maven/net.java.dev.jna-jna-5.12.1 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=432a851f03 ] [LOG4J2-708] Improve `Log4jServletFilter` async behavior The `Log4jServletFilter` filter should run on all the threads a request is run. The current version ignores all async dispatches. > Servlet filter claims to support async but doesn't use AsyncContext > --- > > Key: LOG4J2-708 > URL: https://issues.apache.org/jira/browse/LOG4J2-708 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.0-rc2 > Environment: Servlet 3.0 (Tomcat 7, Jetty 8) or higher >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Minor > Fix For: 2.19.1 > > > In log4j-web, when the ServletContainerInitializer adds the Log4j Filter, it > sets the asyncSupported property to true. However, it's still a synchronous > Filter. > A separate asynchronous Filter should be made for Servlet 3.x support that > doesn't break Servlet 2.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3564) NPE in JULLogger.getLevel()
[
https://issues.apache.org/jira/browse/LOG4J2-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608515#comment-17608515
]
ASF subversion and git services commented on LOG4J2-3564:
-
Commit c07927c112e2fa622a4087d5283841dc77c82fbe in logging-log4j2's branch
refs/heads/dependabot/maven/org.liquibase-liquibase-core-3.10.3 from Piotr P.
Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c07927c112 ]
[LOG4J2-3564] Missing changelog
> NPE in JULLogger.getLevel()
> ---
>
> Key: LOG4J2-3564
> URL: https://issues.apache.org/jira/browse/LOG4J2-3564
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-JUL
>Affects Versions: 2.17.2
>Reporter: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> {{JULLogger.getLevel()}} fails with a {{NullPointerException}} if the JUL
> root logger has a {{null}} level. This is a common situation in JDK 8+, since
> {{LogManager$RootLogger}} does not set the log level any more in its
> constructor.
> A practical example where it fails is Tomcat's {{ClassLoaderLogManager}}: cf.
> [BZ 66184|https://bz.apache.org/bugzilla/show_bug.cgi?id=66184].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3564) NPE in JULLogger.getLevel()
[
https://issues.apache.org/jira/browse/LOG4J2-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608512#comment-17608512
]
ASF subversion and git services commented on LOG4J2-3564:
-
Commit c07927c112e2fa622a4087d5283841dc77c82fbe in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven.plugins-maven-assembly-plugin-3.4.2
from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c07927c112 ]
[LOG4J2-3564] Missing changelog
> NPE in JULLogger.getLevel()
> ---
>
> Key: LOG4J2-3564
> URL: https://issues.apache.org/jira/browse/LOG4J2-3564
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-JUL
>Affects Versions: 2.17.2
>Reporter: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> {{JULLogger.getLevel()}} fails with a {{NullPointerException}} if the JUL
> root logger has a {{null}} level. This is a common situation in JDK 8+, since
> {{LogManager$RootLogger}} does not set the log level any more in its
> constructor.
> A practical example where it fails is Tomcat's {{ClassLoaderLogManager}}: cf.
> [BZ 66184|https://bz.apache.org/bugzilla/show_bug.cgi?id=66184].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3564) NPE in JULLogger.getLevel()
[
https://issues.apache.org/jira/browse/LOG4J2-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608522#comment-17608522
]
ASF subversion and git services commented on LOG4J2-3564:
-
Commit c07927c112e2fa622a4087d5283841dc77c82fbe in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven.plugins-maven-site-plugin-3.12.1
from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c07927c112 ]
[LOG4J2-3564] Missing changelog
> NPE in JULLogger.getLevel()
> ---
>
> Key: LOG4J2-3564
> URL: https://issues.apache.org/jira/browse/LOG4J2-3564
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-JUL
>Affects Versions: 2.17.2
>Reporter: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> {{JULLogger.getLevel()}} fails with a {{NullPointerException}} if the JUL
> root logger has a {{null}} level. This is a common situation in JDK 8+, since
> {{LogManager$RootLogger}} does not set the log level any more in its
> constructor.
> A practical example where it fails is Tomcat's {{ClassLoaderLogManager}}: cf.
> [BZ 66184|https://bz.apache.org/bugzilla/show_bug.cgi?id=66184].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3188) Concurrent individual LoggerContext initializations cause severe LogEvent drop or incorrect delivery
[
https://issues.apache.org/jira/browse/LOG4J2-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608516#comment-17608516
]
ASF subversion and git services commented on LOG4J2-3188:
-
Commit 5bc48cc9b49b291cb1f41b84fcd1ff2965fa7cf2 in logging-log4j2's branch
refs/heads/dependabot/maven/org.liquibase-liquibase-core-3.10.3 from Volkan
Yazıcı
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5bc48cc9b4 ]
LOG4J2-3188 Create a fresh LoggerContext in
JsonTemplateLayoutConcurrentEncodeTest.
> Concurrent individual LoggerContext initializations cause severe LogEvent
> drop or incorrect delivery
>
>
> Key: LOG4J2-3188
> URL: https://issues.apache.org/jira/browse/LOG4J2-3188
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> When multiple {{LoggerContext}}'s get initialized concurrently, they affect
> each other causing severe {{LogEvent}} drop and incorrect delivery. Consider
> the following test:
> {code:java}
> @Execution(ExecutionMode.SAME_THREAD)
> class ParallelRunTest {
> @ParameterizedTest
> @ValueSource(chars = {'A', 'B', 'C', 'D'})
> void test(final char letter) {
> // Create the configuration builder.
> final ConfigurationBuilder configBuilder =
> ConfigurationBuilderFactory
> .newConfigurationBuilder()
> .setStatusLevel(Level.ERROR)
> .setConfigurationName("Letter-" + letter);
> // Create the configuration.
> final String appenderName = "File";
> final String appenderFilepath = Paths
> .get(
> System.getProperty("java.io.tmpdir"),
> "ParallelRunTest-" + letter + ".log")
> .toAbsolutePath()
> .toString();
> final Configuration config = configBuilder
> .add(configBuilder
> .newAppender(appenderName, "File")
> .addAttribute("fileName", appenderFilepath)
> .addAttribute("append", false)
> .addAttribute("immediateFlush", false)
> .addAttribute("ignoreExceptions", false)
> .add(configBuilder
> .newLayout("PatternLayout")
> .addAttribute("pattern", "%m\n")))
> .add(configBuilder
> .newRootLogger(Level.ALL)
> .add(configBuilder.newAppenderRef(appenderName)))
> .build(false);
> // Initialize the configuration.
> try (final LoggerContext loggerContext =
> Configurator.initialize(config)) {
> final Logger logger =
> loggerContext.getLogger(ParallelRunTest.class);
> // Write logs.
> final String message = Strings.repeat(String.valueOf(letter),
> 999);
> for (int i = 0; i < 1_000; i++) {
> logger.info(message);
> }
> }
> // Verify the file content.
> final long appenderFileLength = new File(appenderFilepath).length();
> assertThat(appenderFileLength).isEqualTo(1_000_000L);
> }
> }
> {code}
> Above test, given a {{letter}}, creates a {{ParallelRunTest-.log}}
> file, and writes 999 times that letter to each line (ending with a line-feed
> character) for 1,000 lines. The eventual file is expected to be of size
> {{lineLength * lineCount = 1,000 * 1,000 = 1e6}}. These assumptions indeed
> hold after a run:
> {code}
> wc -l /tmp/ParallelRunTest-*
>1000 /tmp/ParallelRunTest-A.log
>1000 /tmp/ParallelRunTest-B.log
>1000 /tmp/ParallelRunTest-C.log
>1000 /tmp/ParallelRunTest-D.log
>4000 total
> for log_file in /tmp/ParallelRunTest-*; do
> echo "file: $log_file"
> echo "line lengths:"
> awk "{print length}" $log_file | sort | uniq
> echo "distinct lines:"
> sort $log_file | uniq
> echo
> done
> file: /tmp/ParallelRunTest-A.log
> line lengths:
> 999
> distinct lines:
> AAA...A
> file: /tmp/ParallelRunTest-B.log
> line lengths:
> 999
> distinct lines:
> BBB...B
> file: /tmp/ParallelRunTest-C.log
> line lengths:
> 999
> distinct lines:
> CCC...C
> file: /tmp/ParallelRunTest-D.log
> line lengths:
> 999
> distinct lines:
> DDD...D
> {code}
> Though when {{ExecutionMode.SAME_THREAD}} is replaced with
> {{ExecutionMode.CONCURRENT}} tests fail due to unexpected
> {{appenderFileLength}}:
> {code}
> wc -l /tmp/ParallelRunTest-*
> 96 /tmp/ParallelRunTest-A.log
> 1 /tmp/ParallelRunTest-B.log
> 96 /tmp/ParallelRunTest-C.log
>3577 /tmp/ParallelRunT
[jira] [Commented] (LOG4J2-708) Servlet filter claims to support async but doesn't use AsyncContext
[ https://issues.apache.org/jira/browse/LOG4J2-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608517#comment-17608517 ] ASF subversion and git services commented on LOG4J2-708: Commit 432a851f0381a7bf9417a79ea9f9c64748b3020e in logging-log4j2's branch refs/heads/dependabot/maven/surefire.plugin.version-3.0.0-M7 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=432a851f03 ] [LOG4J2-708] Improve `Log4jServletFilter` async behavior The `Log4jServletFilter` filter should run on all the threads a request is run. The current version ignores all async dispatches. > Servlet filter claims to support async but doesn't use AsyncContext > --- > > Key: LOG4J2-708 > URL: https://issues.apache.org/jira/browse/LOG4J2-708 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.0-rc2 > Environment: Servlet 3.0 (Tomcat 7, Jetty 8) or higher >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Minor > Fix For: 2.19.1 > > > In log4j-web, when the ServletContainerInitializer adds the Log4j Filter, it > sets the asyncSupported property to true. However, it's still a synchronous > Filter. > A separate asynchronous Filter should be made for Servlet 3.x support that > doesn't break Servlet 2.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3188) Concurrent individual LoggerContext initializations cause severe LogEvent drop or incorrect delivery
[
https://issues.apache.org/jira/browse/LOG4J2-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608519#comment-17608519
]
ASF subversion and git services commented on LOG4J2-3188:
-
Commit 5bc48cc9b49b291cb1f41b84fcd1ff2965fa7cf2 in logging-log4j2's branch
refs/heads/dependabot/maven/surefire.plugin.version-3.0.0-M7 from Volkan Yazıcı
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5bc48cc9b4 ]
LOG4J2-3188 Create a fresh LoggerContext in
JsonTemplateLayoutConcurrentEncodeTest.
> Concurrent individual LoggerContext initializations cause severe LogEvent
> drop or incorrect delivery
>
>
> Key: LOG4J2-3188
> URL: https://issues.apache.org/jira/browse/LOG4J2-3188
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> When multiple {{LoggerContext}}'s get initialized concurrently, they affect
> each other causing severe {{LogEvent}} drop and incorrect delivery. Consider
> the following test:
> {code:java}
> @Execution(ExecutionMode.SAME_THREAD)
> class ParallelRunTest {
> @ParameterizedTest
> @ValueSource(chars = {'A', 'B', 'C', 'D'})
> void test(final char letter) {
> // Create the configuration builder.
> final ConfigurationBuilder configBuilder =
> ConfigurationBuilderFactory
> .newConfigurationBuilder()
> .setStatusLevel(Level.ERROR)
> .setConfigurationName("Letter-" + letter);
> // Create the configuration.
> final String appenderName = "File";
> final String appenderFilepath = Paths
> .get(
> System.getProperty("java.io.tmpdir"),
> "ParallelRunTest-" + letter + ".log")
> .toAbsolutePath()
> .toString();
> final Configuration config = configBuilder
> .add(configBuilder
> .newAppender(appenderName, "File")
> .addAttribute("fileName", appenderFilepath)
> .addAttribute("append", false)
> .addAttribute("immediateFlush", false)
> .addAttribute("ignoreExceptions", false)
> .add(configBuilder
> .newLayout("PatternLayout")
> .addAttribute("pattern", "%m\n")))
> .add(configBuilder
> .newRootLogger(Level.ALL)
> .add(configBuilder.newAppenderRef(appenderName)))
> .build(false);
> // Initialize the configuration.
> try (final LoggerContext loggerContext =
> Configurator.initialize(config)) {
> final Logger logger =
> loggerContext.getLogger(ParallelRunTest.class);
> // Write logs.
> final String message = Strings.repeat(String.valueOf(letter),
> 999);
> for (int i = 0; i < 1_000; i++) {
> logger.info(message);
> }
> }
> // Verify the file content.
> final long appenderFileLength = new File(appenderFilepath).length();
> assertThat(appenderFileLength).isEqualTo(1_000_000L);
> }
> }
> {code}
> Above test, given a {{letter}}, creates a {{ParallelRunTest-.log}}
> file, and writes 999 times that letter to each line (ending with a line-feed
> character) for 1,000 lines. The eventual file is expected to be of size
> {{lineLength * lineCount = 1,000 * 1,000 = 1e6}}. These assumptions indeed
> hold after a run:
> {code}
> wc -l /tmp/ParallelRunTest-*
>1000 /tmp/ParallelRunTest-A.log
>1000 /tmp/ParallelRunTest-B.log
>1000 /tmp/ParallelRunTest-C.log
>1000 /tmp/ParallelRunTest-D.log
>4000 total
> for log_file in /tmp/ParallelRunTest-*; do
> echo "file: $log_file"
> echo "line lengths:"
> awk "{print length}" $log_file | sort | uniq
> echo "distinct lines:"
> sort $log_file | uniq
> echo
> done
> file: /tmp/ParallelRunTest-A.log
> line lengths:
> 999
> distinct lines:
> AAA...A
> file: /tmp/ParallelRunTest-B.log
> line lengths:
> 999
> distinct lines:
> BBB...B
> file: /tmp/ParallelRunTest-C.log
> line lengths:
> 999
> distinct lines:
> CCC...C
> file: /tmp/ParallelRunTest-D.log
> line lengths:
> 999
> distinct lines:
> DDD...D
> {code}
> Though when {{ExecutionMode.SAME_THREAD}} is replaced with
> {{ExecutionMode.CONCURRENT}} tests fail due to unexpected
> {{appenderFileLength}}:
> {code}
> wc -l /tmp/ParallelRunTest-*
> 96 /tmp/ParallelRunTest-A.log
> 1 /tmp/ParallelRunTest-B.log
> 96 /tmp/ParallelRunTest-C.log
>3577 /tmp/ParallelRunTest-
[jira] [Commented] (LOG4J2-3188) Concurrent individual LoggerContext initializations cause severe LogEvent drop or incorrect delivery
[
https://issues.apache.org/jira/browse/LOG4J2-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608513#comment-17608513
]
ASF subversion and git services commented on LOG4J2-3188:
-
Commit 5bc48cc9b49b291cb1f41b84fcd1ff2965fa7cf2 in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven.plugins-maven-assembly-plugin-3.4.2
from Volkan Yazıcı
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5bc48cc9b4 ]
LOG4J2-3188 Create a fresh LoggerContext in
JsonTemplateLayoutConcurrentEncodeTest.
> Concurrent individual LoggerContext initializations cause severe LogEvent
> drop or incorrect delivery
>
>
> Key: LOG4J2-3188
> URL: https://issues.apache.org/jira/browse/LOG4J2-3188
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> When multiple {{LoggerContext}}'s get initialized concurrently, they affect
> each other causing severe {{LogEvent}} drop and incorrect delivery. Consider
> the following test:
> {code:java}
> @Execution(ExecutionMode.SAME_THREAD)
> class ParallelRunTest {
> @ParameterizedTest
> @ValueSource(chars = {'A', 'B', 'C', 'D'})
> void test(final char letter) {
> // Create the configuration builder.
> final ConfigurationBuilder configBuilder =
> ConfigurationBuilderFactory
> .newConfigurationBuilder()
> .setStatusLevel(Level.ERROR)
> .setConfigurationName("Letter-" + letter);
> // Create the configuration.
> final String appenderName = "File";
> final String appenderFilepath = Paths
> .get(
> System.getProperty("java.io.tmpdir"),
> "ParallelRunTest-" + letter + ".log")
> .toAbsolutePath()
> .toString();
> final Configuration config = configBuilder
> .add(configBuilder
> .newAppender(appenderName, "File")
> .addAttribute("fileName", appenderFilepath)
> .addAttribute("append", false)
> .addAttribute("immediateFlush", false)
> .addAttribute("ignoreExceptions", false)
> .add(configBuilder
> .newLayout("PatternLayout")
> .addAttribute("pattern", "%m\n")))
> .add(configBuilder
> .newRootLogger(Level.ALL)
> .add(configBuilder.newAppenderRef(appenderName)))
> .build(false);
> // Initialize the configuration.
> try (final LoggerContext loggerContext =
> Configurator.initialize(config)) {
> final Logger logger =
> loggerContext.getLogger(ParallelRunTest.class);
> // Write logs.
> final String message = Strings.repeat(String.valueOf(letter),
> 999);
> for (int i = 0; i < 1_000; i++) {
> logger.info(message);
> }
> }
> // Verify the file content.
> final long appenderFileLength = new File(appenderFilepath).length();
> assertThat(appenderFileLength).isEqualTo(1_000_000L);
> }
> }
> {code}
> Above test, given a {{letter}}, creates a {{ParallelRunTest-.log}}
> file, and writes 999 times that letter to each line (ending with a line-feed
> character) for 1,000 lines. The eventual file is expected to be of size
> {{lineLength * lineCount = 1,000 * 1,000 = 1e6}}. These assumptions indeed
> hold after a run:
> {code}
> wc -l /tmp/ParallelRunTest-*
>1000 /tmp/ParallelRunTest-A.log
>1000 /tmp/ParallelRunTest-B.log
>1000 /tmp/ParallelRunTest-C.log
>1000 /tmp/ParallelRunTest-D.log
>4000 total
> for log_file in /tmp/ParallelRunTest-*; do
> echo "file: $log_file"
> echo "line lengths:"
> awk "{print length}" $log_file | sort | uniq
> echo "distinct lines:"
> sort $log_file | uniq
> echo
> done
> file: /tmp/ParallelRunTest-A.log
> line lengths:
> 999
> distinct lines:
> AAA...A
> file: /tmp/ParallelRunTest-B.log
> line lengths:
> 999
> distinct lines:
> BBB...B
> file: /tmp/ParallelRunTest-C.log
> line lengths:
> 999
> distinct lines:
> CCC...C
> file: /tmp/ParallelRunTest-D.log
> line lengths:
> 999
> distinct lines:
> DDD...D
> {code}
> Though when {{ExecutionMode.SAME_THREAD}} is replaced with
> {{ExecutionMode.CONCURRENT}} tests fail due to unexpected
> {{appenderFileLength}}:
> {code}
> wc -l /tmp/ParallelRunTest-*
> 96 /tmp/ParallelRunTest-A.log
> 1 /tmp/ParallelRunTest-B.log
> 96 /tmp/ParallelRunTest-C.log
>3577
[jira] [Commented] (LOG4J2-3188) Concurrent individual LoggerContext initializations cause severe LogEvent drop or incorrect delivery
[
https://issues.apache.org/jira/browse/LOG4J2-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608510#comment-17608510
]
ASF subversion and git services commented on LOG4J2-3188:
-
Commit 5bc48cc9b49b291cb1f41b84fcd1ff2965fa7cf2 in logging-log4j2's branch
refs/heads/dependabot/maven/org.eclipse.persistence-org.eclipse.persistence.jpa-2.7.11
from Volkan Yazıcı
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5bc48cc9b4 ]
LOG4J2-3188 Create a fresh LoggerContext in
JsonTemplateLayoutConcurrentEncodeTest.
> Concurrent individual LoggerContext initializations cause severe LogEvent
> drop or incorrect delivery
>
>
> Key: LOG4J2-3188
> URL: https://issues.apache.org/jira/browse/LOG4J2-3188
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> When multiple {{LoggerContext}}'s get initialized concurrently, they affect
> each other causing severe {{LogEvent}} drop and incorrect delivery. Consider
> the following test:
> {code:java}
> @Execution(ExecutionMode.SAME_THREAD)
> class ParallelRunTest {
> @ParameterizedTest
> @ValueSource(chars = {'A', 'B', 'C', 'D'})
> void test(final char letter) {
> // Create the configuration builder.
> final ConfigurationBuilder configBuilder =
> ConfigurationBuilderFactory
> .newConfigurationBuilder()
> .setStatusLevel(Level.ERROR)
> .setConfigurationName("Letter-" + letter);
> // Create the configuration.
> final String appenderName = "File";
> final String appenderFilepath = Paths
> .get(
> System.getProperty("java.io.tmpdir"),
> "ParallelRunTest-" + letter + ".log")
> .toAbsolutePath()
> .toString();
> final Configuration config = configBuilder
> .add(configBuilder
> .newAppender(appenderName, "File")
> .addAttribute("fileName", appenderFilepath)
> .addAttribute("append", false)
> .addAttribute("immediateFlush", false)
> .addAttribute("ignoreExceptions", false)
> .add(configBuilder
> .newLayout("PatternLayout")
> .addAttribute("pattern", "%m\n")))
> .add(configBuilder
> .newRootLogger(Level.ALL)
> .add(configBuilder.newAppenderRef(appenderName)))
> .build(false);
> // Initialize the configuration.
> try (final LoggerContext loggerContext =
> Configurator.initialize(config)) {
> final Logger logger =
> loggerContext.getLogger(ParallelRunTest.class);
> // Write logs.
> final String message = Strings.repeat(String.valueOf(letter),
> 999);
> for (int i = 0; i < 1_000; i++) {
> logger.info(message);
> }
> }
> // Verify the file content.
> final long appenderFileLength = new File(appenderFilepath).length();
> assertThat(appenderFileLength).isEqualTo(1_000_000L);
> }
> }
> {code}
> Above test, given a {{letter}}, creates a {{ParallelRunTest-.log}}
> file, and writes 999 times that letter to each line (ending with a line-feed
> character) for 1,000 lines. The eventual file is expected to be of size
> {{lineLength * lineCount = 1,000 * 1,000 = 1e6}}. These assumptions indeed
> hold after a run:
> {code}
> wc -l /tmp/ParallelRunTest-*
>1000 /tmp/ParallelRunTest-A.log
>1000 /tmp/ParallelRunTest-B.log
>1000 /tmp/ParallelRunTest-C.log
>1000 /tmp/ParallelRunTest-D.log
>4000 total
> for log_file in /tmp/ParallelRunTest-*; do
> echo "file: $log_file"
> echo "line lengths:"
> awk "{print length}" $log_file | sort | uniq
> echo "distinct lines:"
> sort $log_file | uniq
> echo
> done
> file: /tmp/ParallelRunTest-A.log
> line lengths:
> 999
> distinct lines:
> AAA...A
> file: /tmp/ParallelRunTest-B.log
> line lengths:
> 999
> distinct lines:
> BBB...B
> file: /tmp/ParallelRunTest-C.log
> line lengths:
> 999
> distinct lines:
> CCC...C
> file: /tmp/ParallelRunTest-D.log
> line lengths:
> 999
> distinct lines:
> DDD...D
> {code}
> Though when {{ExecutionMode.SAME_THREAD}} is replaced with
> {{ExecutionMode.CONCURRENT}} tests fail due to unexpected
> {{appenderFileLength}}:
> {code}
> wc -l /tmp/ParallelRunTest-*
> 96 /tmp/ParallelRunTest-A.log
> 1 /tmp/ParallelRunTest-B.log
> 96 /tmp/ParallelRunTest-C.log
>
[jira] [Commented] (LOG4J2-708) Servlet filter claims to support async but doesn't use AsyncContext
[ https://issues.apache.org/jira/browse/LOG4J2-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608508#comment-17608508 ] ASF subversion and git services commented on LOG4J2-708: Commit 432a851f0381a7bf9417a79ea9f9c64748b3020e in logging-log4j2's branch refs/heads/dependabot/maven/org.eclipse.persistence-org.eclipse.persistence.jpa-2.7.11 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=432a851f03 ] [LOG4J2-708] Improve `Log4jServletFilter` async behavior The `Log4jServletFilter` filter should run on all the threads a request is run. The current version ignores all async dispatches. > Servlet filter claims to support async but doesn't use AsyncContext > --- > > Key: LOG4J2-708 > URL: https://issues.apache.org/jira/browse/LOG4J2-708 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.0-rc2 > Environment: Servlet 3.0 (Tomcat 7, Jetty 8) or higher >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Minor > Fix For: 2.19.1 > > > In log4j-web, when the ServletContainerInitializer adds the Log4j Filter, it > sets the asyncSupported property to true. However, it's still a synchronous > Filter. > A separate asynchronous Filter should be made for Servlet 3.x support that > doesn't break Servlet 2.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3564) NPE in JULLogger.getLevel()
[
https://issues.apache.org/jira/browse/LOG4J2-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608506#comment-17608506
]
ASF subversion and git services commented on LOG4J2-3564:
-
Commit c07927c112e2fa622a4087d5283841dc77c82fbe in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven.plugins-maven-resources-plugin-3.3.0
from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c07927c112 ]
[LOG4J2-3564] Missing changelog
> NPE in JULLogger.getLevel()
> ---
>
> Key: LOG4J2-3564
> URL: https://issues.apache.org/jira/browse/LOG4J2-3564
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-JUL
>Affects Versions: 2.17.2
>Reporter: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> {{JULLogger.getLevel()}} fails with a {{NullPointerException}} if the JUL
> root logger has a {{null}} level. This is a common situation in JDK 8+, since
> {{LogManager$RootLogger}} does not set the log level any more in its
> constructor.
> A practical example where it fails is Tomcat's {{ClassLoaderLogManager}}: cf.
> [BZ 66184|https://bz.apache.org/bugzilla/show_bug.cgi?id=66184].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3188) Concurrent individual LoggerContext initializations cause severe LogEvent drop or incorrect delivery
[
https://issues.apache.org/jira/browse/LOG4J2-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608520#comment-17608520
]
ASF subversion and git services commented on LOG4J2-3188:
-
Commit 5bc48cc9b49b291cb1f41b84fcd1ff2965fa7cf2 in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven.plugins-maven-jar-plugin-3.3.0
from Volkan Yazıcı
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5bc48cc9b4 ]
LOG4J2-3188 Create a fresh LoggerContext in
JsonTemplateLayoutConcurrentEncodeTest.
> Concurrent individual LoggerContext initializations cause severe LogEvent
> drop or incorrect delivery
>
>
> Key: LOG4J2-3188
> URL: https://issues.apache.org/jira/browse/LOG4J2-3188
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> When multiple {{LoggerContext}}'s get initialized concurrently, they affect
> each other causing severe {{LogEvent}} drop and incorrect delivery. Consider
> the following test:
> {code:java}
> @Execution(ExecutionMode.SAME_THREAD)
> class ParallelRunTest {
> @ParameterizedTest
> @ValueSource(chars = {'A', 'B', 'C', 'D'})
> void test(final char letter) {
> // Create the configuration builder.
> final ConfigurationBuilder configBuilder =
> ConfigurationBuilderFactory
> .newConfigurationBuilder()
> .setStatusLevel(Level.ERROR)
> .setConfigurationName("Letter-" + letter);
> // Create the configuration.
> final String appenderName = "File";
> final String appenderFilepath = Paths
> .get(
> System.getProperty("java.io.tmpdir"),
> "ParallelRunTest-" + letter + ".log")
> .toAbsolutePath()
> .toString();
> final Configuration config = configBuilder
> .add(configBuilder
> .newAppender(appenderName, "File")
> .addAttribute("fileName", appenderFilepath)
> .addAttribute("append", false)
> .addAttribute("immediateFlush", false)
> .addAttribute("ignoreExceptions", false)
> .add(configBuilder
> .newLayout("PatternLayout")
> .addAttribute("pattern", "%m\n")))
> .add(configBuilder
> .newRootLogger(Level.ALL)
> .add(configBuilder.newAppenderRef(appenderName)))
> .build(false);
> // Initialize the configuration.
> try (final LoggerContext loggerContext =
> Configurator.initialize(config)) {
> final Logger logger =
> loggerContext.getLogger(ParallelRunTest.class);
> // Write logs.
> final String message = Strings.repeat(String.valueOf(letter),
> 999);
> for (int i = 0; i < 1_000; i++) {
> logger.info(message);
> }
> }
> // Verify the file content.
> final long appenderFileLength = new File(appenderFilepath).length();
> assertThat(appenderFileLength).isEqualTo(1_000_000L);
> }
> }
> {code}
> Above test, given a {{letter}}, creates a {{ParallelRunTest-.log}}
> file, and writes 999 times that letter to each line (ending with a line-feed
> character) for 1,000 lines. The eventual file is expected to be of size
> {{lineLength * lineCount = 1,000 * 1,000 = 1e6}}. These assumptions indeed
> hold after a run:
> {code}
> wc -l /tmp/ParallelRunTest-*
>1000 /tmp/ParallelRunTest-A.log
>1000 /tmp/ParallelRunTest-B.log
>1000 /tmp/ParallelRunTest-C.log
>1000 /tmp/ParallelRunTest-D.log
>4000 total
> for log_file in /tmp/ParallelRunTest-*; do
> echo "file: $log_file"
> echo "line lengths:"
> awk "{print length}" $log_file | sort | uniq
> echo "distinct lines:"
> sort $log_file | uniq
> echo
> done
> file: /tmp/ParallelRunTest-A.log
> line lengths:
> 999
> distinct lines:
> AAA...A
> file: /tmp/ParallelRunTest-B.log
> line lengths:
> 999
> distinct lines:
> BBB...B
> file: /tmp/ParallelRunTest-C.log
> line lengths:
> 999
> distinct lines:
> CCC...C
> file: /tmp/ParallelRunTest-D.log
> line lengths:
> 999
> distinct lines:
> DDD...D
> {code}
> Though when {{ExecutionMode.SAME_THREAD}} is replaced with
> {{ExecutionMode.CONCURRENT}} tests fail due to unexpected
> {{appenderFileLength}}:
> {code}
> wc -l /tmp/ParallelRunTest-*
> 96 /tmp/ParallelRunTest-A.log
> 1 /tmp/ParallelRunTest-B.log
> 96 /tmp/ParallelRunTest-C.log
>3577 /tmp/
[jira] [Commented] (LOG4J2-708) Servlet filter claims to support async but doesn't use AsyncContext
[ https://issues.apache.org/jira/browse/LOG4J2-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608514#comment-17608514 ] ASF subversion and git services commented on LOG4J2-708: Commit 432a851f0381a7bf9417a79ea9f9c64748b3020e in logging-log4j2's branch refs/heads/dependabot/maven/org.liquibase-liquibase-core-3.10.3 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=432a851f03 ] [LOG4J2-708] Improve `Log4jServletFilter` async behavior The `Log4jServletFilter` filter should run on all the threads a request is run. The current version ignores all async dispatches. > Servlet filter claims to support async but doesn't use AsyncContext > --- > > Key: LOG4J2-708 > URL: https://issues.apache.org/jira/browse/LOG4J2-708 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.0-rc2 > Environment: Servlet 3.0 (Tomcat 7, Jetty 8) or higher >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Minor > Fix For: 2.19.1 > > > In log4j-web, when the ServletContainerInitializer adds the Log4j Filter, it > sets the asyncSupported property to true. However, it's still a synchronous > Filter. > A separate asynchronous Filter should be made for Servlet 3.x support that > doesn't break Servlet 2.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3564) NPE in JULLogger.getLevel()
[
https://issues.apache.org/jira/browse/LOG4J2-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608503#comment-17608503
]
ASF subversion and git services commented on LOG4J2-3564:
-
Commit c07927c112e2fa622a4087d5283841dc77c82fbe in logging-log4j2's branch
refs/heads/dependabot/maven/org.zapodot-embedded-ldap-junit-0.9.0 from Piotr P.
Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c07927c112 ]
[LOG4J2-3564] Missing changelog
> NPE in JULLogger.getLevel()
> ---
>
> Key: LOG4J2-3564
> URL: https://issues.apache.org/jira/browse/LOG4J2-3564
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-JUL
>Affects Versions: 2.17.2
>Reporter: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> {{JULLogger.getLevel()}} fails with a {{NullPointerException}} if the JUL
> root logger has a {{null}} level. This is a common situation in JDK 8+, since
> {{LogManager$RootLogger}} does not set the log level any more in its
> constructor.
> A practical example where it fails is Tomcat's {{ClassLoaderLogManager}}: cf.
> [BZ 66184|https://bz.apache.org/bugzilla/show_bug.cgi?id=66184].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3188) Concurrent individual LoggerContext initializations cause severe LogEvent drop or incorrect delivery
[
https://issues.apache.org/jira/browse/LOG4J2-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608507#comment-17608507
]
ASF subversion and git services commented on LOG4J2-3188:
-
Commit 5bc48cc9b49b291cb1f41b84fcd1ff2965fa7cf2 in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven.plugins-maven-resources-plugin-3.3.0
from Volkan Yazıcı
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5bc48cc9b4 ]
LOG4J2-3188 Create a fresh LoggerContext in
JsonTemplateLayoutConcurrentEncodeTest.
> Concurrent individual LoggerContext initializations cause severe LogEvent
> drop or incorrect delivery
>
>
> Key: LOG4J2-3188
> URL: https://issues.apache.org/jira/browse/LOG4J2-3188
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> When multiple {{LoggerContext}}'s get initialized concurrently, they affect
> each other causing severe {{LogEvent}} drop and incorrect delivery. Consider
> the following test:
> {code:java}
> @Execution(ExecutionMode.SAME_THREAD)
> class ParallelRunTest {
> @ParameterizedTest
> @ValueSource(chars = {'A', 'B', 'C', 'D'})
> void test(final char letter) {
> // Create the configuration builder.
> final ConfigurationBuilder configBuilder =
> ConfigurationBuilderFactory
> .newConfigurationBuilder()
> .setStatusLevel(Level.ERROR)
> .setConfigurationName("Letter-" + letter);
> // Create the configuration.
> final String appenderName = "File";
> final String appenderFilepath = Paths
> .get(
> System.getProperty("java.io.tmpdir"),
> "ParallelRunTest-" + letter + ".log")
> .toAbsolutePath()
> .toString();
> final Configuration config = configBuilder
> .add(configBuilder
> .newAppender(appenderName, "File")
> .addAttribute("fileName", appenderFilepath)
> .addAttribute("append", false)
> .addAttribute("immediateFlush", false)
> .addAttribute("ignoreExceptions", false)
> .add(configBuilder
> .newLayout("PatternLayout")
> .addAttribute("pattern", "%m\n")))
> .add(configBuilder
> .newRootLogger(Level.ALL)
> .add(configBuilder.newAppenderRef(appenderName)))
> .build(false);
> // Initialize the configuration.
> try (final LoggerContext loggerContext =
> Configurator.initialize(config)) {
> final Logger logger =
> loggerContext.getLogger(ParallelRunTest.class);
> // Write logs.
> final String message = Strings.repeat(String.valueOf(letter),
> 999);
> for (int i = 0; i < 1_000; i++) {
> logger.info(message);
> }
> }
> // Verify the file content.
> final long appenderFileLength = new File(appenderFilepath).length();
> assertThat(appenderFileLength).isEqualTo(1_000_000L);
> }
> }
> {code}
> Above test, given a {{letter}}, creates a {{ParallelRunTest-.log}}
> file, and writes 999 times that letter to each line (ending with a line-feed
> character) for 1,000 lines. The eventual file is expected to be of size
> {{lineLength * lineCount = 1,000 * 1,000 = 1e6}}. These assumptions indeed
> hold after a run:
> {code}
> wc -l /tmp/ParallelRunTest-*
>1000 /tmp/ParallelRunTest-A.log
>1000 /tmp/ParallelRunTest-B.log
>1000 /tmp/ParallelRunTest-C.log
>1000 /tmp/ParallelRunTest-D.log
>4000 total
> for log_file in /tmp/ParallelRunTest-*; do
> echo "file: $log_file"
> echo "line lengths:"
> awk "{print length}" $log_file | sort | uniq
> echo "distinct lines:"
> sort $log_file | uniq
> echo
> done
> file: /tmp/ParallelRunTest-A.log
> line lengths:
> 999
> distinct lines:
> AAA...A
> file: /tmp/ParallelRunTest-B.log
> line lengths:
> 999
> distinct lines:
> BBB...B
> file: /tmp/ParallelRunTest-C.log
> line lengths:
> 999
> distinct lines:
> CCC...C
> file: /tmp/ParallelRunTest-D.log
> line lengths:
> 999
> distinct lines:
> DDD...D
> {code}
> Though when {{ExecutionMode.SAME_THREAD}} is replaced with
> {{ExecutionMode.CONCURRENT}} tests fail due to unexpected
> {{appenderFileLength}}:
> {code}
> wc -l /tmp/ParallelRunTest-*
> 96 /tmp/ParallelRunTest-A.log
> 1 /tmp/ParallelRunTest-B.log
> 96 /tmp/ParallelRunTest-C.log
>3577
[jira] [Commented] (LOG4J2-708) Servlet filter claims to support async but doesn't use AsyncContext
[ https://issues.apache.org/jira/browse/LOG4J2-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608521#comment-17608521 ] ASF subversion and git services commented on LOG4J2-708: Commit 432a851f0381a7bf9417a79ea9f9c64748b3020e in logging-log4j2's branch refs/heads/dependabot/maven/org.apache.maven.plugins-maven-site-plugin-3.12.1 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=432a851f03 ] [LOG4J2-708] Improve `Log4jServletFilter` async behavior The `Log4jServletFilter` filter should run on all the threads a request is run. The current version ignores all async dispatches. > Servlet filter claims to support async but doesn't use AsyncContext > --- > > Key: LOG4J2-708 > URL: https://issues.apache.org/jira/browse/LOG4J2-708 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.0-rc2 > Environment: Servlet 3.0 (Tomcat 7, Jetty 8) or higher >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Minor > Fix For: 2.19.1 > > > In log4j-web, when the ServletContainerInitializer adds the Log4j Filter, it > sets the asyncSupported property to true. However, it's still a synchronous > Filter. > A separate asynchronous Filter should be made for Servlet 3.x support that > doesn't break Servlet 2.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3564) NPE in JULLogger.getLevel()
[
https://issues.apache.org/jira/browse/LOG4J2-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608525#comment-17608525
]
ASF subversion and git services commented on LOG4J2-3564:
-
Commit c07927c112e2fa622a4087d5283841dc77c82fbe in logging-log4j2's branch
refs/heads/dependabot/maven/net.java.dev.jna-jna-5.12.1 from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c07927c112 ]
[LOG4J2-3564] Missing changelog
> NPE in JULLogger.getLevel()
> ---
>
> Key: LOG4J2-3564
> URL: https://issues.apache.org/jira/browse/LOG4J2-3564
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-JUL
>Affects Versions: 2.17.2
>Reporter: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> {{JULLogger.getLevel()}} fails with a {{NullPointerException}} if the JUL
> root logger has a {{null}} level. This is a common situation in JDK 8+, since
> {{LogManager$RootLogger}} does not set the log level any more in its
> constructor.
> A practical example where it fails is Tomcat's {{ClassLoaderLogManager}}: cf.
> [BZ 66184|https://bz.apache.org/bugzilla/show_bug.cgi?id=66184].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3188) Concurrent individual LoggerContext initializations cause severe LogEvent drop or incorrect delivery
[
https://issues.apache.org/jira/browse/LOG4J2-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608504#comment-17608504
]
ASF subversion and git services commented on LOG4J2-3188:
-
Commit 5bc48cc9b49b291cb1f41b84fcd1ff2965fa7cf2 in logging-log4j2's branch
refs/heads/dependabot/maven/org.zapodot-embedded-ldap-junit-0.9.0 from Volkan
Yazıcı
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5bc48cc9b4 ]
LOG4J2-3188 Create a fresh LoggerContext in
JsonTemplateLayoutConcurrentEncodeTest.
> Concurrent individual LoggerContext initializations cause severe LogEvent
> drop or incorrect delivery
>
>
> Key: LOG4J2-3188
> URL: https://issues.apache.org/jira/browse/LOG4J2-3188
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> When multiple {{LoggerContext}}'s get initialized concurrently, they affect
> each other causing severe {{LogEvent}} drop and incorrect delivery. Consider
> the following test:
> {code:java}
> @Execution(ExecutionMode.SAME_THREAD)
> class ParallelRunTest {
> @ParameterizedTest
> @ValueSource(chars = {'A', 'B', 'C', 'D'})
> void test(final char letter) {
> // Create the configuration builder.
> final ConfigurationBuilder configBuilder =
> ConfigurationBuilderFactory
> .newConfigurationBuilder()
> .setStatusLevel(Level.ERROR)
> .setConfigurationName("Letter-" + letter);
> // Create the configuration.
> final String appenderName = "File";
> final String appenderFilepath = Paths
> .get(
> System.getProperty("java.io.tmpdir"),
> "ParallelRunTest-" + letter + ".log")
> .toAbsolutePath()
> .toString();
> final Configuration config = configBuilder
> .add(configBuilder
> .newAppender(appenderName, "File")
> .addAttribute("fileName", appenderFilepath)
> .addAttribute("append", false)
> .addAttribute("immediateFlush", false)
> .addAttribute("ignoreExceptions", false)
> .add(configBuilder
> .newLayout("PatternLayout")
> .addAttribute("pattern", "%m\n")))
> .add(configBuilder
> .newRootLogger(Level.ALL)
> .add(configBuilder.newAppenderRef(appenderName)))
> .build(false);
> // Initialize the configuration.
> try (final LoggerContext loggerContext =
> Configurator.initialize(config)) {
> final Logger logger =
> loggerContext.getLogger(ParallelRunTest.class);
> // Write logs.
> final String message = Strings.repeat(String.valueOf(letter),
> 999);
> for (int i = 0; i < 1_000; i++) {
> logger.info(message);
> }
> }
> // Verify the file content.
> final long appenderFileLength = new File(appenderFilepath).length();
> assertThat(appenderFileLength).isEqualTo(1_000_000L);
> }
> }
> {code}
> Above test, given a {{letter}}, creates a {{ParallelRunTest-.log}}
> file, and writes 999 times that letter to each line (ending with a line-feed
> character) for 1,000 lines. The eventual file is expected to be of size
> {{lineLength * lineCount = 1,000 * 1,000 = 1e6}}. These assumptions indeed
> hold after a run:
> {code}
> wc -l /tmp/ParallelRunTest-*
>1000 /tmp/ParallelRunTest-A.log
>1000 /tmp/ParallelRunTest-B.log
>1000 /tmp/ParallelRunTest-C.log
>1000 /tmp/ParallelRunTest-D.log
>4000 total
> for log_file in /tmp/ParallelRunTest-*; do
> echo "file: $log_file"
> echo "line lengths:"
> awk "{print length}" $log_file | sort | uniq
> echo "distinct lines:"
> sort $log_file | uniq
> echo
> done
> file: /tmp/ParallelRunTest-A.log
> line lengths:
> 999
> distinct lines:
> AAA...A
> file: /tmp/ParallelRunTest-B.log
> line lengths:
> 999
> distinct lines:
> BBB...B
> file: /tmp/ParallelRunTest-C.log
> line lengths:
> 999
> distinct lines:
> CCC...C
> file: /tmp/ParallelRunTest-D.log
> line lengths:
> 999
> distinct lines:
> DDD...D
> {code}
> Though when {{ExecutionMode.SAME_THREAD}} is replaced with
> {{ExecutionMode.CONCURRENT}} tests fail due to unexpected
> {{appenderFileLength}}:
> {code}
> wc -l /tmp/ParallelRunTest-*
> 96 /tmp/ParallelRunTest-A.log
> 1 /tmp/ParallelRunTest-B.log
> 96 /tmp/ParallelRunTest-C.log
>3577 /tmp/ParallelRu
[jira] [Commented] (LOG4J2-3188) Concurrent individual LoggerContext initializations cause severe LogEvent drop or incorrect delivery
[
https://issues.apache.org/jira/browse/LOG4J2-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608501#comment-17608501
]
ASF subversion and git services commented on LOG4J2-3188:
-
Commit 5bc48cc9b49b291cb1f41b84fcd1ff2965fa7cf2 in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven.plugins-maven-install-plugin-3.0.1
from Volkan Yazıcı
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5bc48cc9b4 ]
LOG4J2-3188 Create a fresh LoggerContext in
JsonTemplateLayoutConcurrentEncodeTest.
> Concurrent individual LoggerContext initializations cause severe LogEvent
> drop or incorrect delivery
>
>
> Key: LOG4J2-3188
> URL: https://issues.apache.org/jira/browse/LOG4J2-3188
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> When multiple {{LoggerContext}}'s get initialized concurrently, they affect
> each other causing severe {{LogEvent}} drop and incorrect delivery. Consider
> the following test:
> {code:java}
> @Execution(ExecutionMode.SAME_THREAD)
> class ParallelRunTest {
> @ParameterizedTest
> @ValueSource(chars = {'A', 'B', 'C', 'D'})
> void test(final char letter) {
> // Create the configuration builder.
> final ConfigurationBuilder configBuilder =
> ConfigurationBuilderFactory
> .newConfigurationBuilder()
> .setStatusLevel(Level.ERROR)
> .setConfigurationName("Letter-" + letter);
> // Create the configuration.
> final String appenderName = "File";
> final String appenderFilepath = Paths
> .get(
> System.getProperty("java.io.tmpdir"),
> "ParallelRunTest-" + letter + ".log")
> .toAbsolutePath()
> .toString();
> final Configuration config = configBuilder
> .add(configBuilder
> .newAppender(appenderName, "File")
> .addAttribute("fileName", appenderFilepath)
> .addAttribute("append", false)
> .addAttribute("immediateFlush", false)
> .addAttribute("ignoreExceptions", false)
> .add(configBuilder
> .newLayout("PatternLayout")
> .addAttribute("pattern", "%m\n")))
> .add(configBuilder
> .newRootLogger(Level.ALL)
> .add(configBuilder.newAppenderRef(appenderName)))
> .build(false);
> // Initialize the configuration.
> try (final LoggerContext loggerContext =
> Configurator.initialize(config)) {
> final Logger logger =
> loggerContext.getLogger(ParallelRunTest.class);
> // Write logs.
> final String message = Strings.repeat(String.valueOf(letter),
> 999);
> for (int i = 0; i < 1_000; i++) {
> logger.info(message);
> }
> }
> // Verify the file content.
> final long appenderFileLength = new File(appenderFilepath).length();
> assertThat(appenderFileLength).isEqualTo(1_000_000L);
> }
> }
> {code}
> Above test, given a {{letter}}, creates a {{ParallelRunTest-.log}}
> file, and writes 999 times that letter to each line (ending with a line-feed
> character) for 1,000 lines. The eventual file is expected to be of size
> {{lineLength * lineCount = 1,000 * 1,000 = 1e6}}. These assumptions indeed
> hold after a run:
> {code}
> wc -l /tmp/ParallelRunTest-*
>1000 /tmp/ParallelRunTest-A.log
>1000 /tmp/ParallelRunTest-B.log
>1000 /tmp/ParallelRunTest-C.log
>1000 /tmp/ParallelRunTest-D.log
>4000 total
> for log_file in /tmp/ParallelRunTest-*; do
> echo "file: $log_file"
> echo "line lengths:"
> awk "{print length}" $log_file | sort | uniq
> echo "distinct lines:"
> sort $log_file | uniq
> echo
> done
> file: /tmp/ParallelRunTest-A.log
> line lengths:
> 999
> distinct lines:
> AAA...A
> file: /tmp/ParallelRunTest-B.log
> line lengths:
> 999
> distinct lines:
> BBB...B
> file: /tmp/ParallelRunTest-C.log
> line lengths:
> 999
> distinct lines:
> CCC...C
> file: /tmp/ParallelRunTest-D.log
> line lengths:
> 999
> distinct lines:
> DDD...D
> {code}
> Though when {{ExecutionMode.SAME_THREAD}} is replaced with
> {{ExecutionMode.CONCURRENT}} tests fail due to unexpected
> {{appenderFileLength}}:
> {code}
> wc -l /tmp/ParallelRunTest-*
> 96 /tmp/ParallelRunTest-A.log
> 1 /tmp/ParallelRunTest-B.log
> 96 /tmp/ParallelRunTest-C.log
>3577 /
[jira] [Commented] (LOG4J2-708) Servlet filter claims to support async but doesn't use AsyncContext
[ https://issues.apache.org/jira/browse/LOG4J2-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608505#comment-17608505 ] ASF subversion and git services commented on LOG4J2-708: Commit 432a851f0381a7bf9417a79ea9f9c64748b3020e in logging-log4j2's branch refs/heads/dependabot/maven/org.apache.maven.plugins-maven-resources-plugin-3.3.0 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=432a851f03 ] [LOG4J2-708] Improve `Log4jServletFilter` async behavior The `Log4jServletFilter` filter should run on all the threads a request is run. The current version ignores all async dispatches. > Servlet filter claims to support async but doesn't use AsyncContext > --- > > Key: LOG4J2-708 > URL: https://issues.apache.org/jira/browse/LOG4J2-708 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.0-rc2 > Environment: Servlet 3.0 (Tomcat 7, Jetty 8) or higher >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Minor > Fix For: 2.19.1 > > > In log4j-web, when the ServletContainerInitializer adds the Log4j Filter, it > sets the asyncSupported property to true. However, it's still a synchronous > Filter. > A separate asynchronous Filter should be made for Servlet 3.x support that > doesn't break Servlet 2.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3564) NPE in JULLogger.getLevel()
[
https://issues.apache.org/jira/browse/LOG4J2-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608509#comment-17608509
]
ASF subversion and git services commented on LOG4J2-3564:
-
Commit c07927c112e2fa622a4087d5283841dc77c82fbe in logging-log4j2's branch
refs/heads/dependabot/maven/org.eclipse.persistence-org.eclipse.persistence.jpa-2.7.11
from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c07927c112 ]
[LOG4J2-3564] Missing changelog
> NPE in JULLogger.getLevel()
> ---
>
> Key: LOG4J2-3564
> URL: https://issues.apache.org/jira/browse/LOG4J2-3564
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-JUL
>Affects Versions: 2.17.2
>Reporter: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> {{JULLogger.getLevel()}} fails with a {{NullPointerException}} if the JUL
> root logger has a {{null}} level. This is a common situation in JDK 8+, since
> {{LogManager$RootLogger}} does not set the log level any more in its
> constructor.
> A practical example where it fails is Tomcat's {{ClassLoaderLogManager}}: cf.
> [BZ 66184|https://bz.apache.org/bugzilla/show_bug.cgi?id=66184].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-708) Servlet filter claims to support async but doesn't use AsyncContext
[ https://issues.apache.org/jira/browse/LOG4J2-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608511#comment-17608511 ] ASF subversion and git services commented on LOG4J2-708: Commit 432a851f0381a7bf9417a79ea9f9c64748b3020e in logging-log4j2's branch refs/heads/dependabot/maven/org.apache.maven.plugins-maven-assembly-plugin-3.4.2 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=432a851f03 ] [LOG4J2-708] Improve `Log4jServletFilter` async behavior The `Log4jServletFilter` filter should run on all the threads a request is run. The current version ignores all async dispatches. > Servlet filter claims to support async but doesn't use AsyncContext > --- > > Key: LOG4J2-708 > URL: https://issues.apache.org/jira/browse/LOG4J2-708 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.0-rc2 > Environment: Servlet 3.0 (Tomcat 7, Jetty 8) or higher >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Minor > Fix For: 2.19.1 > > > In log4j-web, when the ServletContainerInitializer adds the Log4j Filter, it > sets the asyncSupported property to true. However, it's still a synchronous > Filter. > A separate asynchronous Filter should be made for Servlet 3.x support that > doesn't break Servlet 2.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-708) Servlet filter claims to support async but doesn't use AsyncContext
[ https://issues.apache.org/jira/browse/LOG4J2-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608502#comment-17608502 ] ASF subversion and git services commented on LOG4J2-708: Commit 432a851f0381a7bf9417a79ea9f9c64748b3020e in logging-log4j2's branch refs/heads/dependabot/maven/org.zapodot-embedded-ldap-junit-0.9.0 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=432a851f03 ] [LOG4J2-708] Improve `Log4jServletFilter` async behavior The `Log4jServletFilter` filter should run on all the threads a request is run. The current version ignores all async dispatches. > Servlet filter claims to support async but doesn't use AsyncContext > --- > > Key: LOG4J2-708 > URL: https://issues.apache.org/jira/browse/LOG4J2-708 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.0-rc2 > Environment: Servlet 3.0 (Tomcat 7, Jetty 8) or higher >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Minor > Fix For: 2.19.1 > > > In log4j-web, when the ServletContainerInitializer adds the Log4j Filter, it > sets the asyncSupported property to true. However, it's still a synchronous > Filter. > A separate asynchronous Filter should be made for Servlet 3.x support that > doesn't break Servlet 2.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-708) Servlet filter claims to support async but doesn't use AsyncContext
[ https://issues.apache.org/jira/browse/LOG4J2-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608496#comment-17608496 ] ASF subversion and git services commented on LOG4J2-708: Commit 432a851f0381a7bf9417a79ea9f9c64748b3020e in logging-log4j2's branch refs/heads/dependabot/maven/org.apache.maven.plugins-maven-toolchains-plugin-3.1.0 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=432a851f03 ] [LOG4J2-708] Improve `Log4jServletFilter` async behavior The `Log4jServletFilter` filter should run on all the threads a request is run. The current version ignores all async dispatches. > Servlet filter claims to support async but doesn't use AsyncContext > --- > > Key: LOG4J2-708 > URL: https://issues.apache.org/jira/browse/LOG4J2-708 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.0-rc2 > Environment: Servlet 3.0 (Tomcat 7, Jetty 8) or higher >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Minor > Fix For: 2.19.1 > > > In log4j-web, when the ServletContainerInitializer adds the Log4j Filter, it > sets the asyncSupported property to true. However, it's still a synchronous > Filter. > A separate asynchronous Filter should be made for Servlet 3.x support that > doesn't break Servlet 2.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3188) Concurrent individual LoggerContext initializations cause severe LogEvent drop or incorrect delivery
[
https://issues.apache.org/jira/browse/LOG4J2-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608498#comment-17608498
]
ASF subversion and git services commented on LOG4J2-3188:
-
Commit 5bc48cc9b49b291cb1f41b84fcd1ff2965fa7cf2 in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven.plugins-maven-toolchains-plugin-3.1.0
from Volkan Yazıcı
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5bc48cc9b4 ]
LOG4J2-3188 Create a fresh LoggerContext in
JsonTemplateLayoutConcurrentEncodeTest.
> Concurrent individual LoggerContext initializations cause severe LogEvent
> drop or incorrect delivery
>
>
> Key: LOG4J2-3188
> URL: https://issues.apache.org/jira/browse/LOG4J2-3188
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> When multiple {{LoggerContext}}'s get initialized concurrently, they affect
> each other causing severe {{LogEvent}} drop and incorrect delivery. Consider
> the following test:
> {code:java}
> @Execution(ExecutionMode.SAME_THREAD)
> class ParallelRunTest {
> @ParameterizedTest
> @ValueSource(chars = {'A', 'B', 'C', 'D'})
> void test(final char letter) {
> // Create the configuration builder.
> final ConfigurationBuilder configBuilder =
> ConfigurationBuilderFactory
> .newConfigurationBuilder()
> .setStatusLevel(Level.ERROR)
> .setConfigurationName("Letter-" + letter);
> // Create the configuration.
> final String appenderName = "File";
> final String appenderFilepath = Paths
> .get(
> System.getProperty("java.io.tmpdir"),
> "ParallelRunTest-" + letter + ".log")
> .toAbsolutePath()
> .toString();
> final Configuration config = configBuilder
> .add(configBuilder
> .newAppender(appenderName, "File")
> .addAttribute("fileName", appenderFilepath)
> .addAttribute("append", false)
> .addAttribute("immediateFlush", false)
> .addAttribute("ignoreExceptions", false)
> .add(configBuilder
> .newLayout("PatternLayout")
> .addAttribute("pattern", "%m\n")))
> .add(configBuilder
> .newRootLogger(Level.ALL)
> .add(configBuilder.newAppenderRef(appenderName)))
> .build(false);
> // Initialize the configuration.
> try (final LoggerContext loggerContext =
> Configurator.initialize(config)) {
> final Logger logger =
> loggerContext.getLogger(ParallelRunTest.class);
> // Write logs.
> final String message = Strings.repeat(String.valueOf(letter),
> 999);
> for (int i = 0; i < 1_000; i++) {
> logger.info(message);
> }
> }
> // Verify the file content.
> final long appenderFileLength = new File(appenderFilepath).length();
> assertThat(appenderFileLength).isEqualTo(1_000_000L);
> }
> }
> {code}
> Above test, given a {{letter}}, creates a {{ParallelRunTest-.log}}
> file, and writes 999 times that letter to each line (ending with a line-feed
> character) for 1,000 lines. The eventual file is expected to be of size
> {{lineLength * lineCount = 1,000 * 1,000 = 1e6}}. These assumptions indeed
> hold after a run:
> {code}
> wc -l /tmp/ParallelRunTest-*
>1000 /tmp/ParallelRunTest-A.log
>1000 /tmp/ParallelRunTest-B.log
>1000 /tmp/ParallelRunTest-C.log
>1000 /tmp/ParallelRunTest-D.log
>4000 total
> for log_file in /tmp/ParallelRunTest-*; do
> echo "file: $log_file"
> echo "line lengths:"
> awk "{print length}" $log_file | sort | uniq
> echo "distinct lines:"
> sort $log_file | uniq
> echo
> done
> file: /tmp/ParallelRunTest-A.log
> line lengths:
> 999
> distinct lines:
> AAA...A
> file: /tmp/ParallelRunTest-B.log
> line lengths:
> 999
> distinct lines:
> BBB...B
> file: /tmp/ParallelRunTest-C.log
> line lengths:
> 999
> distinct lines:
> CCC...C
> file: /tmp/ParallelRunTest-D.log
> line lengths:
> 999
> distinct lines:
> DDD...D
> {code}
> Though when {{ExecutionMode.SAME_THREAD}} is replaced with
> {{ExecutionMode.CONCURRENT}} tests fail due to unexpected
> {{appenderFileLength}}:
> {code}
> wc -l /tmp/ParallelRunTest-*
> 96 /tmp/ParallelRunTest-A.log
> 1 /tmp/ParallelRunTest-B.log
> 96 /tmp/ParallelRunTest-C.log
>357
[jira] [Commented] (LOG4J2-3564) NPE in JULLogger.getLevel()
[
https://issues.apache.org/jira/browse/LOG4J2-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608494#comment-17608494
]
ASF subversion and git services commented on LOG4J2-3564:
-
Commit c07927c112e2fa622a4087d5283841dc77c82fbe in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven-maven-core-3.8.6 from Piotr P.
Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c07927c112 ]
[LOG4J2-3564] Missing changelog
> NPE in JULLogger.getLevel()
> ---
>
> Key: LOG4J2-3564
> URL: https://issues.apache.org/jira/browse/LOG4J2-3564
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-JUL
>Affects Versions: 2.17.2
>Reporter: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> {{JULLogger.getLevel()}} fails with a {{NullPointerException}} if the JUL
> root logger has a {{null}} level. This is a common situation in JDK 8+, since
> {{LogManager$RootLogger}} does not set the log level any more in its
> constructor.
> A practical example where it fails is Tomcat's {{ClassLoaderLogManager}}: cf.
> [BZ 66184|https://bz.apache.org/bugzilla/show_bug.cgi?id=66184].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3564) NPE in JULLogger.getLevel()
[
https://issues.apache.org/jira/browse/LOG4J2-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608500#comment-17608500
]
ASF subversion and git services commented on LOG4J2-3564:
-
Commit c07927c112e2fa622a4087d5283841dc77c82fbe in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven.plugins-maven-install-plugin-3.0.1
from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c07927c112 ]
[LOG4J2-3564] Missing changelog
> NPE in JULLogger.getLevel()
> ---
>
> Key: LOG4J2-3564
> URL: https://issues.apache.org/jira/browse/LOG4J2-3564
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-JUL
>Affects Versions: 2.17.2
>Reporter: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> {{JULLogger.getLevel()}} fails with a {{NullPointerException}} if the JUL
> root logger has a {{null}} level. This is a common situation in JDK 8+, since
> {{LogManager$RootLogger}} does not set the log level any more in its
> constructor.
> A practical example where it fails is Tomcat's {{ClassLoaderLogManager}}: cf.
> [BZ 66184|https://bz.apache.org/bugzilla/show_bug.cgi?id=66184].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-708) Servlet filter claims to support async but doesn't use AsyncContext
[ https://issues.apache.org/jira/browse/LOG4J2-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608493#comment-17608493 ] ASF subversion and git services commented on LOG4J2-708: Commit 432a851f0381a7bf9417a79ea9f9c64748b3020e in logging-log4j2's branch refs/heads/dependabot/maven/org.apache.maven-maven-core-3.8.6 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=432a851f03 ] [LOG4J2-708] Improve `Log4jServletFilter` async behavior The `Log4jServletFilter` filter should run on all the threads a request is run. The current version ignores all async dispatches. > Servlet filter claims to support async but doesn't use AsyncContext > --- > > Key: LOG4J2-708 > URL: https://issues.apache.org/jira/browse/LOG4J2-708 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.0-rc2 > Environment: Servlet 3.0 (Tomcat 7, Jetty 8) or higher >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Minor > Fix For: 2.19.1 > > > In log4j-web, when the ServletContainerInitializer adds the Log4j Filter, it > sets the asyncSupported property to true. However, it's still a synchronous > Filter. > A separate asynchronous Filter should be made for Servlet 3.x support that > doesn't break Servlet 2.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3564) NPE in JULLogger.getLevel()
[
https://issues.apache.org/jira/browse/LOG4J2-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608497#comment-17608497
]
ASF subversion and git services commented on LOG4J2-3564:
-
Commit c07927c112e2fa622a4087d5283841dc77c82fbe in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven.plugins-maven-toolchains-plugin-3.1.0
from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c07927c112 ]
[LOG4J2-3564] Missing changelog
> NPE in JULLogger.getLevel()
> ---
>
> Key: LOG4J2-3564
> URL: https://issues.apache.org/jira/browse/LOG4J2-3564
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-JUL
>Affects Versions: 2.17.2
>Reporter: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> {{JULLogger.getLevel()}} fails with a {{NullPointerException}} if the JUL
> root logger has a {{null}} level. This is a common situation in JDK 8+, since
> {{LogManager$RootLogger}} does not set the log level any more in its
> constructor.
> A practical example where it fails is Tomcat's {{ClassLoaderLogManager}}: cf.
> [BZ 66184|https://bz.apache.org/bugzilla/show_bug.cgi?id=66184].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-708) Servlet filter claims to support async but doesn't use AsyncContext
[ https://issues.apache.org/jira/browse/LOG4J2-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608499#comment-17608499 ] ASF subversion and git services commented on LOG4J2-708: Commit 432a851f0381a7bf9417a79ea9f9c64748b3020e in logging-log4j2's branch refs/heads/dependabot/maven/org.apache.maven.plugins-maven-install-plugin-3.0.1 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=432a851f03 ] [LOG4J2-708] Improve `Log4jServletFilter` async behavior The `Log4jServletFilter` filter should run on all the threads a request is run. The current version ignores all async dispatches. > Servlet filter claims to support async but doesn't use AsyncContext > --- > > Key: LOG4J2-708 > URL: https://issues.apache.org/jira/browse/LOG4J2-708 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.0-rc2 > Environment: Servlet 3.0 (Tomcat 7, Jetty 8) or higher >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Minor > Fix For: 2.19.1 > > > In log4j-web, when the ServletContainerInitializer adds the Log4j Filter, it > sets the asyncSupported property to true. However, it's still a synchronous > Filter. > A separate asynchronous Filter should be made for Servlet 3.x support that > doesn't break Servlet 2.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3188) Concurrent individual LoggerContext initializations cause severe LogEvent drop or incorrect delivery
[
https://issues.apache.org/jira/browse/LOG4J2-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608495#comment-17608495
]
ASF subversion and git services commented on LOG4J2-3188:
-
Commit 5bc48cc9b49b291cb1f41b84fcd1ff2965fa7cf2 in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.maven-maven-core-3.8.6 from Volkan Yazıcı
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5bc48cc9b4 ]
LOG4J2-3188 Create a fresh LoggerContext in
JsonTemplateLayoutConcurrentEncodeTest.
> Concurrent individual LoggerContext initializations cause severe LogEvent
> drop or incorrect delivery
>
>
> Key: LOG4J2-3188
> URL: https://issues.apache.org/jira/browse/LOG4J2-3188
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> When multiple {{LoggerContext}}'s get initialized concurrently, they affect
> each other causing severe {{LogEvent}} drop and incorrect delivery. Consider
> the following test:
> {code:java}
> @Execution(ExecutionMode.SAME_THREAD)
> class ParallelRunTest {
> @ParameterizedTest
> @ValueSource(chars = {'A', 'B', 'C', 'D'})
> void test(final char letter) {
> // Create the configuration builder.
> final ConfigurationBuilder configBuilder =
> ConfigurationBuilderFactory
> .newConfigurationBuilder()
> .setStatusLevel(Level.ERROR)
> .setConfigurationName("Letter-" + letter);
> // Create the configuration.
> final String appenderName = "File";
> final String appenderFilepath = Paths
> .get(
> System.getProperty("java.io.tmpdir"),
> "ParallelRunTest-" + letter + ".log")
> .toAbsolutePath()
> .toString();
> final Configuration config = configBuilder
> .add(configBuilder
> .newAppender(appenderName, "File")
> .addAttribute("fileName", appenderFilepath)
> .addAttribute("append", false)
> .addAttribute("immediateFlush", false)
> .addAttribute("ignoreExceptions", false)
> .add(configBuilder
> .newLayout("PatternLayout")
> .addAttribute("pattern", "%m\n")))
> .add(configBuilder
> .newRootLogger(Level.ALL)
> .add(configBuilder.newAppenderRef(appenderName)))
> .build(false);
> // Initialize the configuration.
> try (final LoggerContext loggerContext =
> Configurator.initialize(config)) {
> final Logger logger =
> loggerContext.getLogger(ParallelRunTest.class);
> // Write logs.
> final String message = Strings.repeat(String.valueOf(letter),
> 999);
> for (int i = 0; i < 1_000; i++) {
> logger.info(message);
> }
> }
> // Verify the file content.
> final long appenderFileLength = new File(appenderFilepath).length();
> assertThat(appenderFileLength).isEqualTo(1_000_000L);
> }
> }
> {code}
> Above test, given a {{letter}}, creates a {{ParallelRunTest-.log}}
> file, and writes 999 times that letter to each line (ending with a line-feed
> character) for 1,000 lines. The eventual file is expected to be of size
> {{lineLength * lineCount = 1,000 * 1,000 = 1e6}}. These assumptions indeed
> hold after a run:
> {code}
> wc -l /tmp/ParallelRunTest-*
>1000 /tmp/ParallelRunTest-A.log
>1000 /tmp/ParallelRunTest-B.log
>1000 /tmp/ParallelRunTest-C.log
>1000 /tmp/ParallelRunTest-D.log
>4000 total
> for log_file in /tmp/ParallelRunTest-*; do
> echo "file: $log_file"
> echo "line lengths:"
> awk "{print length}" $log_file | sort | uniq
> echo "distinct lines:"
> sort $log_file | uniq
> echo
> done
> file: /tmp/ParallelRunTest-A.log
> line lengths:
> 999
> distinct lines:
> AAA...A
> file: /tmp/ParallelRunTest-B.log
> line lengths:
> 999
> distinct lines:
> BBB...B
> file: /tmp/ParallelRunTest-C.log
> line lengths:
> 999
> distinct lines:
> CCC...C
> file: /tmp/ParallelRunTest-D.log
> line lengths:
> 999
> distinct lines:
> DDD...D
> {code}
> Though when {{ExecutionMode.SAME_THREAD}} is replaced with
> {{ExecutionMode.CONCURRENT}} tests fail due to unexpected
> {{appenderFileLength}}:
> {code}
> wc -l /tmp/ParallelRunTest-*
> 96 /tmp/ParallelRunTest-A.log
> 1 /tmp/ParallelRunTest-B.log
> 96 /tmp/ParallelRunTest-C.log
>3577 /tmp/ParallelRunTest
[jira] [Commented] (LOG4J2-3188) Concurrent individual LoggerContext initializations cause severe LogEvent drop or incorrect delivery
[
https://issues.apache.org/jira/browse/LOG4J2-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606346#comment-17606346
]
ASF subversion and git services commented on LOG4J2-3188:
-
Commit 5bc48cc9b49b291cb1f41b84fcd1ff2965fa7cf2 in logging-log4j2's branch
refs/heads/release-2.x from Volkan Yazıcı
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5bc48cc9b4 ]
LOG4J2-3188 Create a fresh LoggerContext in
JsonTemplateLayoutConcurrentEncodeTest.
> Concurrent individual LoggerContext initializations cause severe LogEvent
> drop or incorrect delivery
>
>
> Key: LOG4J2-3188
> URL: https://issues.apache.org/jira/browse/LOG4J2-3188
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> When multiple {{LoggerContext}}'s get initialized concurrently, they affect
> each other causing severe {{LogEvent}} drop and incorrect delivery. Consider
> the following test:
> {code:java}
> @Execution(ExecutionMode.SAME_THREAD)
> class ParallelRunTest {
> @ParameterizedTest
> @ValueSource(chars = {'A', 'B', 'C', 'D'})
> void test(final char letter) {
> // Create the configuration builder.
> final ConfigurationBuilder configBuilder =
> ConfigurationBuilderFactory
> .newConfigurationBuilder()
> .setStatusLevel(Level.ERROR)
> .setConfigurationName("Letter-" + letter);
> // Create the configuration.
> final String appenderName = "File";
> final String appenderFilepath = Paths
> .get(
> System.getProperty("java.io.tmpdir"),
> "ParallelRunTest-" + letter + ".log")
> .toAbsolutePath()
> .toString();
> final Configuration config = configBuilder
> .add(configBuilder
> .newAppender(appenderName, "File")
> .addAttribute("fileName", appenderFilepath)
> .addAttribute("append", false)
> .addAttribute("immediateFlush", false)
> .addAttribute("ignoreExceptions", false)
> .add(configBuilder
> .newLayout("PatternLayout")
> .addAttribute("pattern", "%m\n")))
> .add(configBuilder
> .newRootLogger(Level.ALL)
> .add(configBuilder.newAppenderRef(appenderName)))
> .build(false);
> // Initialize the configuration.
> try (final LoggerContext loggerContext =
> Configurator.initialize(config)) {
> final Logger logger =
> loggerContext.getLogger(ParallelRunTest.class);
> // Write logs.
> final String message = Strings.repeat(String.valueOf(letter),
> 999);
> for (int i = 0; i < 1_000; i++) {
> logger.info(message);
> }
> }
> // Verify the file content.
> final long appenderFileLength = new File(appenderFilepath).length();
> assertThat(appenderFileLength).isEqualTo(1_000_000L);
> }
> }
> {code}
> Above test, given a {{letter}}, creates a {{ParallelRunTest-.log}}
> file, and writes 999 times that letter to each line (ending with a line-feed
> character) for 1,000 lines. The eventual file is expected to be of size
> {{lineLength * lineCount = 1,000 * 1,000 = 1e6}}. These assumptions indeed
> hold after a run:
> {code}
> wc -l /tmp/ParallelRunTest-*
>1000 /tmp/ParallelRunTest-A.log
>1000 /tmp/ParallelRunTest-B.log
>1000 /tmp/ParallelRunTest-C.log
>1000 /tmp/ParallelRunTest-D.log
>4000 total
> for log_file in /tmp/ParallelRunTest-*; do
> echo "file: $log_file"
> echo "line lengths:"
> awk "{print length}" $log_file | sort | uniq
> echo "distinct lines:"
> sort $log_file | uniq
> echo
> done
> file: /tmp/ParallelRunTest-A.log
> line lengths:
> 999
> distinct lines:
> AAA...A
> file: /tmp/ParallelRunTest-B.log
> line lengths:
> 999
> distinct lines:
> BBB...B
> file: /tmp/ParallelRunTest-C.log
> line lengths:
> 999
> distinct lines:
> CCC...C
> file: /tmp/ParallelRunTest-D.log
> line lengths:
> 999
> distinct lines:
> DDD...D
> {code}
> Though when {{ExecutionMode.SAME_THREAD}} is replaced with
> {{ExecutionMode.CONCURRENT}} tests fail due to unexpected
> {{appenderFileLength}}:
> {code}
> wc -l /tmp/ParallelRunTest-*
> 96 /tmp/ParallelRunTest-A.log
> 1 /tmp/ParallelRunTest-B.log
> 96 /tmp/ParallelRunTest-C.log
>3577 /tmp/ParallelRunTest-D.log
>3770 total
> for log_file i
[jira] [Commented] (LOG4J2-3564) NPE in JULLogger.getLevel()
[
https://issues.apache.org/jira/browse/LOG4J2-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606182#comment-17606182
]
ASF subversion and git services commented on LOG4J2-3564:
-
Commit c07927c112e2fa622a4087d5283841dc77c82fbe in logging-log4j2's branch
refs/heads/dependabot/maven/org.apache.felix-maven-bundle-plugin-5.1.8 from
Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c07927c112 ]
[LOG4J2-3564] Missing changelog
> NPE in JULLogger.getLevel()
> ---
>
> Key: LOG4J2-3564
> URL: https://issues.apache.org/jira/browse/LOG4J2-3564
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-JUL
>Affects Versions: 2.17.2
>Reporter: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> {{JULLogger.getLevel()}} fails with a {{NullPointerException}} if the JUL
> root logger has a {{null}} level. This is a common situation in JDK 8+, since
> {{LogManager$RootLogger}} does not set the log level any more in its
> constructor.
> A practical example where it fails is Tomcat's {{ClassLoaderLogManager}}: cf.
> [BZ 66184|https://bz.apache.org/bugzilla/show_bug.cgi?id=66184].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-708) Servlet filter claims to support async but doesn't use AsyncContext
[ https://issues.apache.org/jira/browse/LOG4J2-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606181#comment-17606181 ] ASF subversion and git services commented on LOG4J2-708: Commit 432a851f0381a7bf9417a79ea9f9c64748b3020e in logging-log4j2's branch refs/heads/dependabot/maven/org.apache.felix-maven-bundle-plugin-5.1.8 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=432a851f03 ] [LOG4J2-708] Improve `Log4jServletFilter` async behavior The `Log4jServletFilter` filter should run on all the threads a request is run. The current version ignores all async dispatches. > Servlet filter claims to support async but doesn't use AsyncContext > --- > > Key: LOG4J2-708 > URL: https://issues.apache.org/jira/browse/LOG4J2-708 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.0-rc2 > Environment: Servlet 3.0 (Tomcat 7, Jetty 8) or higher >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Minor > Fix For: 2.19.1 > > > In log4j-web, when the ServletContainerInitializer adds the Log4j Filter, it > sets the asyncSupported property to true. However, it's still a synchronous > Filter. > A separate asynchronous Filter should be made for Servlet 3.x support that > doesn't break Servlet 2.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3564) NPE in JULLogger.getLevel()
[
https://issues.apache.org/jira/browse/LOG4J2-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17603458#comment-17603458
]
ASF subversion and git services commented on LOG4J2-3564:
-
Commit c07927c112e2fa622a4087d5283841dc77c82fbe in logging-log4j2's branch
refs/heads/release-2.x from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c07927c112 ]
[LOG4J2-3564] Missing changelog
> NPE in JULLogger.getLevel()
> ---
>
> Key: LOG4J2-3564
> URL: https://issues.apache.org/jira/browse/LOG4J2-3564
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-JUL
>Affects Versions: 2.17.2
>Reporter: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> {{JULLogger.getLevel()}} fails with a {{NullPointerException}} if the JUL
> root logger has a {{null}} level. This is a common situation in JDK 8+, since
> {{LogManager$RootLogger}} does not set the log level any more in its
> constructor.
> A practical example where it fails is Tomcat's {{ClassLoaderLogManager}}: cf.
> [BZ 66184|https://bz.apache.org/bugzilla/show_bug.cgi?id=66184].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-708) Servlet filter claims to support async but doesn't use AsyncContext
[ https://issues.apache.org/jira/browse/LOG4J2-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602908#comment-17602908 ] ASF subversion and git services commented on LOG4J2-708: Commit 432a851f0381a7bf9417a79ea9f9c64748b3020e in logging-log4j2's branch refs/heads/release-2.x from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=432a851f03 ] [LOG4J2-708] Improve `Log4jServletFilter` async behavior The `Log4jServletFilter` filter should run on all the threads a request is run. The current version ignores all async dispatches. > Servlet filter claims to support async but doesn't use AsyncContext > --- > > Key: LOG4J2-708 > URL: https://issues.apache.org/jira/browse/LOG4J2-708 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.0-rc2 > Environment: Servlet 3.0 (Tomcat 7, Jetty 8) or higher >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Minor > Fix For: 2.19.1 > > > In log4j-web, when the ServletContainerInitializer adds the Log4j Filter, it > sets the asyncSupported property to true. However, it's still a synchronous > Filter. > A separate asynchronous Filter should be made for Servlet 3.x support that > doesn't break Servlet 2.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3590) Remove SLF4J 1.8 binding
[
https://issues.apache.org/jira/browse/LOG4J2-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602518#comment-17602518
]
ASF subversion and git services commented on LOG4J2-3590:
-
Commit 9afd1f068258f0bb557bff8c12852c29ba79d8b0 in logging-log4j2's branch
refs/heads/dependabot/maven/io.fabric8-kubernetes-client-6.1.1 from Piotr P.
Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=9afd1f0682 ]
[LOG4J2-3590] Add release notes
> Remove SLF4J 1.8 binding
>
>
> Key: LOG4J2-3590
> URL: https://issues.apache.org/jira/browse/LOG4J2-3590
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Piotr Karwasz
>Priority: Major
> Fix For: 2.19.0
>
>
> The SLF4J 1.8.x series never produced a stable release.
> Since the introduction of SLF4J 2.x, the {{log4j-slf4j18-impl}} module should
> be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3545) Log4J-JCL should have the same OSGI configuration as Log4j-SLF4J18
[ https://issues.apache.org/jira/browse/LOG4J2-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602520#comment-17602520 ] ASF subversion and git services commented on LOG4J2-3545: - Commit 7e274cb062dfed5d94d7d54e1a7f3a27eab1d29b in logging-log4j2's branch refs/heads/dependabot/maven/io.fabric8-kubernetes-client-6.1.1 from Ralph Goers [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=7e274cb062 ] LOG4J2-3545 - Add correct manifest entries for OSGi to log4j-jcl > Log4J-JCL should have the same OSGI configuration as Log4j-SLF4J18 > -- > > Key: LOG4J2-3545 > URL: https://issues.apache.org/jira/browse/LOG4J2-3545 > Project: Log4j 2 > Issue Type: Improvement > Components: JCL Bridge >Affects Versions: 2.17.2 >Reporter: Johan Compagner >Assignee: Piotr Karwasz >Priority: Major > Fix For: 2.19.0 > > > if you look at the manifest in this jar: > [https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-jcl/2.17.2/log4j-jcl-2.17.2.jar] > compared to the one that is in here: > [https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-slf4j18-impl/2.17.2/log4j-slf4j18-impl-2.17.2.jar] > > then slf4j has the right OSGI manifest entries to work correctly with the > ServiceLoader > SLF4j has: > > Require-Capability: osgi.extender;filter:="(osgi.extender=osgi.service > loader.registrar)",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" > Provide-Capability: osgi.serviceloader;osgi.serviceloader="org.slf4j.s > pi.SLF4JServiceProvider" > > JCL has: > > Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" > > this should become to fully support it in an OSGi environment: > > Require-Capability: osgi.extender;filter:="(osgi.extender=osgi.servicelo > ader.registrar)",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" > Provide-Capability: > osgi.serviceloader;osgi.serviceloader="org.apache.commons.logging.LogFactory" > > to follow the spec: [133 Service Loader Mediator Specification - OSGi > Enterprise > 7|https://docs.osgi.org/specification/osgi.enterprise/7.0.0/service.loader.html] > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3589) Allow plugins to be injected with the LoggerContext
[ https://issues.apache.org/jira/browse/LOG4J2-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602523#comment-17602523 ] ASF subversion and git services commented on LOG4J2-3589: - Commit 5ffbbee76be9f7f701e835e0e99756f978ff7fbd in logging-log4j2's branch refs/heads/dependabot/maven/io.fabric8-kubernetes-client-6.1.1 from Ralph Goers [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5ffbbee76b ] LOG4J2-3589 - Avoid storing strong references to the LoggerContext > Allow plugins to be injected with the LoggerContext > --- > > Key: LOG4J2-3589 > URL: https://issues.apache.org/jira/browse/LOG4J2-3589 > Project: Log4j 2 > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.18.0 >Reporter: Ralph Goers >Priority: Major > Fix For: 2.19.0 > > > Log4j-Spring-Boot needs access to the LoggerContext. The way it is getting it > now is pretty kludgy. It would be better if the LoggerContext was injected > into the plugins. > Note: This should apply to only release-2.x as it is expected that the DI > system in 3.0 should handle this already. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3548) Password-less key stores fail to initialise StoreConfiguration
[
https://issues.apache.org/jira/browse/LOG4J2-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602521#comment-17602521
]
ASF subversion and git services commented on LOG4J2-3548:
-
Commit 60fe5d443770e788e02728d01487a69176c0fc45 in logging-log4j2's branch
refs/heads/dependabot/maven/io.fabric8-kubernetes-client-6.1.1 from Piotr P.
Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=60fe5d4437 ]
[[LOG4J2-3548] Improve support of `null` location and password
Adds support for a `null` location and password (as required by e.g. the
"Windows-MY" keystore).
> Password-less key stores fail to initialise StoreConfiguration
> --
>
> Key: LOG4J2-3548
> URL: https://issues.apache.org/jira/browse/LOG4J2-3548
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.18.0
>Reporter: Kristof Farkas-Pall
>Assignee: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> In LOG4J2-3439 there was a change in AbstractKeyStoreConfiguration that
> replaces null passwords with a default value. This means that when
> password-less key stores initialized, the integrity is checked with the
> default password ("changeit"), which of course fails.
> I think the replacement should be reverted, to allow for password-less key
> stores to be initalized correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3557) mule-3.3.1 with log4j-1.2-api-2.18.0 creates infinite recursion
[ https://issues.apache.org/jira/browse/LOG4J2-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602519#comment-17602519 ] ASF subversion and git services commented on LOG4J2-3557: - Commit 1a395bdc74ca8ced5bdc87c8656b090626c3f471 in logging-log4j2's branch refs/heads/dependabot/maven/io.fabric8-kubernetes-client-6.1.1 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=1a395bdc74 ] [LOG4J2-3557] Missing release note > mule-3.3.1 with log4j-1.2-api-2.18.0 creates infinite recursion > --- > > Key: LOG4J2-3557 > URL: https://issues.apache.org/jira/browse/LOG4J2-3557 > Project: Log4j 2 > Issue Type: Bug > Components: Log4j 1.2 bridge >Affects Versions: 2.18.0 >Reporter: Andreas Leitgeb >Assignee: Piotr Karwasz >Priority: Minor > Fix For: 2.19.0 > > > mule's class ApplicationAwareRepositorySelector has getLoggerRepository() > method, and within that it eventually tries to create a RootLogger. > In old log4j-1.2.16.jar this just created the RootLogger/Logger/Category > hierarchy without any attempt to obtain a LoggerRepository. I disassembled > the bytecode to check this. > in the bridge, the c'tor of Category calls LogManager.getLoggerRepository() > and that method ends up recursively calling mule's > ApplicationAwareRepositorySelector.getLoggerRepository() > ``` > at > org.apache.log4j.LogManager.getLoggerRepository(LogManager.java:171) > at org.apache.log4j.Category.(Category.java:177) > at org.apache.log4j.Category.(Category.java:192) > at org.apache.log4j.Logger.(Logger.java:57) > at org.apache.log4j.spi.RootLogger.(RootLogger.java:39) > at > org.mule.module.launcher.log4j.ApplicationAwareRepositorySelector.getLoggerRepository(ApplicationAwareRepositorySelector.java:62) > ``` > At this point I cannot yet tell, if this is a horrible wrong-doing of mule, > or just one of a number of horrible incompatibilities between the bridge and > the old real log4j. > I'm aware that mule-3.3.1 is helplessly out of lifetime, but that's what I > thought the bridge was meant for: to help upgrading SW that "cannot do > log4j2." -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-2507) Delete on Rollover must work for DirectWriteRolloverStrategy
[
https://issues.apache.org/jira/browse/LOG4J2-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602517#comment-17602517
]
ASF subversion and git services commented on LOG4J2-2507:
-
Commit d145ec8ba3f62d469aaeb6f48f5385d7fb8dde06 in logging-log4j2's branch
refs/heads/dependabot/maven/io.fabric8-kubernetes-client-6.1.1 from Ralph Goers
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=d145ec8ba3 ]
LOG4J2-2507 - Add unit test
> Delete on Rollover must work for DirectWriteRolloverStrategy
> -
>
> Key: LOG4J2-2507
> URL: https://issues.apache.org/jira/browse/LOG4J2-2507
> Project: Log4j 2
> Issue Type: Improvement
>Affects Versions: 2.11.1
>Reporter: lionel sauron
>Priority: Major
> Attachments: ScreenShot-132.png, ScreenShot-133.png
>
>
> Delete on Rollover is limited to DefaultRolloverStrategy
> Why not to add the same feature to the DirectWriteRolloverStrategy ?
>
> +Edit :+
> What i want :
> * For Each startup use a log file with the date in its name
> * For multiple startup the same day, append log in the same file
> * Keep only the last 10 log files
>
> If i use DefaultRolloverStrategy, i can keep the last 10 startup in separate
> file and use DeleteAction to limit the number of log file (for test i use 10,
> but in prod it's 100 = 10 days * 10 startup)
> => It's bad for me, because i can't have more than 10 startup per day logged.
> See the result in ScreenShot-132.png
> {noformat}
> filePattern = "${basePath}/robocopy-%d{MMdd}-%i.log">
>
>
>
>
>
>
>
>
>
>
>
> {noformat}
>
> If i use DirectWriteRolloverStrategy i can have 1 file per day.
> But DeleteAction is never run and i have too many file
> See the result in ScreenShot-133.png
>
> {noformat}
> "${basePath}/robocopy-%d{MMdd}.log">
>
>
>
>
>
>
>
>
>
>
>
> {noformat}
>
> Il i useTimeBasedTriggeringPolicy or CronTriggeringPolicy and
> DefaultRolloverStrategy then a run can be split into 2 file.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3548) Password-less key stores fail to initialise StoreConfiguration
[
https://issues.apache.org/jira/browse/LOG4J2-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602522#comment-17602522
]
ASF subversion and git services commented on LOG4J2-3548:
-
Commit 51f36fd6477ae9e255c11ce5e1bd68a56a20c234 in logging-log4j2's branch
refs/heads/dependabot/maven/io.fabric8-kubernetes-client-6.1.1 from Piotr P.
Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=51f36fd647 ]
[LOG4J2-3548] Add unity tests
Adds tests to prevent regressions.
> Password-less key stores fail to initialise StoreConfiguration
> --
>
> Key: LOG4J2-3548
> URL: https://issues.apache.org/jira/browse/LOG4J2-3548
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.18.0
>Reporter: Kristof Farkas-Pall
>Assignee: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> In LOG4J2-3439 there was a change in AbstractKeyStoreConfiguration that
> replaces null passwords with a default value. This means that when
> password-less key stores initialized, the integrity is checked with the
> default password ("changeit"), which of course fails.
> I think the replacement should be reverted, to allow for password-less key
> stores to be initalized correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3572) LoggerConfig could provide the information if level is explicitly set or inherited
[
https://issues.apache.org/jira/browse/LOG4J2-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602516#comment-17602516
]
ASF subversion and git services commented on LOG4J2-3572:
-
Commit e8fba8caf1ffab6dc0161f8f48611dadedb86b2c in logging-log4j2's branch
refs/heads/dependabot/maven/io.fabric8-kubernetes-client-6.1.1 from Ralph Goers
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=e8fba8caf1 ]
LOG4J2-3572 - Protect from null value
> LoggerConfig could provide the information if level is explicitly set or
> inherited
> --
>
> Key: LOG4J2-3572
> URL: https://issues.apache.org/jira/browse/LOG4J2-3572
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.18.0
>Reporter: Attila Varga
>Priority: Minor
> Fix For: 2.19.0
>
>
> When _org.apache.logging.log4j.core.config.LoggerConfig.level_ is set to
> _null_ the logging level is inherited from the parent:
> {code:java}
> public Level getLevel() {
> return level == null ? parent == null ? Level.ERROR : parent.getLevel() :
> level;
> }
> {code}
> It would be useful to know if level is explicitly set or inherited.
> Something like: {_}hasLevel(){_}, {_}isLevelSet(){_},
> {_}isLevelInherited(){_}, or something that fits into Log4j terminology.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3587) Cannot create Rfc5424Layout without enterpriseNumber after upgrading to 2.18.0
[
https://issues.apache.org/jira/browse/LOG4J2-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602515#comment-17602515
]
ASF subversion and git services commented on LOG4J2-3587:
-
Commit 1470d504b490ef2248c4a6efc9817b076e88e4a7 in logging-log4j2's branch
refs/heads/dependabot/maven/io.fabric8-kubernetes-client-6.1.1 from Piotr P.
Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=1470d504b4 ]
[LOG4J2-3587] Add default enterprise ID value
Adds the correct default values on both the factory method and builder class
and a test case to prevent regressions.
> Cannot create Rfc5424Layout without enterpriseNumber after upgrading to 2.18.0
> --
>
> Key: LOG4J2-3587
> URL: https://issues.apache.org/jira/browse/LOG4J2-3587
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.18.0
>Reporter: Tomas Micko
>Assignee: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> Hello,
> I get an exception when using {{Rfc5424Layout}} after upgrading to 2.18.0
> (but it works in 2.17.2). Using this configuration:
> {code:java}
>
>
>
>
>
>
> {code}
> I get this when starting my application:
> {code:java}
> java.lang.IllegalArgumentException: No enterprise number was supplied
> at
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:169)
> at
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:132)
> at
> org.apache.logging.log4j.core.layout.Rfc5424Layout.(Rfc5424Layout.java:149)
> at
> org.apache.logging.log4j.core.layout.Rfc5424Layout.createLayout(Rfc5424Layout.java:643)
> {code}
> I need to specify an enterpriseNumber for Rfc5424Layout like this to make it
> work:
> {code:java}
>
>
>
>
>
>
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3589) Allow plugins to be injected with the LoggerContext
[ https://issues.apache.org/jira/browse/LOG4J2-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602094#comment-17602094 ] ASF subversion and git services commented on LOG4J2-3589: - Commit 70de14fcc1dfb74173846bf93e8c90a0bb275fc7 in logging-log4j2's branch refs/heads/master from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=70de14fcc1 ] LOG4J2-3589 - Avoid storing strong references to the LoggerContext > Allow plugins to be injected with the LoggerContext > --- > > Key: LOG4J2-3589 > URL: https://issues.apache.org/jira/browse/LOG4J2-3589 > Project: Log4j 2 > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.18.0 >Reporter: Ralph Goers >Priority: Major > Fix For: 2.19.0 > > > Log4j-Spring-Boot needs access to the LoggerContext. The way it is getting it > now is pretty kludgy. It would be better if the LoggerContext was injected > into the plugins. > Note: This should apply to only release-2.x as it is expected that the DI > system in 3.0 should handle this already. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3589) Allow plugins to be injected with the LoggerContext
[ https://issues.apache.org/jira/browse/LOG4J2-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602093#comment-17602093 ] ASF subversion and git services commented on LOG4J2-3589: - Commit 5ffbbee76be9f7f701e835e0e99756f978ff7fbd in logging-log4j2's branch refs/heads/release-2.x from Ralph Goers [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5ffbbee76b ] LOG4J2-3589 - Avoid storing strong references to the LoggerContext > Allow plugins to be injected with the LoggerContext > --- > > Key: LOG4J2-3589 > URL: https://issues.apache.org/jira/browse/LOG4J2-3589 > Project: Log4j 2 > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.18.0 >Reporter: Ralph Goers >Priority: Major > Fix For: 2.19.0 > > > Log4j-Spring-Boot needs access to the LoggerContext. The way it is getting it > now is pretty kludgy. It would be better if the LoggerContext was injected > into the plugins. > Note: This should apply to only release-2.x as it is expected that the DI > system in 3.0 should handle this already. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3548) Password-less key stores fail to initialise StoreConfiguration
[
https://issues.apache.org/jira/browse/LOG4J2-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601863#comment-17601863
]
ASF subversion and git services commented on LOG4J2-3548:
-
Commit 51f36fd6477ae9e255c11ce5e1bd68a56a20c234 in logging-log4j2's branch
refs/heads/release-2.x from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=51f36fd647 ]
[LOG4J2-3548] Add unity tests
Adds tests to prevent regressions.
> Password-less key stores fail to initialise StoreConfiguration
> --
>
> Key: LOG4J2-3548
> URL: https://issues.apache.org/jira/browse/LOG4J2-3548
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.18.0
>Reporter: Kristof Farkas-Pall
>Assignee: Piotr Karwasz
>Priority: Major
>
> In LOG4J2-3439 there was a change in AbstractKeyStoreConfiguration that
> replaces null passwords with a default value. This means that when
> password-less key stores initialized, the integrity is checked with the
> default password ("changeit"), which of course fails.
> I think the replacement should be reverted, to allow for password-less key
> stores to be initalized correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3548) Password-less key stores fail to initialise StoreConfiguration
[
https://issues.apache.org/jira/browse/LOG4J2-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601862#comment-17601862
]
ASF subversion and git services commented on LOG4J2-3548:
-
Commit 60fe5d443770e788e02728d01487a69176c0fc45 in logging-log4j2's branch
refs/heads/release-2.x from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=60fe5d4437 ]
[[LOG4J2-3548] Improve support of `null` location and password
Adds support for a `null` location and password (as required by e.g. the
"Windows-MY" keystore).
> Password-less key stores fail to initialise StoreConfiguration
> --
>
> Key: LOG4J2-3548
> URL: https://issues.apache.org/jira/browse/LOG4J2-3548
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.18.0
>Reporter: Kristof Farkas-Pall
>Assignee: Piotr Karwasz
>Priority: Major
>
> In LOG4J2-3439 there was a change in AbstractKeyStoreConfiguration that
> replaces null passwords with a default value. This means that when
> password-less key stores initialized, the integrity is checked with the
> default password ("changeit"), which of course fails.
> I think the replacement should be reverted, to allow for password-less key
> stores to be initalized correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3545) Log4J-JCL should have the same OSGI configuration as Log4j-SLF4J18
[ https://issues.apache.org/jira/browse/LOG4J2-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601596#comment-17601596 ] ASF subversion and git services commented on LOG4J2-3545: - Commit 43fcdd9a9c2f458dd61c12551ec66d631113391b in logging-log4j2's branch refs/heads/master from Ralph Goers [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=43fcdd9a9c ] LOG4J2-3545 - Add correct manifest entries for OSGi to log4j-jcl > Log4J-JCL should have the same OSGI configuration as Log4j-SLF4J18 > -- > > Key: LOG4J2-3545 > URL: https://issues.apache.org/jira/browse/LOG4J2-3545 > Project: Log4j 2 > Issue Type: Improvement > Components: JCL Bridge >Affects Versions: 2.17.2 >Reporter: Johan Compagner >Assignee: Piotr Karwasz >Priority: Major > > if you look at the manifest in this jar: > [https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-jcl/2.17.2/log4j-jcl-2.17.2.jar] > compared to the one that is in here: > [https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-slf4j18-impl/2.17.2/log4j-slf4j18-impl-2.17.2.jar] > > then slf4j has the right OSGI manifest entries to work correctly with the > ServiceLoader > SLF4j has: > > Require-Capability: osgi.extender;filter:="(osgi.extender=osgi.service > loader.registrar)",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" > Provide-Capability: osgi.serviceloader;osgi.serviceloader="org.slf4j.s > pi.SLF4JServiceProvider" > > JCL has: > > Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" > > this should become to fully support it in an OSGi environment: > > Require-Capability: osgi.extender;filter:="(osgi.extender=osgi.servicelo > ader.registrar)",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" > Provide-Capability: > osgi.serviceloader;osgi.serviceloader="org.apache.commons.logging.LogFactory" > > to follow the spec: [133 Service Loader Mediator Specification - OSGi > Enterprise > 7|https://docs.osgi.org/specification/osgi.enterprise/7.0.0/service.loader.html] > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3545) Log4J-JCL should have the same OSGI configuration as Log4j-SLF4J18
[ https://issues.apache.org/jira/browse/LOG4J2-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601548#comment-17601548 ] ASF subversion and git services commented on LOG4J2-3545: - Commit 7e274cb062dfed5d94d7d54e1a7f3a27eab1d29b in logging-log4j2's branch refs/heads/release-2.x from Ralph Goers [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=7e274cb062 ] LOG4J2-3545 - Add correct manifest entries for OSGi to log4j-jcl > Log4J-JCL should have the same OSGI configuration as Log4j-SLF4J18 > -- > > Key: LOG4J2-3545 > URL: https://issues.apache.org/jira/browse/LOG4J2-3545 > Project: Log4j 2 > Issue Type: Improvement > Components: JCL Bridge >Affects Versions: 2.17.2 >Reporter: Johan Compagner >Assignee: Piotr Karwasz >Priority: Major > > if you look at the manifest in this jar: > [https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-jcl/2.17.2/log4j-jcl-2.17.2.jar] > compared to the one that is in here: > [https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-slf4j18-impl/2.17.2/log4j-slf4j18-impl-2.17.2.jar] > > then slf4j has the right OSGI manifest entries to work correctly with the > ServiceLoader > SLF4j has: > > Require-Capability: osgi.extender;filter:="(osgi.extender=osgi.service > loader.registrar)",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" > Provide-Capability: osgi.serviceloader;osgi.serviceloader="org.slf4j.s > pi.SLF4JServiceProvider" > > JCL has: > > Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" > > this should become to fully support it in an OSGi environment: > > Require-Capability: osgi.extender;filter:="(osgi.extender=osgi.servicelo > ader.registrar)",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" > Provide-Capability: > osgi.serviceloader;osgi.serviceloader="org.apache.commons.logging.LogFactory" > > to follow the spec: [133 Service Loader Mediator Specification - OSGi > Enterprise > 7|https://docs.osgi.org/specification/osgi.enterprise/7.0.0/service.loader.html] > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3557) mule-3.3.1 with log4j-1.2-api-2.18.0 creates infinite recursion
[ https://issues.apache.org/jira/browse/LOG4J2-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601466#comment-17601466 ] ASF subversion and git services commented on LOG4J2-3557: - Commit 1a395bdc74ca8ced5bdc87c8656b090626c3f471 in logging-log4j2's branch refs/heads/release-2.x from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=1a395bdc74 ] [LOG4J2-3557] Missing release note > mule-3.3.1 with log4j-1.2-api-2.18.0 creates infinite recursion > --- > > Key: LOG4J2-3557 > URL: https://issues.apache.org/jira/browse/LOG4J2-3557 > Project: Log4j 2 > Issue Type: Bug > Components: Log4j 1.2 bridge >Affects Versions: 2.18.0 >Reporter: Andreas Leitgeb >Assignee: Piotr Karwasz >Priority: Minor > Fix For: 2.19.0 > > > mule's class ApplicationAwareRepositorySelector has getLoggerRepository() > method, and within that it eventually tries to create a RootLogger. > In old log4j-1.2.16.jar this just created the RootLogger/Logger/Category > hierarchy without any attempt to obtain a LoggerRepository. I disassembled > the bytecode to check this. > in the bridge, the c'tor of Category calls LogManager.getLoggerRepository() > and that method ends up recursively calling mule's > ApplicationAwareRepositorySelector.getLoggerRepository() > ``` > at > org.apache.log4j.LogManager.getLoggerRepository(LogManager.java:171) > at org.apache.log4j.Category.(Category.java:177) > at org.apache.log4j.Category.(Category.java:192) > at org.apache.log4j.Logger.(Logger.java:57) > at org.apache.log4j.spi.RootLogger.(RootLogger.java:39) > at > org.mule.module.launcher.log4j.ApplicationAwareRepositorySelector.getLoggerRepository(ApplicationAwareRepositorySelector.java:62) > ``` > At this point I cannot yet tell, if this is a horrible wrong-doing of mule, > or just one of a number of horrible incompatibilities between the bridge and > the old real log4j. > I'm aware that mule-3.3.1 is helplessly out of lifetime, but that's what I > thought the bridge was meant for: to help upgrading SW that "cannot do > log4j2." -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-2507) Delete on Rollover must work for DirectWriteRolloverStrategy
[
https://issues.apache.org/jira/browse/LOG4J2-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601460#comment-17601460
]
ASF subversion and git services commented on LOG4J2-2507:
-
Commit d145ec8ba3f62d469aaeb6f48f5385d7fb8dde06 in logging-log4j2's branch
refs/heads/remove-slf4j-18 from Ralph Goers
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=d145ec8ba3 ]
LOG4J2-2507 - Add unit test
> Delete on Rollover must work for DirectWriteRolloverStrategy
> -
>
> Key: LOG4J2-2507
> URL: https://issues.apache.org/jira/browse/LOG4J2-2507
> Project: Log4j 2
> Issue Type: Improvement
>Affects Versions: 2.11.1
>Reporter: lionel sauron
>Priority: Major
> Attachments: ScreenShot-132.png, ScreenShot-133.png
>
>
> Delete on Rollover is limited to DefaultRolloverStrategy
> Why not to add the same feature to the DirectWriteRolloverStrategy ?
>
> +Edit :+
> What i want :
> * For Each startup use a log file with the date in its name
> * For multiple startup the same day, append log in the same file
> * Keep only the last 10 log files
>
> If i use DefaultRolloverStrategy, i can keep the last 10 startup in separate
> file and use DeleteAction to limit the number of log file (for test i use 10,
> but in prod it's 100 = 10 days * 10 startup)
> => It's bad for me, because i can't have more than 10 startup per day logged.
> See the result in ScreenShot-132.png
> {noformat}
> filePattern = "${basePath}/robocopy-%d{MMdd}-%i.log">
>
>
>
>
>
>
>
>
>
>
>
> {noformat}
>
> If i use DirectWriteRolloverStrategy i can have 1 file per day.
> But DeleteAction is never run and i have too many file
> See the result in ScreenShot-133.png
>
> {noformat}
> "${basePath}/robocopy-%d{MMdd}.log">
>
>
>
>
>
>
>
>
>
>
>
> {noformat}
>
> Il i useTimeBasedTriggeringPolicy or CronTriggeringPolicy and
> DefaultRolloverStrategy then a run can be split into 2 file.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3572) LoggerConfig could provide the information if level is explicitly set or inherited
[
https://issues.apache.org/jira/browse/LOG4J2-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601459#comment-17601459
]
ASF subversion and git services commented on LOG4J2-3572:
-
Commit e8fba8caf1ffab6dc0161f8f48611dadedb86b2c in logging-log4j2's branch
refs/heads/remove-slf4j-18 from Ralph Goers
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=e8fba8caf1 ]
LOG4J2-3572 - Protect from null value
> LoggerConfig could provide the information if level is explicitly set or
> inherited
> --
>
> Key: LOG4J2-3572
> URL: https://issues.apache.org/jira/browse/LOG4J2-3572
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.18.0
>Reporter: Attila Varga
>Priority: Minor
> Fix For: 2.19.0
>
>
> When _org.apache.logging.log4j.core.config.LoggerConfig.level_ is set to
> _null_ the logging level is inherited from the parent:
> {code:java}
> public Level getLevel() {
> return level == null ? parent == null ? Level.ERROR : parent.getLevel() :
> level;
> }
> {code}
> It would be useful to know if level is explicitly set or inherited.
> Something like: {_}hasLevel(){_}, {_}isLevelSet(){_},
> {_}isLevelInherited(){_}, or something that fits into Log4j terminology.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3590) Remove SLF4J 1.8 binding
[
https://issues.apache.org/jira/browse/LOG4J2-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601461#comment-17601461
]
ASF subversion and git services commented on LOG4J2-3590:
-
Commit 9afd1f068258f0bb557bff8c12852c29ba79d8b0 in logging-log4j2's branch
refs/heads/remove-slf4j-18 from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=9afd1f0682 ]
[LOG4J2-3590] Add release notes
> Remove SLF4J 1.8 binding
>
>
> Key: LOG4J2-3590
> URL: https://issues.apache.org/jira/browse/LOG4J2-3590
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Piotr Karwasz
>Priority: Major
>
> The SLF4J 1.8.x series never produced a stable release.
> Since the introduction of SLF4J 2.x, the {{log4j-slf4j18-impl}} module should
> be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3590) Remove SLF4J 1.8 binding
[
https://issues.apache.org/jira/browse/LOG4J2-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601462#comment-17601462
]
ASF subversion and git services commented on LOG4J2-3590:
-
Commit 9afd1f068258f0bb557bff8c12852c29ba79d8b0 in logging-log4j2's branch
refs/heads/release-2.x from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=9afd1f0682 ]
[LOG4J2-3590] Add release notes
> Remove SLF4J 1.8 binding
>
>
> Key: LOG4J2-3590
> URL: https://issues.apache.org/jira/browse/LOG4J2-3590
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Piotr Karwasz
>Priority: Major
>
> The SLF4J 1.8.x series never produced a stable release.
> Since the introduction of SLF4J 2.x, the {{log4j-slf4j18-impl}} module should
> be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3572) LoggerConfig could provide the information if level is explicitly set or inherited
[
https://issues.apache.org/jira/browse/LOG4J2-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601457#comment-17601457
]
ASF subversion and git services commented on LOG4J2-3572:
-
Commit 5629ece4e8bf0f3816dd86f0705588a6c15150f6 in logging-log4j2's branch
refs/heads/remove-slf4j-18 from Ralph Goers
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5629ece4e8 ]
LOG4J2-3572 - Add getExplicitLevel to LoggerConfig
> LoggerConfig could provide the information if level is explicitly set or
> inherited
> --
>
> Key: LOG4J2-3572
> URL: https://issues.apache.org/jira/browse/LOG4J2-3572
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.18.0
>Reporter: Attila Varga
>Priority: Minor
> Fix For: 2.19.0
>
>
> When _org.apache.logging.log4j.core.config.LoggerConfig.level_ is set to
> _null_ the logging level is inherited from the parent:
> {code:java}
> public Level getLevel() {
> return level == null ? parent == null ? Level.ERROR : parent.getLevel() :
> level;
> }
> {code}
> It would be useful to know if level is explicitly set or inherited.
> Something like: {_}hasLevel(){_}, {_}isLevelSet(){_},
> {_}isLevelInherited(){_}, or something that fits into Log4j terminology.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3587) Cannot create Rfc5424Layout without enterpriseNumber after upgrading to 2.18.0
[
https://issues.apache.org/jira/browse/LOG4J2-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601458#comment-17601458
]
ASF subversion and git services commented on LOG4J2-3587:
-
Commit 1470d504b490ef2248c4a6efc9817b076e88e4a7 in logging-log4j2's branch
refs/heads/remove-slf4j-18 from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=1470d504b4 ]
[LOG4J2-3587] Add default enterprise ID value
Adds the correct default values on both the factory method and builder class
and a test case to prevent regressions.
> Cannot create Rfc5424Layout without enterpriseNumber after upgrading to 2.18.0
> --
>
> Key: LOG4J2-3587
> URL: https://issues.apache.org/jira/browse/LOG4J2-3587
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.18.0
>Reporter: Tomas Micko
>Assignee: Piotr Karwasz
>Priority: Minor
>
> Hello,
> I get an exception when using {{Rfc5424Layout}} after upgrading to 2.18.0
> (but it works in 2.17.2). Using this configuration:
> {code:java}
>
>
>
>
>
>
> {code}
> I get this when starting my application:
> {code:java}
> java.lang.IllegalArgumentException: No enterprise number was supplied
> at
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:169)
> at
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:132)
> at
> org.apache.logging.log4j.core.layout.Rfc5424Layout.(Rfc5424Layout.java:149)
> at
> org.apache.logging.log4j.core.layout.Rfc5424Layout.createLayout(Rfc5424Layout.java:643)
> {code}
> I need to specify an enterpriseNumber for Rfc5424Layout like this to make it
> work:
> {code:java}
>
>
>
>
>
>
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-2507) Delete on Rollover must work for DirectWriteRolloverStrategy
[
https://issues.apache.org/jira/browse/LOG4J2-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601371#comment-17601371
]
ASF subversion and git services commented on LOG4J2-2507:
-
Commit d145ec8ba3f62d469aaeb6f48f5385d7fb8dde06 in logging-log4j2's branch
refs/heads/release-2.x from Ralph Goers
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=d145ec8ba3 ]
LOG4J2-2507 - Add unit test
> Delete on Rollover must work for DirectWriteRolloverStrategy
> -
>
> Key: LOG4J2-2507
> URL: https://issues.apache.org/jira/browse/LOG4J2-2507
> Project: Log4j 2
> Issue Type: Improvement
>Affects Versions: 2.11.1
>Reporter: lionel sauron
>Priority: Major
> Attachments: ScreenShot-132.png, ScreenShot-133.png
>
>
> Delete on Rollover is limited to DefaultRolloverStrategy
> Why not to add the same feature to the DirectWriteRolloverStrategy ?
>
> +Edit :+
> What i want :
> * For Each startup use a log file with the date in its name
> * For multiple startup the same day, append log in the same file
> * Keep only the last 10 log files
>
> If i use DefaultRolloverStrategy, i can keep the last 10 startup in separate
> file and use DeleteAction to limit the number of log file (for test i use 10,
> but in prod it's 100 = 10 days * 10 startup)
> => It's bad for me, because i can't have more than 10 startup per day logged.
> See the result in ScreenShot-132.png
> {noformat}
> filePattern = "${basePath}/robocopy-%d{MMdd}-%i.log">
>
>
>
>
>
>
>
>
>
>
>
> {noformat}
>
> If i use DirectWriteRolloverStrategy i can have 1 file per day.
> But DeleteAction is never run and i have too many file
> See the result in ScreenShot-133.png
>
> {noformat}
> "${basePath}/robocopy-%d{MMdd}.log">
>
>
>
>
>
>
>
>
>
>
>
> {noformat}
>
> Il i useTimeBasedTriggeringPolicy or CronTriggeringPolicy and
> DefaultRolloverStrategy then a run can be split into 2 file.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3572) LoggerConfig could provide the information if level is explicitly set or inherited
[
https://issues.apache.org/jira/browse/LOG4J2-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601370#comment-17601370
]
ASF subversion and git services commented on LOG4J2-3572:
-
Commit e8fba8caf1ffab6dc0161f8f48611dadedb86b2c in logging-log4j2's branch
refs/heads/release-2.x from Ralph Goers
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=e8fba8caf1 ]
LOG4J2-3572 - Protect from null value
> LoggerConfig could provide the information if level is explicitly set or
> inherited
> --
>
> Key: LOG4J2-3572
> URL: https://issues.apache.org/jira/browse/LOG4J2-3572
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.18.0
>Reporter: Attila Varga
>Priority: Minor
> Fix For: 2.19.0
>
>
> When _org.apache.logging.log4j.core.config.LoggerConfig.level_ is set to
> _null_ the logging level is inherited from the parent:
> {code:java}
> public Level getLevel() {
> return level == null ? parent == null ? Level.ERROR : parent.getLevel() :
> level;
> }
> {code}
> It would be useful to know if level is explicitly set or inherited.
> Something like: {_}hasLevel(){_}, {_}isLevelSet(){_},
> {_}isLevelInherited(){_}, or something that fits into Log4j terminology.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3587) Cannot create Rfc5424Layout without enterpriseNumber after upgrading to 2.18.0
[
https://issues.apache.org/jira/browse/LOG4J2-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601231#comment-17601231
]
ASF subversion and git services commented on LOG4J2-3587:
-
Commit 1470d504b490ef2248c4a6efc9817b076e88e4a7 in logging-log4j2's branch
refs/heads/release-2.x from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=1470d504b4 ]
[LOG4J2-3587] Add default enterprise ID value
Adds the correct default values on both the factory method and builder class
and a test case to prevent regressions.
> Cannot create Rfc5424Layout without enterpriseNumber after upgrading to 2.18.0
> --
>
> Key: LOG4J2-3587
> URL: https://issues.apache.org/jira/browse/LOG4J2-3587
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.18.0
>Reporter: Tomas Micko
>Assignee: Piotr Karwasz
>Priority: Minor
>
> Hello,
> I get an exception when using {{Rfc5424Layout}} after upgrading to 2.18.0
> (but it works in 2.17.2). Using this configuration:
> {code:java}
>
>
>
>
>
>
> {code}
> I get this when starting my application:
> {code:java}
> java.lang.IllegalArgumentException: No enterprise number was supplied
> at
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:169)
> at
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:132)
> at
> org.apache.logging.log4j.core.layout.Rfc5424Layout.(Rfc5424Layout.java:149)
> at
> org.apache.logging.log4j.core.layout.Rfc5424Layout.createLayout(Rfc5424Layout.java:643)
> {code}
> I need to specify an enterpriseNumber for Rfc5424Layout like this to make it
> work:
> {code:java}
>
>
>
>
>
>
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3572) LoggerConfig could provide the information if level is explicitly set or inherited
[
https://issues.apache.org/jira/browse/LOG4J2-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601125#comment-17601125
]
ASF subversion and git services commented on LOG4J2-3572:
-
Commit 5629ece4e8bf0f3816dd86f0705588a6c15150f6 in logging-log4j2's branch
refs/heads/release-2.x from Ralph Goers
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5629ece4e8 ]
LOG4J2-3572 - Add getExplicitLevel to LoggerConfig
> LoggerConfig could provide the information if level is explicitly set or
> inherited
> --
>
> Key: LOG4J2-3572
> URL: https://issues.apache.org/jira/browse/LOG4J2-3572
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.18.0
>Reporter: Attila Varga
>Priority: Minor
>
> When _org.apache.logging.log4j.core.config.LoggerConfig.level_ is set to
> _null_ the logging level is inherited from the parent:
> {code:java}
> public Level getLevel() {
> return level == null ? parent == null ? Level.ERROR : parent.getLevel() :
> level;
> }
> {code}
> It would be useful to know if level is explicitly set or inherited.
> Something like: {_}hasLevel(){_}, {_}isLevelSet(){_},
> {_}isLevelInherited(){_}, or something that fits into Log4j terminology.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3572) LoggerConfig could provide the information if level is explicitly set or inherited
[
https://issues.apache.org/jira/browse/LOG4J2-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601126#comment-17601126
]
ASF subversion and git services commented on LOG4J2-3572:
-
Commit 0218b1bc4fca14a54c2db0676d42ba701aab1d51 in logging-log4j2's branch
refs/heads/master from Ralph Goers
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=0218b1bc4f ]
LOG4J2-3572 - Add getExlicitLevel method to LoggerConfig
> LoggerConfig could provide the information if level is explicitly set or
> inherited
> --
>
> Key: LOG4J2-3572
> URL: https://issues.apache.org/jira/browse/LOG4J2-3572
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.18.0
>Reporter: Attila Varga
>Priority: Minor
>
> When _org.apache.logging.log4j.core.config.LoggerConfig.level_ is set to
> _null_ the logging level is inherited from the parent:
> {code:java}
> public Level getLevel() {
> return level == null ? parent == null ? Level.ERROR : parent.getLevel() :
> level;
> }
> {code}
> It would be useful to know if level is explicitly set or inherited.
> Something like: {_}hasLevel(){_}, {_}isLevelSet(){_},
> {_}isLevelInherited(){_}, or something that fits into Log4j terminology.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3589) Allow plugins to be injected with the LoggerContext
[ https://issues.apache.org/jira/browse/LOG4J2-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600993#comment-17600993 ] ASF subversion and git services commented on LOG4J2-3589: - Commit 84a0f4e1379a7536a0496de8885b68109ae1cd8c in logging-log4j2's branch refs/heads/remove-slf4j-18 from Ralph Goers [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=84a0f4e137 ] LOG4J2-3589 - Allow Plugins to be injected with the LoggerContext reference > Allow plugins to be injected with the LoggerContext > --- > > Key: LOG4J2-3589 > URL: https://issues.apache.org/jira/browse/LOG4J2-3589 > Project: Log4j 2 > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.18.0 >Reporter: Ralph Goers >Priority: Major > Fix For: 2.19.0 > > > Log4j-Spring-Boot needs access to the LoggerContext. The way it is getting it > now is pretty kludgy. It would be better if the LoggerContext was injected > into the plugins. > Note: This should apply to only release-2.x as it is expected that the DI > system in 3.0 should handle this already. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3588) Allow property sources to be registered after PropertiesUtil is initialized
[ https://issues.apache.org/jira/browse/LOG4J2-3588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600992#comment-17600992 ] ASF subversion and git services commented on LOG4J2-3588: - Commit 53b01c88809ced74fe6d0012b98510f4c42e6eb3 in logging-log4j2's branch refs/heads/remove-slf4j-18 from Ralph Goers [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=53b01c8880 ] LOG4J2-3588 - Allow a PropertySource to be added > Allow property sources to be registered after PropertiesUtil is initialized > --- > > Key: LOG4J2-3588 > URL: https://issues.apache.org/jira/browse/LOG4J2-3588 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.18.0 >Reporter: Ralph Goers >Assignee: Ralph Goers >Priority: Major > Fix For: 2.19.0 > > > PropertiesUtil loads all PropertySources at startup without any parameters. > Spring Boot needs to pass the Environment to the PropertySource but the > PropertySource is created before Spring Boot has initialized. This change > would allow the Spring Boot PropertySource to be registered manually during > Spring Boot initialization. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3589) Allow plugins to be injected with the LoggerContext
[ https://issues.apache.org/jira/browse/LOG4J2-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600965#comment-17600965 ] ASF subversion and git services commented on LOG4J2-3589: - Commit 84a0f4e1379a7536a0496de8885b68109ae1cd8c in logging-log4j2's branch refs/heads/release-2.x from Ralph Goers [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=84a0f4e137 ] LOG4J2-3589 - Allow Plugins to be injected with the LoggerContext reference > Allow plugins to be injected with the LoggerContext > --- > > Key: LOG4J2-3589 > URL: https://issues.apache.org/jira/browse/LOG4J2-3589 > Project: Log4j 2 > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.18.0 >Reporter: Ralph Goers >Priority: Major > > Log4j-Spring-Boot needs access to the LoggerContext. The way it is getting it > now is pretty kludgy. It would be better if the LoggerContext was injected > into the plugins. > Note: This should apply to only release-2.x as it is expected that the DI > system in 3.0 should handle this already. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3588) Allow property sources to be registered after PropertiesUtil is initialized
[ https://issues.apache.org/jira/browse/LOG4J2-3588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600964#comment-17600964 ] ASF subversion and git services commented on LOG4J2-3588: - Commit 53b01c88809ced74fe6d0012b98510f4c42e6eb3 in logging-log4j2's branch refs/heads/release-2.x from Ralph Goers [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=53b01c8880 ] LOG4J2-3588 - Allow a PropertySource to be added > Allow property sources to be registered after PropertiesUtil is initialized > --- > > Key: LOG4J2-3588 > URL: https://issues.apache.org/jira/browse/LOG4J2-3588 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.18.0 >Reporter: Ralph Goers >Assignee: Ralph Goers >Priority: Major > > PropertiesUtil loads all PropertySources at startup without any parameters. > Spring Boot needs to pass the Environment to the PropertySource but the > PropertySource is created before Spring Boot has initialized. This change > would allow the Spring Boot PropertySource to be registered manually during > Spring Boot initialization. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3589) Allow plugins to be injected with the LoggerContext
[ https://issues.apache.org/jira/browse/LOG4J2-3589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600956#comment-17600956 ] ASF subversion and git services commented on LOG4J2-3589: - Commit bb0c70ec1afe867a52efee873fabb3197dabeae8 in logging-log4j2's branch refs/heads/master from Ralph Goers [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=bb0c70ec1a ] LOG4J2-3589 - Allow Plugins to be injected with the LoggerContext reference > Allow plugins to be injected with the LoggerContext > --- > > Key: LOG4J2-3589 > URL: https://issues.apache.org/jira/browse/LOG4J2-3589 > Project: Log4j 2 > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.18.0 >Reporter: Ralph Goers >Priority: Major > > Log4j-Spring-Boot needs access to the LoggerContext. The way it is getting it > now is pretty kludgy. It would be better if the LoggerContext was injected > into the plugins. > Note: This should apply to only release-2.x as it is expected that the DI > system in 3.0 should handle this already. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3588) Allow property sources to be registered after PropertiesUtil is initialized
[ https://issues.apache.org/jira/browse/LOG4J2-3588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600955#comment-17600955 ] ASF subversion and git services commented on LOG4J2-3588: - Commit 383f64afc8eb9ba55425cd314792ecc9251e3046 in logging-log4j2's branch refs/heads/master from Ralph Goers [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=383f64afc8 ] LOG4J2-3588 - Allow a PropertySource to be added > Allow property sources to be registered after PropertiesUtil is initialized > --- > > Key: LOG4J2-3588 > URL: https://issues.apache.org/jira/browse/LOG4J2-3588 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.18.0 >Reporter: Ralph Goers >Assignee: Ralph Goers >Priority: Major > > PropertiesUtil loads all PropertySources at startup without any parameters. > Spring Boot needs to pass the Environment to the PropertySource but the > PropertySource is created before Spring Boot has initialized. This change > would allow the Spring Boot PropertySource to be registered manually during > Spring Boot initialization. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-2975) SLF4J fluent API fails to capture call site location due to missing LoggingEventAware implementation
[ https://issues.apache.org/jira/browse/LOG4J2-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600922#comment-17600922 ] ASF subversion and git services commented on LOG4J2-2975: - Commit f64c96b591af46e09f7ebebb76d6ba13823fdd44 in logging-log4j2's branch refs/heads/dependabot/maven/org.junit-pioneer-junit-pioneer-1.7.1 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=f64c96b591 ] [LOG4J2-2975] Add release notes > SLF4J fluent API fails to capture call site location due to missing > LoggingEventAware implementation > > > Key: LOG4J2-2975 > URL: https://issues.apache.org/jira/browse/LOG4J2-2975 > Project: Log4j 2 > Issue Type: New Feature > Components: SLF4J Bridge >Affects Versions: 2.13.3 >Reporter: Daniel Gray >Assignee: Piotr Karwasz >Priority: Major > Fix For: 2.19.0 > > > The logger outputs the wrong log line (120 for INFO, 117 for DEBUG, etc.) > instead of the line in the program that generated the log, when running with > the slf4j bridge. *This causes potential confusion when a person debugging > something is reading the logs as the line numbers are wrong!* > I have prepared 2 simple CLI apps to show the correct behavior (with only > Log4J) and the incorrect behavior (with the SLF4J bridge). Both are using the > exact same configuration (log4j2.properties). The repositories of these > sample projects are: > Good behavior with a pure log4j: > [https://github.com/danielthegray/log4j-nobugsample] > Wrong behavior with the slf4j bridge: > [https://github.com/danielthegray/slf4j-bugsample] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3583) Implement stack-valued MDC
[ https://issues.apache.org/jira/browse/LOG4J2-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600920#comment-17600920 ] ASF subversion and git services commented on LOG4J2-3583: - Commit 36cf6420bb96aa53ee261db460ef3c9faa978814 in logging-log4j2's branch refs/heads/dependabot/maven/org.junit-pioneer-junit-pioneer-1.7.1 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=36cf6420bb ] [LOG4J2-3583] Add tests from #1022 and release notes > Implement stack-valued MDC > -- > > Key: LOG4J2-3583 > URL: https://issues.apache.org/jira/browse/LOG4J2-3583 > Project: Log4j 2 > Issue Type: New Feature > Components: SLF4J Bridge >Reporter: Piotr Karwasz >Assignee: Piotr Karwasz >Priority: Minor > Fix For: 2.19.0 > > > SLF4J 2.0 introduces a stack-valued MDC (cf. > [SLF4J-531|https://jira.qos.ch/browse/SLF4J-531])), which must be implemented > in the SLF4J to Log4j2 bridge. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3559) Incorrect normalization of properties not starting with 'log4j'
[
https://issues.apache.org/jira/browse/LOG4J2-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600916#comment-17600916
]
ASF subversion and git services commented on LOG4J2-3559:
-
Commit a470bf2860f6c45b1474ff78ee67153d7de4a120 in logging-log4j2's branch
refs/heads/dependabot/maven/org.junit-pioneer-junit-pioneer-1.7.1 from Piotr P.
Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=a470bf2860 ]
[LOG4J2-3559] Add release notes
> Incorrect normalization of properties not starting with 'log4j'
> ---
>
> Key: LOG4J2-3559
> URL: https://issues.apache.org/jira/browse/LOG4J2-3559
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.18.0
>Reporter: Piotr Karwasz
>Assignee: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> The {{PropertiesUtil}} incorrectly returns the value of an environment
> variable called 'LOG4J' or system property 'log4j2.' when looking up
> non-existent properties that do not start with 'log4j2?'
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3583) Implement stack-valued MDC
[ https://issues.apache.org/jira/browse/LOG4J2-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600919#comment-17600919 ] ASF subversion and git services commented on LOG4J2-3583: - Commit ccd807b00b4e748f7c1873cdbf30004457188ea2 in logging-log4j2's branch refs/heads/dependabot/maven/org.junit-pioneer-junit-pioneer-1.7.1 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=ccd807b00b ] [LOG4J2-3583] Implements stack-valued MDC This PR implements SLF4J-531 by storing the result of `pushByKey(key, value)` in the usual thread context map and restoring the previous value, when a `popByKey(key)` call occurs. > Implement stack-valued MDC > -- > > Key: LOG4J2-3583 > URL: https://issues.apache.org/jira/browse/LOG4J2-3583 > Project: Log4j 2 > Issue Type: New Feature > Components: SLF4J Bridge >Reporter: Piotr Karwasz >Assignee: Piotr Karwasz >Priority: Minor > Fix For: 2.19.0 > > > SLF4J 2.0 introduces a stack-valued MDC (cf. > [SLF4J-531|https://jira.qos.ch/browse/SLF4J-531])), which must be implemented > in the SLF4J to Log4j2 bridge. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3559) Incorrect normalization of properties not starting with 'log4j'
[
https://issues.apache.org/jira/browse/LOG4J2-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600915#comment-17600915
]
ASF subversion and git services commented on LOG4J2-3559:
-
Commit 18528056fd42a8360f27d9f4f8fac97d477731b9 in logging-log4j2's branch
refs/heads/dependabot/maven/org.junit-pioneer-junit-pioneer-1.7.1 from Piotr P.
Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=18528056fd ]
[LOG4J2-3559] Correct normalization problem.
Properties not starting with 'log4j' are normalized to 'LOG4J' for
environment variables and 'log4j2.' for system properties. This PR
normalizes them to `null`.
> Incorrect normalization of properties not starting with 'log4j'
> ---
>
> Key: LOG4J2-3559
> URL: https://issues.apache.org/jira/browse/LOG4J2-3559
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.18.0
>Reporter: Piotr Karwasz
>Assignee: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> The {{PropertiesUtil}} incorrectly returns the value of an environment
> variable called 'LOG4J' or system property 'log4j2.' when looking up
> non-existent properties that do not start with 'log4j2?'
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-2975) SLF4J fluent API fails to capture call site location due to missing LoggingEventAware implementation
[ https://issues.apache.org/jira/browse/LOG4J2-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600921#comment-17600921 ] ASF subversion and git services commented on LOG4J2-2975: - Commit 8f63620875b7cc742a4c153101a875bf9df45227 in logging-log4j2's branch refs/heads/dependabot/maven/org.junit-pioneer-junit-pioneer-1.7.1 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=8f63620875 ] [LOG4J2-2975] Implements the SLF4J LoggingEventBuilder This PR implements the SLF4J 2.0 `LoggingEventBuilder`, taking care of preserving the caller information. > SLF4J fluent API fails to capture call site location due to missing > LoggingEventAware implementation > > > Key: LOG4J2-2975 > URL: https://issues.apache.org/jira/browse/LOG4J2-2975 > Project: Log4j 2 > Issue Type: New Feature > Components: SLF4J Bridge >Affects Versions: 2.13.3 >Reporter: Daniel Gray >Assignee: Piotr Karwasz >Priority: Major > Fix For: 2.19.0 > > > The logger outputs the wrong log line (120 for INFO, 117 for DEBUG, etc.) > instead of the line in the program that generated the log, when running with > the slf4j bridge. *This causes potential confusion when a person debugging > something is reading the logs as the line numbers are wrong!* > I have prepared 2 simple CLI apps to show the correct behavior (with only > Log4J) and the incorrect behavior (with the SLF4J bridge). Both are using the > exact same configuration (log4j2.properties). The repositories of these > sample projects are: > Good behavior with a pure log4j: > [https://github.com/danielthegray/log4j-nobugsample] > Wrong behavior with the slf4j bridge: > [https://github.com/danielthegray/slf4j-bugsample] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3578) TlsSyslogAppenderTest fails because of expired certificate
[
https://issues.apache.org/jira/browse/LOG4J2-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600912#comment-17600912
]
ASF subversion and git services commented on LOG4J2-3578:
-
Commit 1e25c58dd2a999f90583629fb4ef161abe4bfaa7 in logging-log4j2's branch
refs/heads/dependabot/maven/org.junit-pioneer-junit-pioneer-1.7.1 from Ralph
Goers
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=1e25c58dd2 ]
LOG4J2-3578 - Generate new SSL certs for unit testing
> TlsSyslogAppenderTest fails because of expired certificate
> ---
>
> Key: LOG4J2-3578
> URL: https://issues.apache.org/jira/browse/LOG4J2-3578
> Project: Log4j 2
> Issue Type: Bug
> Components: Tests
>Affects Versions: 2.18.0
>Reporter: Wolff Bock von Wuelfingen
>Assignee: Ralph Goers
>Priority: Major
> Fix For: 2.19.0
>
>
> Running the Test by itself reveals the following cause for
> {{sendLargeLegacyBsdMessageOverTls(), sendLegacyBsdMessagesOverTls(),
> }}{{sendStructuredMessageOverTls(), }}{{sendStructuredMessagesOverTls()}}
> failing:
> {code:java}
> Caused by: java.security.cert.CertPathValidatorException: validity check
> failed
> at
> sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:135)
> at
> sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:220)
> at
> sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:140)
> at
> sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:79)
> at
> java.security.cert.CertPathValidator.validate(CertPathValidator.java:292)
> at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:381)
> ... 75 more
> Caused by: java.security.cert.CertificateExpiredException: NotAfter: Fri Aug
> 05 17:00:53 CEST 2022
> at
> sun.security.x509.CertificateValidity.valid(CertificateValidity.java:277)
> at sun.security.x509.X509CertImpl.checkValidity(X509CertImpl.java:677)
> at
> sun.security.provider.certpath.BasicChecker.verifyValidity(BasicChecker.java:190)
> at
> sun.security.provider.certpath.BasicChecker.check(BasicChecker.java:144)
> at
> sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125)
> ... 80 more {code}
> Looking at the certificate confirms this:
>
> {code:java}
> Validity: [From: Wed Aug 07 17:00:53 CEST 2013,
> To: Fri Aug 05 17:00:53 CEST 2022] {code}
> By overriding the checked Date inside at
> sun.security.x509.X509CertImpl.checkValidity(X509CertImpl.java:677) with the
> debugger i can make all tests pass under Windows.
> I think the certificate at fault is one of those in
> resources/org/apache/logging/log4j/core/net/ssl
> I'm unfortunately not versed enough to make a new certificate with a new
> expiration date.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3370) Add Support for SLF4J 2.0
[
https://issues.apache.org/jira/browse/LOG4J2-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600913#comment-17600913
]
ASF subversion and git services commented on LOG4J2-3370:
-
Commit 73db342e9116044acad5ad649f753cb385c5395f in logging-log4j2's branch
refs/heads/dependabot/maven/org.junit-pioneer-junit-pioneer-1.7.1 from Piotr P.
Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=73db342e91 ]
[LOG4J2-3370] Initial SLF4J 2.0.x support (#1023)
Initial SLF4J 2.0.x support.
> Add Support for SLF4J 2.0
> -
>
> Key: LOG4J2-3370
> URL: https://issues.apache.org/jira/browse/LOG4J2-3370
> Project: Log4j 2
> Issue Type: New Feature
> Components: SLF4J Bridge
>Affects Versions: 2.17.1
>Reporter: Timon H.
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.19.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The SLF4J Bridge (log4j-slf4j18-impl:2.17.1) is currently broken as it
> contains the same typo bug of SLF4J-API which was fixed in SLF4J-API
> 2.0.0-alpha3 and therefore leads to an API mismatch error. In the
> {_}org.apache.logging.slf4j.SLF4JServiceProvider{_}, the
> {_}getRequesteApiVersion{_}-Method need to be refactored to
> {_}getRequeste{*}d{*}ApiVersion{_}.
> h3. See the Changelog of SLF4J-API 2.0.0-alpha3:
> * The {{getRequesteApiVersion}} method in {{SLF4JServiceProvider}} was
> renamed as getRequeste{*}d{*}ApiVersion. This fixes
> [SLF4J-516|https://jira.qos.ch/browse/SLF4J-516].
> This leads to the following exception during the use of
> log4j-slf4j18-impl:2.17.1 with the current SLF4J-API:
> {{Unexpected problem occured during version sanity check}}
> {{Reported exception:}}
> {{java.lang.AbstractMethodError: Receiver class
> org.apache.logging.slf4j.SLF4JServiceProvider does not define or inherit an
> implementation of the resolved method 'abstract java.lang.String
> getRequestedApiVersion()' of interface org.slf4j.spi.SLF4JServiceProvider.}}
> {{ at org.slf4j.LoggerFactory.versionSanityCheck(LoggerFactory.java:297)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3585) Exception in Parameterized Message not logged using LocationAwareLogger API
[
https://issues.apache.org/jira/browse/LOG4J2-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600914#comment-17600914
]
ASF subversion and git services commented on LOG4J2-3585:
-
Commit 674dae6d5596ce33473d8f4588128c155ba5d23c in logging-log4j2's branch
refs/heads/dependabot/maven/org.junit-pioneer-junit-pioneer-1.7.1 from Piotr P.
Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=674dae6d55 ]
[LOG4J2-3585] Fix throwable logging
An inverted condition prevented throwables to be added as additional
arguments.
> Exception in Parameterized Message not logged using LocationAwareLogger API
> ---
>
> Key: LOG4J2-3585
> URL: https://issues.apache.org/jira/browse/LOG4J2-3585
> Project: Log4j 2
> Issue Type: Bug
> Components: SLF4J Bridge
>Affects Versions: 2.17.1
> Environment: Windows 10, Tomcat 9, Java 8
>Reporter: Marian Barton
>Assignee: Piotr Karwasz
>Priority: Major
>
> +Versions:+
> * slf4j-api version 1.7.36
> * log4j-core/log4j-slf4j-impl: 2.17.1
> +Action:+
> Logging a message using LocationAwareLogger.log including an exception as
> unused last parameter in the params array.
> +Result:+
> The message is constructed correctly but the exception is being ignored and
> not logged.
> +Expected:+
> According to the SLF4J FAQ, passing an exception as unused parameter in the
> last place should result in it being interpreted as Exception and logged as
> such.
> +Example:+
> {code:java}
> // Method in wrapping custom logger
> public void error(final String message, final Object... argArray) {
> logger.log(null, FQCN, LocationAwareLogger.ERROR_INT, message, argArray,
> null);
> }
> // Call from another class to that method
> String someString = "insertedString";
> LOGGER.log("Test {}", someString, someException);
> // Result - no exception logged, only message
> 2022-Aug.-31 12:41:59,829 [https-openssl-nio-443-exec-4] some.Class
> ERROR Test insertedString
> // this works though
> public void error(final String message, final Object... argArray) {
> logger.error(message, argArray);
> }{code}
> The same call works when not using the LocationAwareLogger log method but the
> standard logger.error(String message, Object... argArray) method. But since I
> am using a wrapping logger I have to use the LocationAwareLogger interface in
> order to conserve the location information.
> +Possible solution:+
> I debugged a bit to try and find the issue and I might have found the problem
> inside the org.apache.logging.slf4j.Log4jLogger.log method:
> {code:java}
> @Override
> public void log(final Marker marker, final String fqcn, final int level,
> final String message, final Object[] params, Throwable throwable) {
> final Level log4jLevel = getLevel(level);
> final org.apache.logging.log4j.Marker log4jMarker = getMarker(marker);
> if (!logger.isEnabled(log4jLevel, log4jMarker, message, params)) {
> return;
> }
> final Message msg;
> if (CONVERTER != null && eventLogger && marker != null &&
> marker.contains(EVENT_MARKER)) {
> msg = CONVERTER.convertEvent(message, params, throwable);
> } else if (params == null) {
> msg = new SimpleMessage(message);
> } else {
> msg = new ParameterizedMessage(message, params, throwable);
> if (throwable != null) {
> throwable = msg.getThrowable();
> }
> }
> logger.logMessage(fqcn, log4jLevel, log4jMarker, msg, throwable);
> }
> {code}
> The problem here specifically being this part:
> {code:java}
> } else {
> msg = new ParameterizedMessage(message, params, throwable);
> if (throwable != null) {
> throwable = msg.getThrowable();
> }
> }
> {code}
> Log4J successfully detects this as and creates a ParameterizedMessage. This
> instance also correctly found the Throwable from the parameters and set it to
> its throwable property.
> Now I think the bug here is that the if condition is inverted. As I have no
> Throwable explicitly passed to this method (because it is passed via the
> params), it is currently null. In this case SLF4J should check if a Throwable
> is set and if not try to get it from the ParameterizedMessage, because there
> it was successfully detected inside the constructor.
> The correct implementation would therefore be:
> {code:java}
> } else {
> msg = new ParameterizedMessage(message, params, throwable);
> if (throwable == null) {
> throwable = msg.getThrowable();
> }
> }
> {code}
> If the throwable is not set here, it remains inside the ParameterizedMessage
> and is ignored by Log4J, as Log4J appears to only respect the explicit
> Throwable parameter.
> Any questions, feedback and help are/is appr
[jira] [Commented] (LOG4J2-3559) Incorrect normalization of properties not starting with 'log4j'
[
https://issues.apache.org/jira/browse/LOG4J2-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600624#comment-17600624
]
ASF subversion and git services commented on LOG4J2-3559:
-
Commit a470bf2860f6c45b1474ff78ee67153d7de4a120 in logging-log4j2's branch
refs/heads/dependabot/maven/com.conversantmedia-disruptor-1.2.20 from Piotr P.
Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=a470bf2860 ]
[LOG4J2-3559] Add release notes
> Incorrect normalization of properties not starting with 'log4j'
> ---
>
> Key: LOG4J2-3559
> URL: https://issues.apache.org/jira/browse/LOG4J2-3559
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.18.0
>Reporter: Piotr Karwasz
>Assignee: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> The {{PropertiesUtil}} incorrectly returns the value of an environment
> variable called 'LOG4J' or system property 'log4j2.' when looking up
> non-existent properties that do not start with 'log4j2?'
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3585) Exception in Parameterized Message not logged using LocationAwareLogger API
[
https://issues.apache.org/jira/browse/LOG4J2-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600622#comment-17600622
]
ASF subversion and git services commented on LOG4J2-3585:
-
Commit 674dae6d5596ce33473d8f4588128c155ba5d23c in logging-log4j2's branch
refs/heads/dependabot/maven/com.conversantmedia-disruptor-1.2.20 from Piotr P.
Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=674dae6d55 ]
[LOG4J2-3585] Fix throwable logging
An inverted condition prevented throwables to be added as additional
arguments.
> Exception in Parameterized Message not logged using LocationAwareLogger API
> ---
>
> Key: LOG4J2-3585
> URL: https://issues.apache.org/jira/browse/LOG4J2-3585
> Project: Log4j 2
> Issue Type: Bug
> Components: SLF4J Bridge
>Affects Versions: 2.17.1
> Environment: Windows 10, Tomcat 9, Java 8
>Reporter: Marian Barton
>Assignee: Piotr Karwasz
>Priority: Major
>
> +Versions:+
> * slf4j-api version 1.7.36
> * log4j-core/log4j-slf4j-impl: 2.17.1
> +Action:+
> Logging a message using LocationAwareLogger.log including an exception as
> unused last parameter in the params array.
> +Result:+
> The message is constructed correctly but the exception is being ignored and
> not logged.
> +Expected:+
> According to the SLF4J FAQ, passing an exception as unused parameter in the
> last place should result in it being interpreted as Exception and logged as
> such.
> +Example:+
> {code:java}
> // Method in wrapping custom logger
> public void error(final String message, final Object... argArray) {
> logger.log(null, FQCN, LocationAwareLogger.ERROR_INT, message, argArray,
> null);
> }
> // Call from another class to that method
> String someString = "insertedString";
> LOGGER.log("Test {}", someString, someException);
> // Result - no exception logged, only message
> 2022-Aug.-31 12:41:59,829 [https-openssl-nio-443-exec-4] some.Class
> ERROR Test insertedString
> // this works though
> public void error(final String message, final Object... argArray) {
> logger.error(message, argArray);
> }{code}
> The same call works when not using the LocationAwareLogger log method but the
> standard logger.error(String message, Object... argArray) method. But since I
> am using a wrapping logger I have to use the LocationAwareLogger interface in
> order to conserve the location information.
> +Possible solution:+
> I debugged a bit to try and find the issue and I might have found the problem
> inside the org.apache.logging.slf4j.Log4jLogger.log method:
> {code:java}
> @Override
> public void log(final Marker marker, final String fqcn, final int level,
> final String message, final Object[] params, Throwable throwable) {
> final Level log4jLevel = getLevel(level);
> final org.apache.logging.log4j.Marker log4jMarker = getMarker(marker);
> if (!logger.isEnabled(log4jLevel, log4jMarker, message, params)) {
> return;
> }
> final Message msg;
> if (CONVERTER != null && eventLogger && marker != null &&
> marker.contains(EVENT_MARKER)) {
> msg = CONVERTER.convertEvent(message, params, throwable);
> } else if (params == null) {
> msg = new SimpleMessage(message);
> } else {
> msg = new ParameterizedMessage(message, params, throwable);
> if (throwable != null) {
> throwable = msg.getThrowable();
> }
> }
> logger.logMessage(fqcn, log4jLevel, log4jMarker, msg, throwable);
> }
> {code}
> The problem here specifically being this part:
> {code:java}
> } else {
> msg = new ParameterizedMessage(message, params, throwable);
> if (throwable != null) {
> throwable = msg.getThrowable();
> }
> }
> {code}
> Log4J successfully detects this as and creates a ParameterizedMessage. This
> instance also correctly found the Throwable from the parameters and set it to
> its throwable property.
> Now I think the bug here is that the if condition is inverted. As I have no
> Throwable explicitly passed to this method (because it is passed via the
> params), it is currently null. In this case SLF4J should check if a Throwable
> is set and if not try to get it from the ParameterizedMessage, because there
> it was successfully detected inside the constructor.
> The correct implementation would therefore be:
> {code:java}
> } else {
> msg = new ParameterizedMessage(message, params, throwable);
> if (throwable == null) {
> throwable = msg.getThrowable();
> }
> }
> {code}
> If the throwable is not set here, it remains inside the ParameterizedMessage
> and is ignored by Log4J, as Log4J appears to only respect the explicit
> Throwable parameter.
> Any questions, feedback and help are/is appre
[jira] [Commented] (LOG4J2-3370) Add Support for SLF4J 2.0
[
https://issues.apache.org/jira/browse/LOG4J2-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600621#comment-17600621
]
ASF subversion and git services commented on LOG4J2-3370:
-
Commit 73db342e9116044acad5ad649f753cb385c5395f in logging-log4j2's branch
refs/heads/dependabot/maven/com.conversantmedia-disruptor-1.2.20 from Piotr P.
Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=73db342e91 ]
[LOG4J2-3370] Initial SLF4J 2.0.x support (#1023)
Initial SLF4J 2.0.x support.
> Add Support for SLF4J 2.0
> -
>
> Key: LOG4J2-3370
> URL: https://issues.apache.org/jira/browse/LOG4J2-3370
> Project: Log4j 2
> Issue Type: New Feature
> Components: SLF4J Bridge
>Affects Versions: 2.17.1
>Reporter: Timon H.
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.19.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The SLF4J Bridge (log4j-slf4j18-impl:2.17.1) is currently broken as it
> contains the same typo bug of SLF4J-API which was fixed in SLF4J-API
> 2.0.0-alpha3 and therefore leads to an API mismatch error. In the
> {_}org.apache.logging.slf4j.SLF4JServiceProvider{_}, the
> {_}getRequesteApiVersion{_}-Method need to be refactored to
> {_}getRequeste{*}d{*}ApiVersion{_}.
> h3. See the Changelog of SLF4J-API 2.0.0-alpha3:
> * The {{getRequesteApiVersion}} method in {{SLF4JServiceProvider}} was
> renamed as getRequeste{*}d{*}ApiVersion. This fixes
> [SLF4J-516|https://jira.qos.ch/browse/SLF4J-516].
> This leads to the following exception during the use of
> log4j-slf4j18-impl:2.17.1 with the current SLF4J-API:
> {{Unexpected problem occured during version sanity check}}
> {{Reported exception:}}
> {{java.lang.AbstractMethodError: Receiver class
> org.apache.logging.slf4j.SLF4JServiceProvider does not define or inherit an
> implementation of the resolved method 'abstract java.lang.String
> getRequestedApiVersion()' of interface org.slf4j.spi.SLF4JServiceProvider.}}
> {{ at org.slf4j.LoggerFactory.versionSanityCheck(LoggerFactory.java:297)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-2975) SLF4J fluent API fails to capture call site location due to missing LoggingEventAware implementation
[ https://issues.apache.org/jira/browse/LOG4J2-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600629#comment-17600629 ] ASF subversion and git services commented on LOG4J2-2975: - Commit 8f63620875b7cc742a4c153101a875bf9df45227 in logging-log4j2's branch refs/heads/dependabot/maven/com.conversantmedia-disruptor-1.2.20 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=8f63620875 ] [LOG4J2-2975] Implements the SLF4J LoggingEventBuilder This PR implements the SLF4J 2.0 `LoggingEventBuilder`, taking care of preserving the caller information. > SLF4J fluent API fails to capture call site location due to missing > LoggingEventAware implementation > > > Key: LOG4J2-2975 > URL: https://issues.apache.org/jira/browse/LOG4J2-2975 > Project: Log4j 2 > Issue Type: New Feature > Components: SLF4J Bridge >Affects Versions: 2.13.3 >Reporter: Daniel Gray >Assignee: Piotr Karwasz >Priority: Major > Fix For: 2.19.0 > > > The logger outputs the wrong log line (120 for INFO, 117 for DEBUG, etc.) > instead of the line in the program that generated the log, when running with > the slf4j bridge. *This causes potential confusion when a person debugging > something is reading the logs as the line numbers are wrong!* > I have prepared 2 simple CLI apps to show the correct behavior (with only > Log4J) and the incorrect behavior (with the SLF4J bridge). Both are using the > exact same configuration (log4j2.properties). The repositories of these > sample projects are: > Good behavior with a pure log4j: > [https://github.com/danielthegray/log4j-nobugsample] > Wrong behavior with the slf4j bridge: > [https://github.com/danielthegray/slf4j-bugsample] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-2975) SLF4J fluent API fails to capture call site location due to missing LoggingEventAware implementation
[ https://issues.apache.org/jira/browse/LOG4J2-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600630#comment-17600630 ] ASF subversion and git services commented on LOG4J2-2975: - Commit f64c96b591af46e09f7ebebb76d6ba13823fdd44 in logging-log4j2's branch refs/heads/dependabot/maven/com.conversantmedia-disruptor-1.2.20 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=f64c96b591 ] [LOG4J2-2975] Add release notes > SLF4J fluent API fails to capture call site location due to missing > LoggingEventAware implementation > > > Key: LOG4J2-2975 > URL: https://issues.apache.org/jira/browse/LOG4J2-2975 > Project: Log4j 2 > Issue Type: New Feature > Components: SLF4J Bridge >Affects Versions: 2.13.3 >Reporter: Daniel Gray >Assignee: Piotr Karwasz >Priority: Major > Fix For: 2.19.0 > > > The logger outputs the wrong log line (120 for INFO, 117 for DEBUG, etc.) > instead of the line in the program that generated the log, when running with > the slf4j bridge. *This causes potential confusion when a person debugging > something is reading the logs as the line numbers are wrong!* > I have prepared 2 simple CLI apps to show the correct behavior (with only > Log4J) and the incorrect behavior (with the SLF4J bridge). Both are using the > exact same configuration (log4j2.properties). The repositories of these > sample projects are: > Good behavior with a pure log4j: > [https://github.com/danielthegray/log4j-nobugsample] > Wrong behavior with the slf4j bridge: > [https://github.com/danielthegray/slf4j-bugsample] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3583) Implement stack-valued MDC
[ https://issues.apache.org/jira/browse/LOG4J2-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600628#comment-17600628 ] ASF subversion and git services commented on LOG4J2-3583: - Commit 36cf6420bb96aa53ee261db460ef3c9faa978814 in logging-log4j2's branch refs/heads/dependabot/maven/com.conversantmedia-disruptor-1.2.20 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=36cf6420bb ] [LOG4J2-3583] Add tests from #1022 and release notes > Implement stack-valued MDC > -- > > Key: LOG4J2-3583 > URL: https://issues.apache.org/jira/browse/LOG4J2-3583 > Project: Log4j 2 > Issue Type: New Feature > Components: SLF4J Bridge >Reporter: Piotr Karwasz >Assignee: Piotr Karwasz >Priority: Minor > Fix For: 2.19.0 > > > SLF4J 2.0 introduces a stack-valued MDC (cf. > [SLF4J-531|https://jira.qos.ch/browse/SLF4J-531])), which must be implemented > in the SLF4J to Log4j2 bridge. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3556) JsonTemplateLayout truncation ignores exception cause
[
https://issues.apache.org/jira/browse/LOG4J2-3556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600619#comment-17600619
]
ASF subversion and git services commented on LOG4J2-3556:
-
Commit 767e03020b92da705326684ed2edc4f73d7b8d33 in logging-log4j2's branch
refs/heads/dependabot/maven/com.conversantmedia-disruptor-1.2.20 from Volkan
Yazıcı
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=767e03020b ]
LOG4J2-3556 Make JsonTemplateLayout stack trace truncation operate for each
label block. (#1002)
> JsonTemplateLayout truncation ignores exception cause
> -
>
> Key: LOG4J2-3556
> URL: https://issues.apache.org/jira/browse/LOG4J2-3556
> Project: Log4j 2
> Issue Type: Bug
> Components: JsonTemplateLayout
>Reporter: Arthur Gavlyukovskiy
>Assignee: Volkan Yazici
>Priority: Minor
> Fix For: 2.19.0
>
>
> Stacktrace truncation is helpful to reduce the size of the event, but current
> approach implemented in LOG4J2-2993 completely removes any "Caused by:" that
> might be in the stacktrace, while those are the most useful parts of
> stacktrace.
> I'm using the modified EcsLayout.json with suggested truncation point
> {code:java}
> "error.stack_trace": {
> "$resolver": "exception",
> "field": "stackTrace",
> "stackTrace": {
> "stringified": {
> "truncation": {
> "pointMatcherStrings": ["at javax.servlet.http.HttpServlet.service"],
> "suffix": "\n\t"
> }
> }
> }
> } {code}
> and the stacktrace I saw on a real production server was rendered as
> {code:java}
> org.springframework.web.util.NestedServletException: Request processing
> failed; nested exception is java.lang.NullPointerException
> at
> org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1014)
> at
> org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:909)
> at javax.servlet.http.HttpServlet.service
> {code}
> which doesn't show anything about origin of the error.
>
> The fix should be relatively simple - change
> StackTraceStringResolver.truncate method to
> {code:java}
> private void truncate(
> final TruncatingBufferedPrintWriter writer,
> final int index) {
> int causedByIndex = writer.indexOf("Caused by:");
> CharSequence causedBy = null;
> if (causedByIndex != -1) {
> causedBy = writer.subSequence(causedByIndex - 1,
> writer.position());
> }
> writer.position(index);
> writer.print(truncationSuffix);
> if (causedByIndex != -1) {
> writer.print(causedBy);
> }
> }
> {code}
> and it correctly displays the stack trace:
> {code:java}
> java.lang.IllegalArgumentException: wrapper error
> at
> reproducer.log4jjsontemplate.StackTraceController.test(StackTraceController.java:18)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:205)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:150)
> at
> org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:117)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:895)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:808)
> at
> org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:87)
> at
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1067)
> at
> org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:963)
> at
> org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)
> at
> org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:898)
> at javax.servlet.http.HttpServlet.service
>
> Caused by: java.lang.NullPointerException: original error
> at
> reproducer.log4jjsontemplate.StackTraceController.test(StackTraceController.java:16)
> ... 50 more {code}
[jira] [Commented] (LOG4J2-3583) Implement stack-valued MDC
[ https://issues.apache.org/jira/browse/LOG4J2-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600627#comment-17600627 ] ASF subversion and git services commented on LOG4J2-3583: - Commit ccd807b00b4e748f7c1873cdbf30004457188ea2 in logging-log4j2's branch refs/heads/dependabot/maven/com.conversantmedia-disruptor-1.2.20 from Piotr P. Karwasz [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=ccd807b00b ] [LOG4J2-3583] Implements stack-valued MDC This PR implements SLF4J-531 by storing the result of `pushByKey(key, value)` in the usual thread context map and restoring the previous value, when a `popByKey(key)` call occurs. > Implement stack-valued MDC > -- > > Key: LOG4J2-3583 > URL: https://issues.apache.org/jira/browse/LOG4J2-3583 > Project: Log4j 2 > Issue Type: New Feature > Components: SLF4J Bridge >Reporter: Piotr Karwasz >Assignee: Piotr Karwasz >Priority: Minor > Fix For: 2.19.0 > > > SLF4J 2.0 introduces a stack-valued MDC (cf. > [SLF4J-531|https://jira.qos.ch/browse/SLF4J-531])), which must be implemented > in the SLF4J to Log4j2 bridge. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3578) TlsSyslogAppenderTest fails because of expired certificate
[
https://issues.apache.org/jira/browse/LOG4J2-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600620#comment-17600620
]
ASF subversion and git services commented on LOG4J2-3578:
-
Commit 1e25c58dd2a999f90583629fb4ef161abe4bfaa7 in logging-log4j2's branch
refs/heads/dependabot/maven/com.conversantmedia-disruptor-1.2.20 from Ralph
Goers
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=1e25c58dd2 ]
LOG4J2-3578 - Generate new SSL certs for unit testing
> TlsSyslogAppenderTest fails because of expired certificate
> ---
>
> Key: LOG4J2-3578
> URL: https://issues.apache.org/jira/browse/LOG4J2-3578
> Project: Log4j 2
> Issue Type: Bug
> Components: Tests
>Affects Versions: 2.18.0
>Reporter: Wolff Bock von Wuelfingen
>Assignee: Ralph Goers
>Priority: Major
> Fix For: 2.19.0
>
>
> Running the Test by itself reveals the following cause for
> {{sendLargeLegacyBsdMessageOverTls(), sendLegacyBsdMessagesOverTls(),
> }}{{sendStructuredMessageOverTls(), }}{{sendStructuredMessagesOverTls()}}
> failing:
> {code:java}
> Caused by: java.security.cert.CertPathValidatorException: validity check
> failed
> at
> sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:135)
> at
> sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:220)
> at
> sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:140)
> at
> sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:79)
> at
> java.security.cert.CertPathValidator.validate(CertPathValidator.java:292)
> at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:381)
> ... 75 more
> Caused by: java.security.cert.CertificateExpiredException: NotAfter: Fri Aug
> 05 17:00:53 CEST 2022
> at
> sun.security.x509.CertificateValidity.valid(CertificateValidity.java:277)
> at sun.security.x509.X509CertImpl.checkValidity(X509CertImpl.java:677)
> at
> sun.security.provider.certpath.BasicChecker.verifyValidity(BasicChecker.java:190)
> at
> sun.security.provider.certpath.BasicChecker.check(BasicChecker.java:144)
> at
> sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125)
> ... 80 more {code}
> Looking at the certificate confirms this:
>
> {code:java}
> Validity: [From: Wed Aug 07 17:00:53 CEST 2013,
> To: Fri Aug 05 17:00:53 CEST 2022] {code}
> By overriding the checked Date inside at
> sun.security.x509.X509CertImpl.checkValidity(X509CertImpl.java:677) with the
> debugger i can make all tests pass under Windows.
> I think the certificate at fault is one of those in
> resources/org/apache/logging/log4j/core/net/ssl
> I'm unfortunately not versed enough to make a new certificate with a new
> expiration date.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3559) Incorrect normalization of properties not starting with 'log4j'
[
https://issues.apache.org/jira/browse/LOG4J2-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600623#comment-17600623
]
ASF subversion and git services commented on LOG4J2-3559:
-
Commit 18528056fd42a8360f27d9f4f8fac97d477731b9 in logging-log4j2's branch
refs/heads/dependabot/maven/com.conversantmedia-disruptor-1.2.20 from Piotr P.
Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=18528056fd ]
[LOG4J2-3559] Correct normalization problem.
Properties not starting with 'log4j' are normalized to 'LOG4J' for
environment variables and 'log4j2.' for system properties. This PR
normalizes them to `null`.
> Incorrect normalization of properties not starting with 'log4j'
> ---
>
> Key: LOG4J2-3559
> URL: https://issues.apache.org/jira/browse/LOG4J2-3559
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.18.0
>Reporter: Piotr Karwasz
>Assignee: Piotr Karwasz
>Priority: Minor
> Fix For: 2.19.0
>
>
> The {{PropertiesUtil}} incorrectly returns the value of an environment
> variable called 'LOG4J' or system property 'log4j2.' when looking up
> non-existent properties that do not start with 'log4j2?'
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
