[jira] [Commented] (LOG4J2-3628) Migrate from maven-changes-plugin to a merge-conflict-free Markdown-based solution
[
https://issues.apache.org/jira/browse/LOG4J2-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17630585#comment-17630585
]
Carter Kozak commented on LOG4J2-3628:
--
This sounds great to me, the system very nearly matches what we do at work.
Neither cherry-picks nor long-running branches require rebases, even if
releases occur while the change is in-progress, because the destination
directory is static even if existing files are moved elsewhere when a release
occurs. Reverts to released changes _do_ show a merge conflict on the
changelog, which is ideal because we don't want to undo changelogs from
released versions (rather we want to add a new changelog describing the revert).
By being sympathetic to git, there's a great deal of headroom for this sort of
solution to be automated away, however none of that is necessary initially.
> Migrate from maven-changes-plugin to a merge-conflict-free Markdown-based
> solution
> --
>
> Key: LOG4J2-3628
> URL: https://issues.apache.org/jira/browse/LOG4J2-3628
> Project: Log4j 2
> Issue Type: Story
>Reporter: Volkan Yazici
>Priority: Major
> Fix For: 2.20.0
>
>
> As of date, Log4j project keeps its changelog using
> [maven-changelog-plugin|https://maven.apache.org/plugins/maven-changes-plugin/].
> In a nutshell, developers register their entries to {{changes.xml}} and
> {{maven-changelog-plugin}} generates [the
> report|https://logging.apache.org/log4j/2.x/changes-report.html] during Maven
> {{site}} phase.
> This approach has certain drawbacks:
> * {{maven-changelog-plugin}} hasn't been updated since 2016-10-29
> * {{maven-changelog-plugin}} doesn't allow text style formatting (e.g., code
> blocks)
> * {{maven-changelog-plugin}} doesn't allow an introduction paragraph.
> Everything needs to be a ticket; it is not possible to enhance the changelog
> of a release with _"This release has mostly focused on bug fixes, yet we also
> shipped this awesome feature, ..."_ We work around this shortcoming via
> {{{}RELEASE-NOTES.md{}}}, which contradicts with the purpose of this plugin.
> * {{maven-changelog-plugin}} doesn't generate a Markdown-formatted release
> note where one can simply copy paste to, say, [a GitHub
> release|https://github.com/apache/logging-log4j2/releases]. Developers
> manually duplicate its efforts in {{{}RELEASE-NOTES.md{}}}.
> * {{maven-changelog-plugin}} source {{changes.xml}} constantly creates merge
> conflicts
> I propose to replace {{maven-changelog-plugin}} and {{changes.xml}} with the
> following merge-conflict-free Markdown-based solution:
> # The changelogs of the *released* versions will be kept in
> {{changelogs/-.md}} files (e.g.,
> {{{}changelogs/20220223-2.17.2.md{}}})
> # {{changelogs/-.md}} files will be structured as
> described in [keep a changelog|https://keepachangelog.com/en/1.0.0/], where
> tickets are grouped in following types: Added, Changed, Deprecated, Removed,
> Fixed, and Security
> # {{changelogs/index.md}} will keep an index of all
> {{changelogs/-.md}} files
> # The changelog of the *unreleased* version will be kept in
> {{changelogs/unreleased}} directory
> ## {{changelogs/unreleased/_.md}} files will be used to
> register changes: {{{}Added_JTL_Jackson_fallback_support.md{}}},
> {{{}Removed_SLF4J_1.8_bridge.md{}}}, etc. The contents of these files must be
> a single-line Markdown, since it will later be used in a Markdown bullet list.
> ## {{changelogs/unreleased/template.md}} will contain the Markdown file that
> will be used to render the final changelog just before a release. {{ id="Tickets"/>}} will be replaced with a Markdown bullet list containing the
> files in the folder.
> ## {{changelogs/index.md}} and {{changelogs/-.md}} files
> will be symlinked under {{src/site/markdown/changelogs}} directory
> # {{bin/generate-changelogs.sh}} script will perform the following tasks:
> ## generating a {{changelogs/-.md}} from the contents of
> {{changelogs/unreleased}}
> ## removing all {{changelogs/unreleased/_.md}} files
> ## generating {{changelogs/index.md}} again
> h3. How does a {{changelogs/unreleased/template.md}} file look like?
> {code:java}
> The Apache Log4j 2 team is pleased to announce the Log4j id="revision"/> release!
> This release primarily contains bug fixes and minor enhancements.
>
> {code}
> h3. What shall I do when I am about to commit a change?
> Add a {{changelogs/unreleased/_.md}} file along with your
> changes.
> h3. What shall I do when I am about to make a new Log4j release?
> Update the version in the root {{{}pom.xml{}}}, call
> {{{}bin/generate-changelogs.sh{}}}, review and commit changes.
> Now you can proceed with {{{}./mvnw deploy{}}}.
> h3. What about the current {{changes.xml}}?
[jira] [Commented] (LOG4J2-3623) Application went unresponsive because of log4j2
[
https://issues.apache.org/jira/browse/LOG4J2-3623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624017#comment-17624017
]
Carter Kozak commented on LOG4J2-3623:
--
This looks a lot like LOG4J2-3619
Can you please provide a full thread dump?
How frequently can you reproduce this? Is it reproducible using
{{log4j2.asyncLoggerWaitStrategy=Block}} (BlockingWaitStrategy)?
> Application went unresponsive because of log4j2
> ---
>
> Key: LOG4J2-3623
> URL: https://issues.apache.org/jira/browse/LOG4J2-3623
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.17.1
> Environment: Java version - openjdk-1.8.0.191
> Log4j2 version - 2.17.1
> OS - Linux, 2.6.32
> Ring Buffer Size : 1MB
>
>Reporter: Venkatesh
>Priority: Major
>
> We have seen this behavior in during high load of log events. Where Logging
> Got Stropped and Application Went to not responsive state.
> Ring Buffer Size : 128
> Here is the one of the Trace from Thread Dump: I have taken thread dumps
> thrice, every time the states of the threads are at same. One producer thread
> went to TIMED WAITING sate, others went o BLOCKED and consumer (AsynchLogger)
> thread went into TIMED_WAITING state.
> Producer 1 :
> "Scheduler_Worker-7" #143 prio=5 os_prio=0 tid=0x7fae2ac55800 nid=0x18fc
> runnable [0x7faceab12000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338)
> at
> com.lmax.disruptor.MultiProducerSequencer.next(MultiProducerSequencer.java:136)
> at
> com.lmax.disruptor.MultiProducerSequencer.next(MultiProducerSequencer.java:105)
> at com.lmax.disruptor.RingBuffer.publishEvent(RingBuffer.java:465)
> at com.lmax.disruptor.dsl.Disruptor.publishEvent(Disruptor.java:331)
> at
> org.apache.logging.log4j.core.async.AsyncLoggerDisruptor.enqueueLogMessageWhenQueueFull(AsyncLoggerDisruptor.java:236)
> - locked <0x0005522ce890> (a java.lang.Object)
> at
> org.apache.logging.log4j.core.async.AsyncLogger.handleRingBufferFull(AsyncLogger.java:246)
>
> Producer 2:
> "Scheduler_Worker-8" #144 prio=5 os_prio=0 tid=0x7fae2a79b000 nid=0x18fd
> waiting for monitor entry [0x7faceaa12000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.logging.log4j.core.async.AsyncLoggerDisruptor.enqueueLogMessageWhenQueueFull(AsyncLoggerDisruptor.java:236)
> - waiting to lock <0x0005522ce890> (a java.lang.Object)
> at
> org.apache.logging.log4j.core.async.AsyncLogger.handleRingBufferFull(AsyncLogger.java:246)
> at
> org.apache.logging.log4j.core.async.AsyncLogger.publish(AsyncLogger.java:230)
>
> Consumer:
> "Log4j2-TF-4-AsyncLogger[DefaultAsyncContext@main]-2" #17 daemon prio=5
> os_prio=0 tid=0x7fae29692000 nid=0x1806 runnable [0x7fadfea4d000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000553fa0d98> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at
> com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:38)
> at
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
> at
> com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159)
> at
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125)
> at java.lang.Thread.run(Thread.java:748)
>
> Is this is known issue? What is the way to fix this?
> h4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3619) Log4j stops logging when the log message contains a java.lang.StackOverflowError
[ https://issues.apache.org/jira/browse/LOG4J2-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623213#comment-17623213 ] Carter Kozak commented on LOG4J2-3619: -- That would be ideal, if you could reproduce the failure! Is there anything interesting in the StatusLogger (perhaps WARN or ERROR) prior to the failure state? > Log4j stops logging when the log message contains a > java.lang.StackOverflowError > > > Key: LOG4J2-3619 > URL: https://issues.apache.org/jira/browse/LOG4J2-3619 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.17.2 > Environment: We run Weblogic 12 in a Linux environment. >Reporter: Gary ,Verwers >Priority: Major > Attachments: BatchEventProcessor.png, CauseEvent.png, > IncomingReferences.png, cusor.png, gatinngSequence.png, log4j2.xml, > thread-dump-analyses.png, threadDump.txt > > > The RingBuffer Consumer stop printing logs when it comes to a log event with > an exception connected with a StackOverFlowError attached. We have had > this occur several dozen times. > Both the cursor and the gate point at the same place in the event buffer and > very quickly all the threads on the server are frozen waiting for the ring > buffer to clear up space. But the consumer is just stuck waiting a not > printing event. It has failed with a stack overflow from spring MVC mapping > and it has failed with a stack overflow from Jackson JSON ObjectMapper with > object level recursion triggering a stack overflow. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-3619) Log4j stops logging when the log message contains a java.lang.StackOverflowError
[ https://issues.apache.org/jira/browse/LOG4J2-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17621324#comment-17621324 ] Carter Kozak commented on LOG4J2-3619: -- Is there any chance you could create a minimal reproducer that you can share with us via GitHub? It would be tremendously helpful if I could debug locally. > Log4j stops logging when the log message contains a > java.lang.StackOverflowError > > > Key: LOG4J2-3619 > URL: https://issues.apache.org/jira/browse/LOG4J2-3619 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.17.2 > Environment: We run Weblogic 12 in a Linux environment. >Reporter: Gary ,Verwers >Priority: Major > Attachments: BatchEventProcessor.png, CauseEvent.png, > IncomingReferences.png, cusor.png, gatinngSequence.png, log4j2.xml, > thread-dump-analyses.png, threadDump.txt > > > The RingBuffer Consumer stop printing logs when it comes to a log event with > an exception connected with a StackOverFlowError attached. We have had > this occur several dozen times. > Both the cursor and the gate point at the same place in the event buffer and > very quickly all the threads on the server are frozen waiting for the ring > buffer to clear up space. But the consumer is just stuck waiting a not > printing event. It has failed with a stack overflow from spring MVC mapping > and it has failed with a stack overflow from Jackson JSON ObjectMapper with > object level recursion triggering a stack overflow. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LOG4J2-2623) log4j-to-slf4j: Messages are formatted twice if there happen to be a `{}` in the parameters
[
https://issues.apache.org/jira/browse/LOG4J2-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572637#comment-17572637
]
Carter Kozak commented on LOG4J2-2623:
--
I believe this is a duplicate of
https://issues.apache.org/jira/browse/LOG4J2-3289 fixed in 2.17.0
> log4j-to-slf4j: Messages are formatted twice if there happen to be a `{}` in
> the parameters
> ---
>
> Key: LOG4J2-2623
> URL: https://issues.apache.org/jira/browse/LOG4J2-2623
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-SLF4J
>Affects Versions: 2.11.1, 2.11.2, 2.14.1
> Environment: MacOS Majave
> Java 1.8
> log4j2
> logback
>Reporter: Yueguang Jiao
>Assignee: Piotr Karwasz
>Priority: Major
> Labels: easyfix
>
> As says in the summary. If we do
> {code:java}
> logger.info("Message: {}", "Test - {}")
> {code}
> The final message is
> {code:java}
> Message: Test - Test - {}
> {code}
> Which should be
> {code:java}
> Message: Test - {}
> {code}
> See the code at
> [log4j-to-slf4j-test|https://github.com/lasyard/code-java-maven/blob/main/utils/src/test/java/io/github/lasyard/utils/Log4jToSlf4jTest.java].
> After some investigation, I think the reason may lies in
> log4j-to-slf4j/src/main/java/org/apache/logging/slf4j/SLF4JLogger#logMessage
> {code:java}
> locationAwareLogger.log(getMarker(marker), fqcn, convertLevel(level),
> message.getFormattedMessage(),
> message.getParameters(), t);
> {code}
> The String returned by message.getFormattedMessage() is already formatted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3560) Logger$PrivateConfig.filter(Level, Marker, String) allocates empty varargs array
[
https://issues.apache.org/jira/browse/LOG4J2-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572064#comment-17572064
]
Carter Kozak commented on LOG4J2-3560:
--
Thanks for the fix! I've applied it to both release-2.x and master branches.
> Logger$PrivateConfig.filter(Level, Marker, String) allocates empty varargs
> array
>
>
> Key: LOG4J2-3560
> URL: https://issues.apache.org/jira/browse/LOG4J2-3560
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.18.0
>Reporter: David Schlosnagle
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.18.1
>
>
> While reviewing some JFR profiles, I notice significant allocations of
> {{Object[]}} due to use of some {{isEnabled}} conditions that ends up using
> empty varargs invoking {{org.apache.logging.log4j.core.Filter#filter(Logger,
> Level, Marker, String, Object...)}}, for example the following call trace:
> {code}
> at org.apache.logging.log4j.core.Logger$PrivateConfig.filter(Level, Marker,
> String)
> at org.apache.logging.log4j.core.Logger.isEnabled(Level, Marker, String)
> {code}
> We can avoid allocation on this hot path when invoking
> {{Filter#filter(Logger, Level, Marker, String, Object...)}} by reusing an
> empty object array for the varargs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (LOG4J2-3560) Logger$PrivateConfig.filter(Level, Marker, String) allocates empty varargs array
[
https://issues.apache.org/jira/browse/LOG4J2-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak resolved LOG4J2-3560.
--
Resolution: Fixed
> Logger$PrivateConfig.filter(Level, Marker, String) allocates empty varargs
> array
>
>
> Key: LOG4J2-3560
> URL: https://issues.apache.org/jira/browse/LOG4J2-3560
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.18.0
>Reporter: David Schlosnagle
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.18.1
>
>
> While reviewing some JFR profiles, I notice significant allocations of
> {{Object[]}} due to use of some {{isEnabled}} conditions that ends up using
> empty varargs invoking {{org.apache.logging.log4j.core.Filter#filter(Logger,
> Level, Marker, String, Object...)}}, for example the following call trace:
> {code}
> at org.apache.logging.log4j.core.Logger$PrivateConfig.filter(Level, Marker,
> String)
> at org.apache.logging.log4j.core.Logger.isEnabled(Level, Marker, String)
> {code}
> We can avoid allocation on this hot path when invoking
> {{Filter#filter(Logger, Level, Marker, String, Object...)}} by reusing an
> empty object array for the varargs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (LOG4J2-3560) Logger$PrivateConfig.filter(Level, Marker, String) allocates empty varargs array
[
https://issues.apache.org/jira/browse/LOG4J2-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak closed LOG4J2-3560.
> Logger$PrivateConfig.filter(Level, Marker, String) allocates empty varargs
> array
>
>
> Key: LOG4J2-3560
> URL: https://issues.apache.org/jira/browse/LOG4J2-3560
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.18.0
>Reporter: David Schlosnagle
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.18.1
>
>
> While reviewing some JFR profiles, I notice significant allocations of
> {{Object[]}} due to use of some {{isEnabled}} conditions that ends up using
> empty varargs invoking {{org.apache.logging.log4j.core.Filter#filter(Logger,
> Level, Marker, String, Object...)}}, for example the following call trace:
> {code}
> at org.apache.logging.log4j.core.Logger$PrivateConfig.filter(Level, Marker,
> String)
> at org.apache.logging.log4j.core.Logger.isEnabled(Level, Marker, String)
> {code}
> We can avoid allocation on this hot path when invoking
> {{Filter#filter(Logger, Level, Marker, String, Object...)}} by reusing an
> empty object array for the varargs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LOG4J2-3560) Logger$PrivateConfig.filter(Level, Marker, String) allocates empty varargs array
[
https://issues.apache.org/jira/browse/LOG4J2-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak updated LOG4J2-3560:
-
Fix Version/s: 2.18.1
Affects Version/s: 2.18.0
> Logger$PrivateConfig.filter(Level, Marker, String) allocates empty varargs
> array
>
>
> Key: LOG4J2-3560
> URL: https://issues.apache.org/jira/browse/LOG4J2-3560
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.18.0
>Reporter: David Schlosnagle
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.18.1
>
>
> While reviewing some JFR profiles, I notice significant allocations of
> {{Object[]}} due to use of some {{isEnabled}} conditions that ends up using
> empty varargs invoking {{org.apache.logging.log4j.core.Filter#filter(Logger,
> Level, Marker, String, Object...)}}, for example the following call trace:
> {code}
> at org.apache.logging.log4j.core.Logger$PrivateConfig.filter(Level, Marker,
> String)
> at org.apache.logging.log4j.core.Logger.isEnabled(Level, Marker, String)
> {code}
> We can avoid allocation on this hot path when invoking
> {{Filter#filter(Logger, Level, Marker, String, Object...)}} by reusing an
> empty object array for the varargs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (LOG4J2-3560) Logger$PrivateConfig.filter(Level, Marker, String) allocates empty varargs array
[
https://issues.apache.org/jira/browse/LOG4J2-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak reassigned LOG4J2-3560:
Assignee: Carter Kozak
> Logger$PrivateConfig.filter(Level, Marker, String) allocates empty varargs
> array
>
>
> Key: LOG4J2-3560
> URL: https://issues.apache.org/jira/browse/LOG4J2-3560
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
>Reporter: David Schlosnagle
>Assignee: Carter Kozak
>Priority: Major
>
> While reviewing some JFR profiles, I notice significant allocations of
> {{Object[]}} due to use of some {{isEnabled}} conditions that ends up using
> empty varargs invoking {{org.apache.logging.log4j.core.Filter#filter(Logger,
> Level, Marker, String, Object...)}}, for example the following call trace:
> {code}
> at org.apache.logging.log4j.core.Logger$PrivateConfig.filter(Level, Marker,
> String)
> at org.apache.logging.log4j.core.Logger.isEnabled(Level, Marker, String)
> {code}
> We can avoid allocation on this hot path when invoking
> {{Filter#filter(Logger, Level, Marker, String, Object...)}} by reusing an
> empty object array for the varargs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LOG4J2-3505) Threads get stuck inside TimeoutBlockingWaitStrategy when using async logging
[
https://issues.apache.org/jira/browse/LOG4J2-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17536875#comment-17536875
]
Carter Kozak commented on LOG4J2-3505:
--
It's potentially odd that there are two {{AsyncLogger}} threads consuming
ring-buffers -- can you confirm that you expect multiple contexts? Otherwise
you may want to specify
{{-Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.BasicAsyncLoggerContextSelector}}
which doesn't attempt to create a separate context per classloader.
> Threads get stuck inside TimeoutBlockingWaitStrategy when using async logging
> -
>
> Key: LOG4J2-3505
> URL: https://issues.apache.org/jira/browse/LOG4J2-3505
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1
>Reporter: Maksim Fedorov
>Priority: Major
> Attachments: threads.txt
>
>
> In our project we are using log4j2 2.17.1 in async mode with
> RollingRandomAccessFile appenders, LMAX Disruptor version is 3.4.4. Sometimes
> our application gets in a situation when some of its threads get stuck
> infinitely inside Disruptor's
> {{TimeoutBlockingWaitStrategy#signalAllWhenBlocking}} method, while log4j2
> async logger threads are sitting in {{TimeoutBlockingWaitStrategy#waitFor}}
> (see the attached excerpt from the thread dump). From this point logging
> stops completely and the abovementioned application threads become unable to
> make any progress. We added a custom async log queue policy which discards
> all messages regardless of the log level in case of an overflow, but it
> didn't help. Here is our logging configuration:
> {noformat}
> -Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
> -Dlog4j2.asyncLoggerRingBufferSize=524288
> -Dlog4j2.asyncQueueFullPolicy=com.mycompany.logging.DiscardingLogQueueFullPolicy
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-3505) Threads get stuck inside TimeoutBlockingWaitStrategy when using async logging
[
https://issues.apache.org/jira/browse/LOG4J2-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17536864#comment-17536864
]
Carter Kozak commented on LOG4J2-3505:
--
Can you share some details about your DiscardingLogQueueFullPolicy?
> Threads get stuck inside TimeoutBlockingWaitStrategy when using async logging
> -
>
> Key: LOG4J2-3505
> URL: https://issues.apache.org/jira/browse/LOG4J2-3505
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1
>Reporter: Maksim Fedorov
>Priority: Major
> Attachments: threads.txt
>
>
> In our project we are using log4j2 2.17.1 in async mode with
> RollingRandomAccessFile appenders, LMAX Disruptor version is 3.4.4. Sometimes
> our application gets in a situation when some of its threads get stuck
> infinitely inside Disruptor's
> {{TimeoutBlockingWaitStrategy#signalAllWhenBlocking}} method, while log4j2
> async logger threads are sitting in {{TimeoutBlockingWaitStrategy#waitFor}}
> (see the attached excerpt from the thread dump). From this point logging
> stops completely and the abovementioned application threads become unable to
> make any progress. We added a custom async log queue policy which discards
> all messages regardless of the log level in case of an overflow, but it
> didn't help. Here is our logging configuration:
> {noformat}
> -Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
> -Dlog4j2.asyncLoggerRingBufferSize=524288
> -Dlog4j2.asyncQueueFullPolicy=com.mycompany.logging.DiscardingLogQueueFullPolicy
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-3478) Base64 lookup doesn't work with system property substitution
[
https://issues.apache.org/jira/browse/LOG4J2-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531717#comment-17531717
]
Carter Kozak commented on LOG4J2-3478:
--
It looks like that was added to the documentation in this commit:
{noformat}
commit 1ec8712874f8059fac09e39e3f9d3601d8a9f11a
Author: Gary Gregory
Date: Thu Sep 20 15:59:37 2018 -0600
Documentation for base64 variable substitution.
{noformat}
However, I don't see any indication of support for base64 variable substitution
in release-2.x, only in the master (3.x, unreleased) branch.
> Though it only works to decode plain text
Can you provide an example of this working?
> Base64 lookup doesn't work with system property substitution
>
>
> Key: LOG4J2-3478
> URL: https://issues.apache.org/jira/browse/LOG4J2-3478
> Project: Log4j 2
> Issue Type: Bug
>Reporter: oskarryn
>Priority: Minor
>
> Base64 encoded system property doesn't work, e.g.
> {code:java}
> property.token = ${base64:${sys:some.encoded.token}}
> {code}
> fails (silently) and is valued literally, without any expansion. The expected
> behavior is that the _some.encoded.token_ system property would be looked up
> and then decoded by base64 lookup.
> If this kind of "nesting" should be considered a feature please comment and
> I'll change the type.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-3480) Changed behaviour (regression) in 2.17.2 lookup plugin or string interpolation
[
https://issues.apache.org/jira/browse/LOG4J2-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17530920#comment-17530920
]
Carter Kozak commented on LOG4J2-3480:
--
I think you may want to update the lookup plugin to implement the new methods
on StrLookup which return a LookupResult:
https://github.com/apache/logging-log4j2/blob/17a77f5c27bda545de4b8eda46590401313e0be8/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/StrLookup.java#L103-L112
This flag will allow your nested interpolation values to be evaluated as you
expect:
https://github.com/apache/logging-log4j2/blob/17a77f5c27bda545de4b8eda46590401313e0be8/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/LookupResult.java#L25-L33
We opted out of nested interpolation outside of configuration properties due to
security concerns, as you can imagine, if a user provides input which includes
the substitution language, we should never evaluate it.
> Changed behaviour (regression) in 2.17.2 lookup plugin or string interpolation
> --
>
> Key: LOG4J2-3480
> URL: https://issues.apache.org/jira/browse/LOG4J2-3480
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.2
>Reporter: K P
>Priority: Major
> Labels: interpolation, lookup, regression
>
> Something (breaking) changed in the way lookups and/or string interpolation
> is done, between versions 2.17.1 and {*}2.17.2{*}.
> Our situation has some complexities (for historical reason):
> * we can use {_}either a configuration via log4j2.xml file{_},
> or either the same _config built programmatically_
> * we have a {_}custom lookup plugin{_}. Let's call it "foo" for the purpose
> of illustration:
> {{@Plugin(name = "foo", category = "Lookup")}}
> The lookup has a few keys.
> * e.g.: _${foo:version}_ , _${foo:options}_ , etc.
> (reason or underlying implementation doesn't matter here - something to do
> with context based on dynamic modules, threadgroups, etc)
> * The lookup also has the keys _${foo:header}_ and _${foo:footer}_ , which
> contains a larger snippet, INCLUDING some of its other keys.
> e.g. (simplified adapted example)
> "Here some header text for version $${foo:version} at ** $${date} etc etc"
> These double $$ are important here , see further below.
> Then we have in our configuration the following:
> {{ }}
> {{ ... omitted here ... {{ ${foo:header}}}
> {{ ${foo:footer}}}
>
>
> As a result, each logfile is started with the well-defined header snippet
> (this string hard-coded inside the lookup plugin), but that header has some
> variable content (${foo:version}, ${foo:options}, ${date} ), which is
> substituted in turn. And each logfile is terminated by the foo:footer. Having
> this header and footer defined by the lookup ensures that the end-user easily
> configures them in the fixed header and footer in his log4j2.xml.
> Now in our application we also allow a +programmatically built log+
> configuration:
> {{ builder.newLayout("PatternLayout")}}
> {{ .addAttribute("header", HEADER)}}
> {{ .addAttribute("header", FOOTER)}}
> whereby HEADER and FOOTER are the same strings as returned by our custom foo
> lookup plugin when it returns foo:header and foo:footer. (i.e. containing the
> double $$ inside)
> +Why the double $$ ?+
> We have these since many years: The double $$ ensure that the lookups
> included inside the header and footer (e.g. $${foo:version}, but also the
> $${date} ) +are evaluated at the time that the logfile is actually being
> written+ !
> If instead we used a single $ inside the header and footer, the interpolation
> happened only 1x at time of configuration. Which is not what we want.
> e.g. when using a single $, then the timestamp in the header was stuck to
> the timestamp at the time that our application _loaded the logging config._
> Whereas of course we'd want the timestamp to be current at the time the new
> logfile was created.
> If I remember well, the same was true for our custom lookup: to ensure it
> being {+}re{+}-evaluated at the time the logfile was written, we needed to
> use a double $$.
>
> Now this {+}worked fine up until log4j 2.17.1{+}.
> +both+ with our _programmatic_ configuration or when configured via
> _log4j2.xml_
> This _still_ works in log4j 2.17{*}.2{*} when we are running with our
> *programmatically* built configuration:
> However, in log4j 2.17.2 this *no longer* works when the configuration is
> taken from the *log4j2.xml* file.
> In that case, the expansion of double $${...} no longer works.
> Instead, it just prints something like: "{{{}Here some header text for
> version ${foo:version} at ${date} etc{}}}"
> i.e. the double $$ is substi
[jira] [Commented] (LOG4J2-3478) Base64 lookup doesn't work with system property substitution
[
https://issues.apache.org/jira/browse/LOG4J2-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17530910#comment-17530910
]
Carter Kozak commented on LOG4J2-3478:
--
I don't believe we have a base64 lookup in log4j2. If we did, the linked code
should decode as expected.
> Base64 lookup doesn't work with system property substitution
>
>
> Key: LOG4J2-3478
> URL: https://issues.apache.org/jira/browse/LOG4J2-3478
> Project: Log4j 2
> Issue Type: Bug
>Reporter: oskarryn
>Priority: Minor
>
> Base64 encoded system property doesn't work, e.g.
> {code:java}
> property.token = ${base64:${sys:some.encoded.token}}
> {code}
> fails (silently) and is valued literally, without any expansion. The expected
> behavior is that the _some.encoded.token_ system property would be looked up
> and then decoded by base64 lookup.
> If this kind of "nesting" should be considered a feature please comment and
> I'll change the type.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (LOG4J2-3476) Support JUL ApiLogger::setLevel
[
https://issues.apache.org/jira/browse/LOG4J2-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522494#comment-17522494
]
Carter Kozak commented on LOG4J2-3476:
--
I agree with the api/implementation separation and would prefer not to add
level/configuration-mutation features to the api logger. In fact, I consider it
a feature that JUL backed by log4j cannot override my configuration
unexpectedly, although I can understand why it is desirable and wouldn't be
opposed to supporting it :-)
It sounds reasonable that the CoreLogger could support level updates, while the
ApiLogger would not (if log4j-core is not available, some other facade like
slf4j may not support level updates)
> Support JUL ApiLogger::setLevel
> ---
>
> Key: LOG4J2-3476
> URL: https://issues.apache.org/jira/browse/LOG4J2-3476
> Project: Log4j 2
> Issue Type: New Feature
> Components: JUL adapter
>Affects Versions: 2.17.2
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 2.17.3
>
>
> The current implementation of ApiLogger::setLevel is to throw an
> UnsupportedOperation Exception.
> It turns out that Gradle's internal logging tries to call this method under
> some configurations, and it cannot deal gracefully with that Exception, so
> the build fails.
> -[~mattsicker] I was wondering if there is any reason why the implementation
> could not be like this:-
> {code}
> @Override
> public void setLevel(final Level newLevel) throws SecurityException {
> doSetLevel(newLevel);
> Configurator.setLevel(logger, LevelTranslator.toLevel(newLevel));
> }
> {code}
> -I will try this in a test project.-
> (5 minutes later...) Looking at LOG4J2-1110, I understand that this can be
> done in CoreLogger but not in ApiLogger.
> Still, would it be possible to silently ignore this call to setLevel, rather
> than throwing an UnsupportedOperationException?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3470) Expressions in property values are not expanded anymore
[
https://issues.apache.org/jira/browse/LOG4J2-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17518850#comment-17518850
]
Carter Kozak edited comment on LOG4J2-3470 at 4/7/22 12:26 PM:
---
Sorry, based on the link I closed this as a duplicate incorrectly.
Can you provide more information? The entirety of your logging configuration
would be tremendously helpful
was (Author: ckozak):
This is a duplicate of https://issues.apache.org/jira/browse/LOG4J2-3424, which
has been resolved, but not yet released.
> Expressions in property values are not expanded anymore
> ---
>
> Key: LOG4J2-3470
> URL: https://issues.apache.org/jira/browse/LOG4J2-3470
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.17.2
> Environment: Running with / in:
> * Spring Boot 2.6.6
> * log4j 2.17.2
> * Docker / K8s on Amazon EKS
> * Java 11
>Reporter: Jan Mosig
>Priority: Major
>
> In our logging submodule we are using log4j2 properties with value
> expressions to do things, e. g.
> {code}
>
>
> {code}
> However, since we upgraded to 2.17.2, the expressions are not (always)
> expanded anymore, i. e. the log will contain
> {{environment:${env:ENVIRONMENT}}} rather than {{environment:my-fancy-env}}.
> The behavior is reproducible, however different applications behave
> differently, i. e. the same configuration yields different results (as in a
> race condition). The behavior is the same for the same config and application.
> Our current *workaround* is to downgrade to 2.17.1 for the time being.
> Is there maybe a connection to recently introduced raw values? Is this
> related to LOG4J2-3434?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Reopened] (LOG4J2-3470) Expressions in property values are not expanded anymore
[
https://issues.apache.org/jira/browse/LOG4J2-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak reopened LOG4J2-3470:
--
> Expressions in property values are not expanded anymore
> ---
>
> Key: LOG4J2-3470
> URL: https://issues.apache.org/jira/browse/LOG4J2-3470
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.17.2
> Environment: Running with / in:
> * Spring Boot 2.6.6
> * log4j 2.17.2
> * Docker / K8s on Amazon EKS
> * Java 11
>Reporter: Jan Mosig
>Priority: Major
>
> In our logging submodule we are using log4j2 properties with value
> expressions to do things, e. g.
> {code}
>
>
> {code}
> However, since we upgraded to 2.17.2, the expressions are not (always)
> expanded anymore, i. e. the log will contain
> {{environment:${env:ENVIRONMENT}}} rather than {{environment:my-fancy-env}}.
> The behavior is reproducible, however different applications behave
> differently, i. e. the same configuration yields different results (as in a
> race condition). The behavior is the same for the same config and application.
> Our current *workaround* is to downgrade to 2.17.1 for the time being.
> Is there maybe a connection to recently introduced raw values? Is this
> related to LOG4J2-3434?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (LOG4J2-3470) Expressions in property values are not expanded anymore
[
https://issues.apache.org/jira/browse/LOG4J2-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak closed LOG4J2-3470.
Resolution: Duplicate
This is a duplicate of https://issues.apache.org/jira/browse/LOG4J2-3424, which
has been resolved, but not yet released.
> Expressions in property values are not expanded anymore
> ---
>
> Key: LOG4J2-3470
> URL: https://issues.apache.org/jira/browse/LOG4J2-3470
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.17.2
> Environment: Running with / in:
> * Spring Boot 2.6.6
> * log4j 2.17.2
> * Docker / K8s on Amazon EKS
> * Java 11
>Reporter: Jan Mosig
>Priority: Major
>
> In our logging submodule we are using log4j2 properties with value
> expressions to do things, e. g.
> {code}
>
>
> {code}
> However, since we upgraded to 2.17.2, the expressions are not (always)
> expanded anymore, i. e. the log will contain
> {{environment:${env:ENVIRONMENT}}} rather than {{environment:my-fancy-env}}.
> The behavior is reproducible, however different applications behave
> differently, i. e. the same configuration yields different results (as in a
> race condition). The behavior is the same for the same config and application.
> Our current *workaround* is to downgrade to 2.17.1 for the time being.
> Is there maybe a connection to recently introduced raw values? Is this
> related to LOG4J2-3434?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (LOG4J2-3434) Property is not populating "value"
[
https://issues.apache.org/jira/browse/LOG4J2-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak closed LOG4J2-3434.
Resolution: Duplicate
This is a duplicate of https://issues.apache.org/jira/browse/LOG4J2-3424, which
has been resolved, but not yet released.
> Property is not populating "value"
> --
>
> Key: LOG4J2-3434
> URL: https://issues.apache.org/jira/browse/LOG4J2-3434
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.2
>Reporter: Kai
>Priority: Major
>
> When specifying Property for customized appender like:
> {code:java}
> {code}
> It used to populating Property.value with "value1".
> But after upgrading to 2.17.2 with introduce of "rawValue", only "rawValue"
> is populated but "value" stays null.
> Note: current solution for us is to roll back to 2.17.1, which is not ideal.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3459) Reduce use of class static initialization blocks
[ https://issues.apache.org/jira/browse/LOG4J2-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515611#comment-17515611 ] Carter Kozak commented on LOG4J2-3459: -- I’ve used jmh for this sort of thing using oneshot mode with zero warmup, one iteration, 1 thread, and N forks (the number of times to spin up a jvm). The benchmark body just need to trigger log4j init and maybe log a single event depending what we want to measure. The async profiler integration should give helpful data > Reduce use of class static initialization blocks > > > Key: LOG4J2-3459 > URL: https://issues.apache.org/jira/browse/LOG4J2-3459 > Project: Log4j 2 > Issue Type: Improvement > Components: API, Core >Reporter: Matt Sicker >Priority: Major > > There are numerous classes that use static initializer blocks to perform > computation for caching some results. These should all generally be deferred > until some other reference to the class such as instantiation of use of a > singleton getter method. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3345) log4j-jpl must handle parameters as MessageFormat args
[
https://issues.apache.org/jira/browse/LOG4J2-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17503605#comment-17503605
]
Carter Kozak commented on LOG4J2-3345:
--
The System.Logger API that this implements requires MessageFormat formatting,
the api is not aware of curly brace placeholders without indices:
[https://docs.oracle.com/javase/9/docs/api/java/lang/System.Logger.html#log-java.lang.System.Logger.Level-java.lang.String-java.lang.Object...-]
> format - the string message format in
> [{{MessageFormat}}|https://docs.oracle.com/javase/9/docs/api/java/text/MessageFormat.html]
> format
Libraries which consume this API cannot make assumptions about what types of
formatting will be supported by the underlying logging framework. That would be
reasonable if they used log4j-api or slf4j loggers which explicitly support
curly brace placeholders, but not System.Logger.
> log4j-jpl must handle parameters as MessageFormat args
> --
>
> Key: LOG4J2-3345
> URL: https://issues.apache.org/jira/browse/LOG4J2-3345
> Project: Log4j 2
> Issue Type: Bug
> Components: JPL Adapter
>Affects Versions: 2.17.1
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> Currently message parameters use the configured default messagefactory, which
> provides no guarantees around the format used, however JPL API requires
> MessageFormat style formatting.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3424) JDBC Appender configuration properties not handled correctly after upgrading to 2.17.2
[
https://issues.apache.org/jira/browse/LOG4J2-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17501557#comment-17501557
]
Carter Kozak commented on LOG4J2-3424:
--
Thank you for verifying, [~ggrzybek] :)
> JDBC Appender configuration properties not handled correctly after upgrading
> to 2.17.2
> --
>
> Key: LOG4J2-3424
> URL: https://issues.apache.org/jira/browse/LOG4J2-3424
> Project: Log4j 2
> Issue Type: Dependency upgrade
> Components: Appenders, Configuration
>Affects Versions: 2.17.2
>Reporter: Grzegorz Grzybek
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.3
>
>
> I'm a maintainer of Pax Logging project and for long time we had this
> configuration in integration tests:
> {noformat}
> appender.jdbc.type = JDBC
> appender.jdbc.name = jdbc
> appender.jdbc.tableName = LOG
> appender.jdbc.connectionSource.type = DriverManager
> appender.jdbc.connectionSource.driverClassName = org.h2.Driver
> appender.jdbc.connectionSource.connectionString =
> jdbc:h2:tcp://localhost:PORT/logsdb
> appender.jdbc.connectionSource.p1.type = property
> appender.jdbc.connectionSource.p1.name = SCHEMA
> appender.jdbc.connectionSource.p1.value = logs
> appender.jdbc.connectionSource.p2.type = property
> appender.jdbc.connectionSource.p2.name = QUERY_TIMEOUT
> appender.jdbc.connectionSource.p2.value = 5000
> appender.jdbc.connectionSource.p3.type = property
> appender.jdbc.connectionSource.p3.name = user
> appender.jdbc.connectionSource.p3.value = logadmin
> appender.jdbc.connectionSource.p4.type = property
> appender.jdbc.connectionSource.p4.name = password
> appender.jdbc.connectionSource.p4.value = logpassword
> appender.jdbc.c1.type = Column
> appender.jdbc.c1.name = DATE
> appender.jdbc.c1.isEventTimestamp = true
> appender.jdbc.c2.type = Column
> appender.jdbc.c2.name = LEVEL
> appender.jdbc.c2.pattern = %level
> appender.jdbc.c2.isUnicode = false
> appender.jdbc.c3.type = Column
> appender.jdbc.c3.name = SOURCE
> appender.jdbc.c3.pattern = %logger
> appender.jdbc.c3.isUnicode = false
> appender.jdbc.c4.type = Column
> appender.jdbc.c4.name = MESSAGE
> appender.jdbc.c4.pattern = %message
> appender.jdbc.c4.isUnicode = false
> rootLogger.level = info
> rootLogger.appenderRef.console.ref = console
> logger.my.name = my.logger
> logger.my.level = trace
> logger.my.additivity = false
> logger.my.appenderRef.jdbc.ref = jdbc
> {noformat}
> now the properties are not handled correctly. For example with:
> {noformat}
> appender.jdbc.connectionSource.p1.type = property
> appender.jdbc.connectionSource.p1.name = SCHEMA
> appender.jdbc.connectionSource.p1.value = logs
> {noformat}
> I'm getting (in
> {{org.apache.logging.log4j.core.config.plugins.util.PluginBuilder#generateParameters()}}):
> {noformat}
> createProperty(name="SCHEMA", value="logs", value="null")
> {noformat}
> call and
> {{org.apache.logging.log4j.core.config.Property#createProperty(java.lang.String,
> java.lang.String, java.lang.String)}} is called with:
> * SCHEMA
> * logs
> * null
> values.
> In debug logs there's:
> {noformat}
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="password", value="logpassword", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="SCHEMA", value="logs", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="user", value="logadmin", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="QUERY_TIMEOUT", value="5000", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=connectionSource,
> class=org.apache.logging.log4j.core.appender.db.jdbc.DriverManagerConnectionSource].
> {noformat}
> 2.17.2 introduced {{org.apache.logging.log4j.core.config.Property#rawValue}}
> and my values are available under {{rawValue}} instead of {{value}} fields of
> {{org.apache.logging.log4j.core.config.Property}} objects.
> Eventually
> {{org.apache.logging.log4j.core.appender.db.jdbc.AbstractDriverManagerConnectionSource#toProperties()}}
> takes the {{value}} from {{Property}} and it is null.
[jira] [Closed] (LOG4J2-3424) JDBC Appender configuration properties not handled correctly after upgrading to 2.17.2
[
https://issues.apache.org/jira/browse/LOG4J2-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak closed LOG4J2-3424.
> JDBC Appender configuration properties not handled correctly after upgrading
> to 2.17.2
> --
>
> Key: LOG4J2-3424
> URL: https://issues.apache.org/jira/browse/LOG4J2-3424
> Project: Log4j 2
> Issue Type: Dependency upgrade
> Components: Appenders, Configuration
>Affects Versions: 2.17.2
>Reporter: Grzegorz Grzybek
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.3
>
>
> I'm a maintainer of Pax Logging project and for long time we had this
> configuration in integration tests:
> {noformat}
> appender.jdbc.type = JDBC
> appender.jdbc.name = jdbc
> appender.jdbc.tableName = LOG
> appender.jdbc.connectionSource.type = DriverManager
> appender.jdbc.connectionSource.driverClassName = org.h2.Driver
> appender.jdbc.connectionSource.connectionString =
> jdbc:h2:tcp://localhost:PORT/logsdb
> appender.jdbc.connectionSource.p1.type = property
> appender.jdbc.connectionSource.p1.name = SCHEMA
> appender.jdbc.connectionSource.p1.value = logs
> appender.jdbc.connectionSource.p2.type = property
> appender.jdbc.connectionSource.p2.name = QUERY_TIMEOUT
> appender.jdbc.connectionSource.p2.value = 5000
> appender.jdbc.connectionSource.p3.type = property
> appender.jdbc.connectionSource.p3.name = user
> appender.jdbc.connectionSource.p3.value = logadmin
> appender.jdbc.connectionSource.p4.type = property
> appender.jdbc.connectionSource.p4.name = password
> appender.jdbc.connectionSource.p4.value = logpassword
> appender.jdbc.c1.type = Column
> appender.jdbc.c1.name = DATE
> appender.jdbc.c1.isEventTimestamp = true
> appender.jdbc.c2.type = Column
> appender.jdbc.c2.name = LEVEL
> appender.jdbc.c2.pattern = %level
> appender.jdbc.c2.isUnicode = false
> appender.jdbc.c3.type = Column
> appender.jdbc.c3.name = SOURCE
> appender.jdbc.c3.pattern = %logger
> appender.jdbc.c3.isUnicode = false
> appender.jdbc.c4.type = Column
> appender.jdbc.c4.name = MESSAGE
> appender.jdbc.c4.pattern = %message
> appender.jdbc.c4.isUnicode = false
> rootLogger.level = info
> rootLogger.appenderRef.console.ref = console
> logger.my.name = my.logger
> logger.my.level = trace
> logger.my.additivity = false
> logger.my.appenderRef.jdbc.ref = jdbc
> {noformat}
> now the properties are not handled correctly. For example with:
> {noformat}
> appender.jdbc.connectionSource.p1.type = property
> appender.jdbc.connectionSource.p1.name = SCHEMA
> appender.jdbc.connectionSource.p1.value = logs
> {noformat}
> I'm getting (in
> {{org.apache.logging.log4j.core.config.plugins.util.PluginBuilder#generateParameters()}}):
> {noformat}
> createProperty(name="SCHEMA", value="logs", value="null")
> {noformat}
> call and
> {{org.apache.logging.log4j.core.config.Property#createProperty(java.lang.String,
> java.lang.String, java.lang.String)}} is called with:
> * SCHEMA
> * logs
> * null
> values.
> In debug logs there's:
> {noformat}
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="password", value="logpassword", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="SCHEMA", value="logs", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="user", value="logadmin", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="QUERY_TIMEOUT", value="5000", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=connectionSource,
> class=org.apache.logging.log4j.core.appender.db.jdbc.DriverManagerConnectionSource].
> {noformat}
> 2.17.2 introduced {{org.apache.logging.log4j.core.config.Property#rawValue}}
> and my values are available under {{rawValue}} instead of {{value}} fields of
> {{org.apache.logging.log4j.core.config.Property}} objects.
> Eventually
> {{org.apache.logging.log4j.core.appender.db.jdbc.AbstractDriverManagerConnectionSource#toProperties()}}
> takes the {{value}} from {{Property}} and it is null...
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3424) JDBC Appender configuration properties not handled correctly after upgrading to 2.17.2
[
https://issues.apache.org/jira/browse/LOG4J2-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak resolved LOG4J2-3424.
--
Resolution: Fixed
Merged into release-2.x, this will be included in 2.17.3
> JDBC Appender configuration properties not handled correctly after upgrading
> to 2.17.2
> --
>
> Key: LOG4J2-3424
> URL: https://issues.apache.org/jira/browse/LOG4J2-3424
> Project: Log4j 2
> Issue Type: Dependency upgrade
> Components: Appenders, Configuration
>Affects Versions: 2.17.2
>Reporter: Grzegorz Grzybek
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.3
>
>
> I'm a maintainer of Pax Logging project and for long time we had this
> configuration in integration tests:
> {noformat}
> appender.jdbc.type = JDBC
> appender.jdbc.name = jdbc
> appender.jdbc.tableName = LOG
> appender.jdbc.connectionSource.type = DriverManager
> appender.jdbc.connectionSource.driverClassName = org.h2.Driver
> appender.jdbc.connectionSource.connectionString =
> jdbc:h2:tcp://localhost:PORT/logsdb
> appender.jdbc.connectionSource.p1.type = property
> appender.jdbc.connectionSource.p1.name = SCHEMA
> appender.jdbc.connectionSource.p1.value = logs
> appender.jdbc.connectionSource.p2.type = property
> appender.jdbc.connectionSource.p2.name = QUERY_TIMEOUT
> appender.jdbc.connectionSource.p2.value = 5000
> appender.jdbc.connectionSource.p3.type = property
> appender.jdbc.connectionSource.p3.name = user
> appender.jdbc.connectionSource.p3.value = logadmin
> appender.jdbc.connectionSource.p4.type = property
> appender.jdbc.connectionSource.p4.name = password
> appender.jdbc.connectionSource.p4.value = logpassword
> appender.jdbc.c1.type = Column
> appender.jdbc.c1.name = DATE
> appender.jdbc.c1.isEventTimestamp = true
> appender.jdbc.c2.type = Column
> appender.jdbc.c2.name = LEVEL
> appender.jdbc.c2.pattern = %level
> appender.jdbc.c2.isUnicode = false
> appender.jdbc.c3.type = Column
> appender.jdbc.c3.name = SOURCE
> appender.jdbc.c3.pattern = %logger
> appender.jdbc.c3.isUnicode = false
> appender.jdbc.c4.type = Column
> appender.jdbc.c4.name = MESSAGE
> appender.jdbc.c4.pattern = %message
> appender.jdbc.c4.isUnicode = false
> rootLogger.level = info
> rootLogger.appenderRef.console.ref = console
> logger.my.name = my.logger
> logger.my.level = trace
> logger.my.additivity = false
> logger.my.appenderRef.jdbc.ref = jdbc
> {noformat}
> now the properties are not handled correctly. For example with:
> {noformat}
> appender.jdbc.connectionSource.p1.type = property
> appender.jdbc.connectionSource.p1.name = SCHEMA
> appender.jdbc.connectionSource.p1.value = logs
> {noformat}
> I'm getting (in
> {{org.apache.logging.log4j.core.config.plugins.util.PluginBuilder#generateParameters()}}):
> {noformat}
> createProperty(name="SCHEMA", value="logs", value="null")
> {noformat}
> call and
> {{org.apache.logging.log4j.core.config.Property#createProperty(java.lang.String,
> java.lang.String, java.lang.String)}} is called with:
> * SCHEMA
> * logs
> * null
> values.
> In debug logs there's:
> {noformat}
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="password", value="logpassword", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="SCHEMA", value="logs", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="user", value="logadmin", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="QUERY_TIMEOUT", value="5000", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=connectionSource,
> class=org.apache.logging.log4j.core.appender.db.jdbc.DriverManagerConnectionSource].
> {noformat}
> 2.17.2 introduced {{org.apache.logging.log4j.core.config.Property#rawValue}}
> and my values are available under {{rawValue}} instead of {{value}} fields of
> {{org.apache.logging.log4j.core.config.Property}} objects.
> Eventually
> {{org.apache.logging.log4j.core.appender.db.jdbc.AbstractDriverManagerConnectionSource#toProperties()}}
> takes the {{value}} from {{Property}} and it is null...
--
This me
[jira] [Assigned] (LOG4J2-3424) JDBC Appender configuration properties not handled correctly after upgrading to 2.17.2
[
https://issues.apache.org/jira/browse/LOG4J2-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak reassigned LOG4J2-3424:
Assignee: Carter Kozak
> JDBC Appender configuration properties not handled correctly after upgrading
> to 2.17.2
> --
>
> Key: LOG4J2-3424
> URL: https://issues.apache.org/jira/browse/LOG4J2-3424
> Project: Log4j 2
> Issue Type: Dependency upgrade
> Components: Appenders, Configuration
>Affects Versions: 2.17.2
>Reporter: Grzegorz Grzybek
>Assignee: Carter Kozak
>Priority: Major
>
> I'm a maintainer of Pax Logging project and for long time we had this
> configuration in integration tests:
> {noformat}
> appender.jdbc.type = JDBC
> appender.jdbc.name = jdbc
> appender.jdbc.tableName = LOG
> appender.jdbc.connectionSource.type = DriverManager
> appender.jdbc.connectionSource.driverClassName = org.h2.Driver
> appender.jdbc.connectionSource.connectionString =
> jdbc:h2:tcp://localhost:PORT/logsdb
> appender.jdbc.connectionSource.p1.type = property
> appender.jdbc.connectionSource.p1.name = SCHEMA
> appender.jdbc.connectionSource.p1.value = logs
> appender.jdbc.connectionSource.p2.type = property
> appender.jdbc.connectionSource.p2.name = QUERY_TIMEOUT
> appender.jdbc.connectionSource.p2.value = 5000
> appender.jdbc.connectionSource.p3.type = property
> appender.jdbc.connectionSource.p3.name = user
> appender.jdbc.connectionSource.p3.value = logadmin
> appender.jdbc.connectionSource.p4.type = property
> appender.jdbc.connectionSource.p4.name = password
> appender.jdbc.connectionSource.p4.value = logpassword
> appender.jdbc.c1.type = Column
> appender.jdbc.c1.name = DATE
> appender.jdbc.c1.isEventTimestamp = true
> appender.jdbc.c2.type = Column
> appender.jdbc.c2.name = LEVEL
> appender.jdbc.c2.pattern = %level
> appender.jdbc.c2.isUnicode = false
> appender.jdbc.c3.type = Column
> appender.jdbc.c3.name = SOURCE
> appender.jdbc.c3.pattern = %logger
> appender.jdbc.c3.isUnicode = false
> appender.jdbc.c4.type = Column
> appender.jdbc.c4.name = MESSAGE
> appender.jdbc.c4.pattern = %message
> appender.jdbc.c4.isUnicode = false
> rootLogger.level = info
> rootLogger.appenderRef.console.ref = console
> logger.my.name = my.logger
> logger.my.level = trace
> logger.my.additivity = false
> logger.my.appenderRef.jdbc.ref = jdbc
> {noformat}
> now the properties are not handled correctly. For example with:
> {noformat}
> appender.jdbc.connectionSource.p1.type = property
> appender.jdbc.connectionSource.p1.name = SCHEMA
> appender.jdbc.connectionSource.p1.value = logs
> {noformat}
> I'm getting (in
> {{org.apache.logging.log4j.core.config.plugins.util.PluginBuilder#generateParameters()}}):
> {noformat}
> createProperty(name="SCHEMA", value="logs", value="null")
> {noformat}
> call and
> {{org.apache.logging.log4j.core.config.Property#createProperty(java.lang.String,
> java.lang.String, java.lang.String)}} is called with:
> * SCHEMA
> * logs
> * null
> values.
> In debug logs there's:
> {noformat}
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="password", value="logpassword", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="SCHEMA", value="logs", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="user", value="logadmin", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="QUERY_TIMEOUT", value="5000", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=connectionSource,
> class=org.apache.logging.log4j.core.appender.db.jdbc.DriverManagerConnectionSource].
> {noformat}
> 2.17.2 introduced {{org.apache.logging.log4j.core.config.Property#rawValue}}
> and my values are available under {{rawValue}} instead of {{value}} fields of
> {{org.apache.logging.log4j.core.config.Property}} objects.
> Eventually
> {{org.apache.logging.log4j.core.appender.db.jdbc.AbstractDriverManagerConnectionSource#toProperties()}}
> takes the {{value}} from {{Property}} and it is null...
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3424) JDBC Appender configuration properties not handled correctly after upgrading to 2.17.2
[
https://issues.apache.org/jira/browse/LOG4J2-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak updated LOG4J2-3424:
-
Fix Version/s: 2.17.3
> JDBC Appender configuration properties not handled correctly after upgrading
> to 2.17.2
> --
>
> Key: LOG4J2-3424
> URL: https://issues.apache.org/jira/browse/LOG4J2-3424
> Project: Log4j 2
> Issue Type: Dependency upgrade
> Components: Appenders, Configuration
>Affects Versions: 2.17.2
>Reporter: Grzegorz Grzybek
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.3
>
>
> I'm a maintainer of Pax Logging project and for long time we had this
> configuration in integration tests:
> {noformat}
> appender.jdbc.type = JDBC
> appender.jdbc.name = jdbc
> appender.jdbc.tableName = LOG
> appender.jdbc.connectionSource.type = DriverManager
> appender.jdbc.connectionSource.driverClassName = org.h2.Driver
> appender.jdbc.connectionSource.connectionString =
> jdbc:h2:tcp://localhost:PORT/logsdb
> appender.jdbc.connectionSource.p1.type = property
> appender.jdbc.connectionSource.p1.name = SCHEMA
> appender.jdbc.connectionSource.p1.value = logs
> appender.jdbc.connectionSource.p2.type = property
> appender.jdbc.connectionSource.p2.name = QUERY_TIMEOUT
> appender.jdbc.connectionSource.p2.value = 5000
> appender.jdbc.connectionSource.p3.type = property
> appender.jdbc.connectionSource.p3.name = user
> appender.jdbc.connectionSource.p3.value = logadmin
> appender.jdbc.connectionSource.p4.type = property
> appender.jdbc.connectionSource.p4.name = password
> appender.jdbc.connectionSource.p4.value = logpassword
> appender.jdbc.c1.type = Column
> appender.jdbc.c1.name = DATE
> appender.jdbc.c1.isEventTimestamp = true
> appender.jdbc.c2.type = Column
> appender.jdbc.c2.name = LEVEL
> appender.jdbc.c2.pattern = %level
> appender.jdbc.c2.isUnicode = false
> appender.jdbc.c3.type = Column
> appender.jdbc.c3.name = SOURCE
> appender.jdbc.c3.pattern = %logger
> appender.jdbc.c3.isUnicode = false
> appender.jdbc.c4.type = Column
> appender.jdbc.c4.name = MESSAGE
> appender.jdbc.c4.pattern = %message
> appender.jdbc.c4.isUnicode = false
> rootLogger.level = info
> rootLogger.appenderRef.console.ref = console
> logger.my.name = my.logger
> logger.my.level = trace
> logger.my.additivity = false
> logger.my.appenderRef.jdbc.ref = jdbc
> {noformat}
> now the properties are not handled correctly. For example with:
> {noformat}
> appender.jdbc.connectionSource.p1.type = property
> appender.jdbc.connectionSource.p1.name = SCHEMA
> appender.jdbc.connectionSource.p1.value = logs
> {noformat}
> I'm getting (in
> {{org.apache.logging.log4j.core.config.plugins.util.PluginBuilder#generateParameters()}}):
> {noformat}
> createProperty(name="SCHEMA", value="logs", value="null")
> {noformat}
> call and
> {{org.apache.logging.log4j.core.config.Property#createProperty(java.lang.String,
> java.lang.String, java.lang.String)}} is called with:
> * SCHEMA
> * logs
> * null
> values.
> In debug logs there's:
> {noformat}
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="password", value="logpassword", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="SCHEMA", value="logs", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="user", value="logadmin", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="QUERY_TIMEOUT", value="5000", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=connectionSource,
> class=org.apache.logging.log4j.core.appender.db.jdbc.DriverManagerConnectionSource].
> {noformat}
> 2.17.2 introduced {{org.apache.logging.log4j.core.config.Property#rawValue}}
> and my values are available under {{rawValue}} instead of {{value}} fields of
> {{org.apache.logging.log4j.core.config.Property}} objects.
> Eventually
> {{org.apache.logging.log4j.core.appender.db.jdbc.AbstractDriverManagerConnectionSource#toProperties()}}
> takes the {{value}} from {{Property}} and it is null...
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3424) JDBC Appender configuration properties not handled correctly after upgrading to 2.17.2
[
https://issues.apache.org/jira/browse/LOG4J2-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17501401#comment-17501401
]
Carter Kozak commented on LOG4J2-3424:
--
That would be fantastic, my current PR is here:
[https://github.com/apache/logging-log4j2/pull/783]
> JDBC Appender configuration properties not handled correctly after upgrading
> to 2.17.2
> --
>
> Key: LOG4J2-3424
> URL: https://issues.apache.org/jira/browse/LOG4J2-3424
> Project: Log4j 2
> Issue Type: Dependency upgrade
> Components: Appenders, Configuration
>Affects Versions: 2.17.2
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> I'm a maintainer of Pax Logging project and for long time we had this
> configuration in integration tests:
> {noformat}
> appender.jdbc.type = JDBC
> appender.jdbc.name = jdbc
> appender.jdbc.tableName = LOG
> appender.jdbc.connectionSource.type = DriverManager
> appender.jdbc.connectionSource.driverClassName = org.h2.Driver
> appender.jdbc.connectionSource.connectionString =
> jdbc:h2:tcp://localhost:PORT/logsdb
> appender.jdbc.connectionSource.p1.type = property
> appender.jdbc.connectionSource.p1.name = SCHEMA
> appender.jdbc.connectionSource.p1.value = logs
> appender.jdbc.connectionSource.p2.type = property
> appender.jdbc.connectionSource.p2.name = QUERY_TIMEOUT
> appender.jdbc.connectionSource.p2.value = 5000
> appender.jdbc.connectionSource.p3.type = property
> appender.jdbc.connectionSource.p3.name = user
> appender.jdbc.connectionSource.p3.value = logadmin
> appender.jdbc.connectionSource.p4.type = property
> appender.jdbc.connectionSource.p4.name = password
> appender.jdbc.connectionSource.p4.value = logpassword
> appender.jdbc.c1.type = Column
> appender.jdbc.c1.name = DATE
> appender.jdbc.c1.isEventTimestamp = true
> appender.jdbc.c2.type = Column
> appender.jdbc.c2.name = LEVEL
> appender.jdbc.c2.pattern = %level
> appender.jdbc.c2.isUnicode = false
> appender.jdbc.c3.type = Column
> appender.jdbc.c3.name = SOURCE
> appender.jdbc.c3.pattern = %logger
> appender.jdbc.c3.isUnicode = false
> appender.jdbc.c4.type = Column
> appender.jdbc.c4.name = MESSAGE
> appender.jdbc.c4.pattern = %message
> appender.jdbc.c4.isUnicode = false
> rootLogger.level = info
> rootLogger.appenderRef.console.ref = console
> logger.my.name = my.logger
> logger.my.level = trace
> logger.my.additivity = false
> logger.my.appenderRef.jdbc.ref = jdbc
> {noformat}
> now the properties are not handled correctly. For example with:
> {noformat}
> appender.jdbc.connectionSource.p1.type = property
> appender.jdbc.connectionSource.p1.name = SCHEMA
> appender.jdbc.connectionSource.p1.value = logs
> {noformat}
> I'm getting (in
> {{org.apache.logging.log4j.core.config.plugins.util.PluginBuilder#generateParameters()}}):
> {noformat}
> createProperty(name="SCHEMA", value="logs", value="null")
> {noformat}
> call and
> {{org.apache.logging.log4j.core.config.Property#createProperty(java.lang.String,
> java.lang.String, java.lang.String)}} is called with:
> * SCHEMA
> * logs
> * null
> values.
> In debug logs there's:
> {noformat}
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="password", value="logpassword", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="SCHEMA", value="logs", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="user", value="logadmin", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="QUERY_TIMEOUT", value="5000", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=connectionSource,
> class=org.apache.logging.log4j.core.appender.db.jdbc.DriverManagerConnectionSource].
> {noformat}
> 2.17.2 introduced {{org.apache.logging.log4j.core.config.Property#rawValue}}
> and my values are available under {{rawValue}} instead of {{value}} fields of
> {{org.apache.logging.log4j.core.config.Property}} objects.
> Eventually
> {{org.apache.logging.log4j.core.appender.db.jdbc.AbstractDriverManagerConnectionSource#toProperties()}}
> takes the {{value}} from {{Property}} and it is null...
-
[jira] [Commented] (LOG4J2-3424) JDBC Appender configuration properties not handled correctly after upgrading to 2.17.2
[
https://issues.apache.org/jira/browse/LOG4J2-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17501370#comment-17501370
]
Carter Kozak commented on LOG4J2-3424:
--
[~ggrzybek] We have every intention of retaining backwards compatibility, I
introduced an unfortunate regression in the last release which wasn't caught by
our existing testing. This will be fixes by the next release.
> JDBC Appender configuration properties not handled correctly after upgrading
> to 2.17.2
> --
>
> Key: LOG4J2-3424
> URL: https://issues.apache.org/jira/browse/LOG4J2-3424
> Project: Log4j 2
> Issue Type: Dependency upgrade
> Components: Appenders, Configuration
>Affects Versions: 2.17.2
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> I'm a maintainer of Pax Logging project and for long time we had this
> configuration in integration tests:
> {noformat}
> appender.jdbc.type = JDBC
> appender.jdbc.name = jdbc
> appender.jdbc.tableName = LOG
> appender.jdbc.connectionSource.type = DriverManager
> appender.jdbc.connectionSource.driverClassName = org.h2.Driver
> appender.jdbc.connectionSource.connectionString =
> jdbc:h2:tcp://localhost:PORT/logsdb
> appender.jdbc.connectionSource.p1.type = property
> appender.jdbc.connectionSource.p1.name = SCHEMA
> appender.jdbc.connectionSource.p1.value = logs
> appender.jdbc.connectionSource.p2.type = property
> appender.jdbc.connectionSource.p2.name = QUERY_TIMEOUT
> appender.jdbc.connectionSource.p2.value = 5000
> appender.jdbc.connectionSource.p3.type = property
> appender.jdbc.connectionSource.p3.name = user
> appender.jdbc.connectionSource.p3.value = logadmin
> appender.jdbc.connectionSource.p4.type = property
> appender.jdbc.connectionSource.p4.name = password
> appender.jdbc.connectionSource.p4.value = logpassword
> appender.jdbc.c1.type = Column
> appender.jdbc.c1.name = DATE
> appender.jdbc.c1.isEventTimestamp = true
> appender.jdbc.c2.type = Column
> appender.jdbc.c2.name = LEVEL
> appender.jdbc.c2.pattern = %level
> appender.jdbc.c2.isUnicode = false
> appender.jdbc.c3.type = Column
> appender.jdbc.c3.name = SOURCE
> appender.jdbc.c3.pattern = %logger
> appender.jdbc.c3.isUnicode = false
> appender.jdbc.c4.type = Column
> appender.jdbc.c4.name = MESSAGE
> appender.jdbc.c4.pattern = %message
> appender.jdbc.c4.isUnicode = false
> rootLogger.level = info
> rootLogger.appenderRef.console.ref = console
> logger.my.name = my.logger
> logger.my.level = trace
> logger.my.additivity = false
> logger.my.appenderRef.jdbc.ref = jdbc
> {noformat}
> now the properties are not handled correctly. For example with:
> {noformat}
> appender.jdbc.connectionSource.p1.type = property
> appender.jdbc.connectionSource.p1.name = SCHEMA
> appender.jdbc.connectionSource.p1.value = logs
> {noformat}
> I'm getting (in
> {{org.apache.logging.log4j.core.config.plugins.util.PluginBuilder#generateParameters()}}):
> {noformat}
> createProperty(name="SCHEMA", value="logs", value="null")
> {noformat}
> call and
> {{org.apache.logging.log4j.core.config.Property#createProperty(java.lang.String,
> java.lang.String, java.lang.String)}} is called with:
> * SCHEMA
> * logs
> * null
> values.
> In debug logs there's:
> {noformat}
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="password", value="logpassword", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="SCHEMA", value="logs", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="user", value="logadmin", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="QUERY_TIMEOUT", value="5000", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=connectionSource,
> class=org.apache.logging.log4j.core.appender.db.jdbc.DriverManagerConnectionSource].
> {noformat}
> 2.17.2 introduced {{org.apache.logging.log4j.core.config.Property#rawValue}}
> and my values are available under {{rawValue}} instead of {{value}} fields of
> {{org.apache.logging.log4j.core.config.Property}} objects.
> Eventually
> {{org.apache.logging.log4j.core.appender.db.jdbc
[jira] [Commented] (LOG4J2-3424) JDBC Appender configuration properties not handled correctly after upgrading to 2.17.2
[
https://issues.apache.org/jira/browse/LOG4J2-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17501099#comment-17501099
]
Carter Kozak commented on LOG4J2-3424:
--
Ouch, I see the cause, still looking into why this doesn't impact other tests:
In most cases, property values come from elements, not attributes. Attributes
are consumed/removed from the underlying node as we read them, so reading the
same attribute twice results in a null value, while the rawValue is correct.
We can unfortunately reproduce the same behavior in XML using {{}} where {{value}}
works as expected.
I'll put together test coverage and investigate a fix. I'm not entirely sure
how to represent property values as node elements in properties configurations
as a workaround.
> JDBC Appender configuration properties not handled correctly after upgrading
> to 2.17.2
> --
>
> Key: LOG4J2-3424
> URL: https://issues.apache.org/jira/browse/LOG4J2-3424
> Project: Log4j 2
> Issue Type: Dependency upgrade
> Components: Appenders, Configuration
>Affects Versions: 2.17.2
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> I'm a maintainer of Pax Logging project and for long time we had this
> configuration in integration tests:
> {noformat}
> appender.jdbc.type = JDBC
> appender.jdbc.name = jdbc
> appender.jdbc.tableName = LOG
> appender.jdbc.connectionSource.type = DriverManager
> appender.jdbc.connectionSource.driverClassName = org.h2.Driver
> appender.jdbc.connectionSource.connectionString =
> jdbc:h2:tcp://localhost:PORT/logsdb
> appender.jdbc.connectionSource.p1.type = property
> appender.jdbc.connectionSource.p1.name = SCHEMA
> appender.jdbc.connectionSource.p1.value = logs
> appender.jdbc.connectionSource.p2.type = property
> appender.jdbc.connectionSource.p2.name = QUERY_TIMEOUT
> appender.jdbc.connectionSource.p2.value = 5000
> appender.jdbc.connectionSource.p3.type = property
> appender.jdbc.connectionSource.p3.name = user
> appender.jdbc.connectionSource.p3.value = logadmin
> appender.jdbc.connectionSource.p4.type = property
> appender.jdbc.connectionSource.p4.name = password
> appender.jdbc.connectionSource.p4.value = logpassword
> appender.jdbc.c1.type = Column
> appender.jdbc.c1.name = DATE
> appender.jdbc.c1.isEventTimestamp = true
> appender.jdbc.c2.type = Column
> appender.jdbc.c2.name = LEVEL
> appender.jdbc.c2.pattern = %level
> appender.jdbc.c2.isUnicode = false
> appender.jdbc.c3.type = Column
> appender.jdbc.c3.name = SOURCE
> appender.jdbc.c3.pattern = %logger
> appender.jdbc.c3.isUnicode = false
> appender.jdbc.c4.type = Column
> appender.jdbc.c4.name = MESSAGE
> appender.jdbc.c4.pattern = %message
> appender.jdbc.c4.isUnicode = false
> rootLogger.level = info
> rootLogger.appenderRef.console.ref = console
> logger.my.name = my.logger
> logger.my.level = trace
> logger.my.additivity = false
> logger.my.appenderRef.jdbc.ref = jdbc
> {noformat}
> now the properties are not handled correctly. For example with:
> {noformat}
> appender.jdbc.connectionSource.p1.type = property
> appender.jdbc.connectionSource.p1.name = SCHEMA
> appender.jdbc.connectionSource.p1.value = logs
> {noformat}
> I'm getting (in
> {{org.apache.logging.log4j.core.config.plugins.util.PluginBuilder#generateParameters()}}):
> {noformat}
> createProperty(name="SCHEMA", value="logs", value="null")
> {noformat}
> call and
> {{org.apache.logging.log4j.core.config.Property#createProperty(java.lang.String,
> java.lang.String, java.lang.String)}} is called with:
> * SCHEMA
> * logs
> * null
> values.
> In debug logs there's:
> {noformat}
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="password", value="logpassword", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="SCHEMA", value="logs", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="user", value="logadmin", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG :
> createProperty(name="QUERY_TIMEOUT", value="5000", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building
> Plugin[name=connectionSource,
> cla
[jira] [Work started] (LOG4J2-3404) Leak of DefaultConfiguration instances
[
https://issues.apache.org/jira/browse/LOG4J2-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on LOG4J2-3404 started by Carter Kozak.
> Leak of DefaultConfiguration instances
> --
>
> Key: LOG4J2-3404
> URL: https://issues.apache.org/jira/browse/LOG4J2-3404
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.17.1
>Reporter: Piotr P. Karwasz
>Assignee: Carter Kozak
>Priority: Major
>
> If an appender does not specify a layout a default {{PatternLayout}} is
> created *together* with a {{{}DefaultConfiguration{}}}, which is never
> stopped nor attached to a {{{}LoggerContext{}}}.
> For example, if we using a simple file appender:
> {code:java}
> appenders:
> File:
> name: FILE
> fileName: logs/myfile.log {code}
> and running:
> {code:java}
> LogManager.getLogger("test");{code}
> will result in the following (redacted and commented) status logger output:
> {code:java}
> # DefaultConfiguration from LoggerContext constructor
> DEBUG StatusLogger Starting OutputStreamManager SYSTEM_OUT.false.false-1
> DEBUG StatusLogger Starting LoggerContext[name=2437c6dc,
> org.apache.logging.log4j.core.LoggerContext@45752059]...
> DEBUG StatusLogger Reconfiguration started for context[name=2437c6dc] at URI
> null (org.apache.logging.log4j.core.LoggerContext@45752059) with optional
> ClassLoader: null
> # Spurious DefaultConfiguration used to create default PatternLayout
> # This manager will **never** stop
> DEBUG StatusLogger Starting OutputStreamManager SYSTEM_OUT.false.false-2
> # My appender
> DEBUG StatusLogger Starting FileManager logs/myfile.log
> DEBUG StatusLogger Starting configuration
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]
> DEBUG StatusLogger Started configuration
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml] OK.
> # The first DefaultConfiguration stops
> #
> TRACE StatusLogger Stopping
> org.apache.logging.log4j.core.config.DefaultConfiguration@145f66e3...
> DEBUG StatusLogger Shutting down OutputStreamManager SYSTEM_OUT.false.false-1
> DEBUG StatusLogger OutputStream closed
> DEBUG StatusLogger Shut down OutputStreamManager SYSTEM_OUT.false.false-1,
> all resources released: true
> DEBUG StatusLogger Appender DefaultConsole-1 stopped with status true
> TRACE StatusLogger DefaultConfiguration stopped 1 remaining Appenders.
> TRACE StatusLogger DefaultConfiguration cleaning Appenders from 1
> LoggerConfigs.
> DEBUG StatusLogger Stopped
> org.apache.logging.log4j.core.config.DefaultConfiguration@145f66e3 OK
> # At JVM shutdown
> TRACE StatusLogger Stopping
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]...
> TRACE StatusLogger YamlConfiguration notified 2 ReliabilityStrategies that
> config will be stopped.
> TRACE StatusLogger YamlConfiguration stopping 1 LoggerConfigs.
> TRACE StatusLogger YamlConfiguration stopping root LoggerConfig.
> TRACE StatusLogger YamlConfiguration notifying ReliabilityStrategies that
> appenders will be stopped.
> TRACE StatusLogger YamlConfiguration stopping remaining Appenders.
> DEBUG StatusLogger Appender CONSOLE stopped with status true
> TRACE StatusLogger YamlConfiguration stopped 1 remaining Appenders.
> TRACE StatusLogger YamlConfiguration cleaning Appenders from 2 LoggerConfigs.
> DEBUG StatusLogger Stopped
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]
> OK{code}
> I can provide a PR to prevent the leaking of {{DefaultConfiguration}} s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3404) Leak of DefaultConfiguration instances
[
https://issues.apache.org/jira/browse/LOG4J2-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak reassigned LOG4J2-3404:
Assignee: Carter Kozak
> Leak of DefaultConfiguration instances
> --
>
> Key: LOG4J2-3404
> URL: https://issues.apache.org/jira/browse/LOG4J2-3404
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.17.1
>Reporter: Piotr P. Karwasz
>Assignee: Carter Kozak
>Priority: Major
>
> If an appender does not specify a layout a default {{PatternLayout}} is
> created *together* with a {{{}DefaultConfiguration{}}}, which is never
> stopped nor attached to a {{{}LoggerContext{}}}.
> For example, if we using a simple file appender:
> {code:java}
> appenders:
> File:
> name: FILE
> fileName: logs/myfile.log {code}
> and running:
> {code:java}
> LogManager.getLogger("test");{code}
> will result in the following (redacted and commented) status logger output:
> {code:java}
> # DefaultConfiguration from LoggerContext constructor
> DEBUG StatusLogger Starting OutputStreamManager SYSTEM_OUT.false.false-1
> DEBUG StatusLogger Starting LoggerContext[name=2437c6dc,
> org.apache.logging.log4j.core.LoggerContext@45752059]...
> DEBUG StatusLogger Reconfiguration started for context[name=2437c6dc] at URI
> null (org.apache.logging.log4j.core.LoggerContext@45752059) with optional
> ClassLoader: null
> # Spurious DefaultConfiguration used to create default PatternLayout
> # This manager will **never** stop
> DEBUG StatusLogger Starting OutputStreamManager SYSTEM_OUT.false.false-2
> # My appender
> DEBUG StatusLogger Starting FileManager logs/myfile.log
> DEBUG StatusLogger Starting configuration
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]
> DEBUG StatusLogger Started configuration
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml] OK.
> # The first DefaultConfiguration stops
> #
> TRACE StatusLogger Stopping
> org.apache.logging.log4j.core.config.DefaultConfiguration@145f66e3...
> DEBUG StatusLogger Shutting down OutputStreamManager SYSTEM_OUT.false.false-1
> DEBUG StatusLogger OutputStream closed
> DEBUG StatusLogger Shut down OutputStreamManager SYSTEM_OUT.false.false-1,
> all resources released: true
> DEBUG StatusLogger Appender DefaultConsole-1 stopped with status true
> TRACE StatusLogger DefaultConfiguration stopped 1 remaining Appenders.
> TRACE StatusLogger DefaultConfiguration cleaning Appenders from 1
> LoggerConfigs.
> DEBUG StatusLogger Stopped
> org.apache.logging.log4j.core.config.DefaultConfiguration@145f66e3 OK
> # At JVM shutdown
> TRACE StatusLogger Stopping
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]...
> TRACE StatusLogger YamlConfiguration notified 2 ReliabilityStrategies that
> config will be stopped.
> TRACE StatusLogger YamlConfiguration stopping 1 LoggerConfigs.
> TRACE StatusLogger YamlConfiguration stopping root LoggerConfig.
> TRACE StatusLogger YamlConfiguration notifying ReliabilityStrategies that
> appenders will be stopped.
> TRACE StatusLogger YamlConfiguration stopping remaining Appenders.
> DEBUG StatusLogger Appender CONSOLE stopped with status true
> TRACE StatusLogger YamlConfiguration stopped 1 remaining Appenders.
> TRACE StatusLogger YamlConfiguration cleaning Appenders from 2 LoggerConfigs.
> DEBUG StatusLogger Stopped
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]
> OK{code}
> I can provide a PR to prevent the leaking of {{DefaultConfiguration}} s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3404) Leak of DefaultConfiguration instances
[
https://issues.apache.org/jira/browse/LOG4J2-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak resolved LOG4J2-3404.
--
Resolution: Fixed
> Leak of DefaultConfiguration instances
> --
>
> Key: LOG4J2-3404
> URL: https://issues.apache.org/jira/browse/LOG4J2-3404
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.17.1
>Reporter: Piotr P. Karwasz
>Assignee: Carter Kozak
>Priority: Major
>
> If an appender does not specify a layout a default {{PatternLayout}} is
> created *together* with a {{{}DefaultConfiguration{}}}, which is never
> stopped nor attached to a {{{}LoggerContext{}}}.
> For example, if we using a simple file appender:
> {code:java}
> appenders:
> File:
> name: FILE
> fileName: logs/myfile.log {code}
> and running:
> {code:java}
> LogManager.getLogger("test");{code}
> will result in the following (redacted and commented) status logger output:
> {code:java}
> # DefaultConfiguration from LoggerContext constructor
> DEBUG StatusLogger Starting OutputStreamManager SYSTEM_OUT.false.false-1
> DEBUG StatusLogger Starting LoggerContext[name=2437c6dc,
> org.apache.logging.log4j.core.LoggerContext@45752059]...
> DEBUG StatusLogger Reconfiguration started for context[name=2437c6dc] at URI
> null (org.apache.logging.log4j.core.LoggerContext@45752059) with optional
> ClassLoader: null
> # Spurious DefaultConfiguration used to create default PatternLayout
> # This manager will **never** stop
> DEBUG StatusLogger Starting OutputStreamManager SYSTEM_OUT.false.false-2
> # My appender
> DEBUG StatusLogger Starting FileManager logs/myfile.log
> DEBUG StatusLogger Starting configuration
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]
> DEBUG StatusLogger Started configuration
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml] OK.
> # The first DefaultConfiguration stops
> #
> TRACE StatusLogger Stopping
> org.apache.logging.log4j.core.config.DefaultConfiguration@145f66e3...
> DEBUG StatusLogger Shutting down OutputStreamManager SYSTEM_OUT.false.false-1
> DEBUG StatusLogger OutputStream closed
> DEBUG StatusLogger Shut down OutputStreamManager SYSTEM_OUT.false.false-1,
> all resources released: true
> DEBUG StatusLogger Appender DefaultConsole-1 stopped with status true
> TRACE StatusLogger DefaultConfiguration stopped 1 remaining Appenders.
> TRACE StatusLogger DefaultConfiguration cleaning Appenders from 1
> LoggerConfigs.
> DEBUG StatusLogger Stopped
> org.apache.logging.log4j.core.config.DefaultConfiguration@145f66e3 OK
> # At JVM shutdown
> TRACE StatusLogger Stopping
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]...
> TRACE StatusLogger YamlConfiguration notified 2 ReliabilityStrategies that
> config will be stopped.
> TRACE StatusLogger YamlConfiguration stopping 1 LoggerConfigs.
> TRACE StatusLogger YamlConfiguration stopping root LoggerConfig.
> TRACE StatusLogger YamlConfiguration notifying ReliabilityStrategies that
> appenders will be stopped.
> TRACE StatusLogger YamlConfiguration stopping remaining Appenders.
> DEBUG StatusLogger Appender CONSOLE stopped with status true
> TRACE StatusLogger YamlConfiguration stopped 1 remaining Appenders.
> TRACE StatusLogger YamlConfiguration cleaning Appenders from 2 LoggerConfigs.
> DEBUG StatusLogger Stopped
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]
> OK{code}
> I can provide a PR to prevent the leaking of {{DefaultConfiguration}} s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3258) RollingFile fileName containing variables does not work on 2.17.0
[
https://issues.apache.org/jira/browse/LOG4J2-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak resolved LOG4J2-3258.
--
Resolution: Fixed
> RollingFile fileName containing variables does not work on 2.17.0
> -
>
> Key: LOG4J2-3258
> URL: https://issues.apache.org/jira/browse/LOG4J2-3258
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.0
> Environment: Java 17, Ubuntu 20.04.
>Reporter: Konstantinos Liakos
>Assignee: Carter Kozak
>Priority: Major
> Attachments: log4j2-appender-routing.xml, log4j2.xml
>
>
> A configuration like the below has stopped working since 2.17.0. The
> variables that originate from are not resolved to their actual
> values.
> {code:xml}
> $${env:LOGS_DIRECTORY} {code}
> {code:xml}
> fileName="${logs_dir}/${ctx:logFile}"{code}
>
> Works fine on 2.16.0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3258) RollingFile fileName containing variables does not work on 2.17.0
[
https://issues.apache.org/jira/browse/LOG4J2-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494297#comment-17494297
]
Carter Kozak commented on LOG4J2-3258:
--
Yes, this is resolved in 2.17.2-SNAPSHOT with the resolution of LOG4J2-3317.
> RollingFile fileName containing variables does not work on 2.17.0
> -
>
> Key: LOG4J2-3258
> URL: https://issues.apache.org/jira/browse/LOG4J2-3258
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.0
> Environment: Java 17, Ubuntu 20.04.
>Reporter: Konstantinos Liakos
>Assignee: Carter Kozak
>Priority: Major
> Attachments: log4j2-appender-routing.xml, log4j2.xml
>
>
> A configuration like the below has stopped working since 2.17.0. The
> variables that originate from are not resolved to their actual
> values.
> {code:xml}
> $${env:LOGS_DIRECTORY} {code}
> {code:xml}
> fileName="${logs_dir}/${ctx:logFile}"{code}
>
> Works fine on 2.16.0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3258) RollingFile fileName containing variables does not work on 2.17.0
[
https://issues.apache.org/jira/browse/LOG4J2-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak reassigned LOG4J2-3258:
Assignee: Carter Kozak
> RollingFile fileName containing variables does not work on 2.17.0
> -
>
> Key: LOG4J2-3258
> URL: https://issues.apache.org/jira/browse/LOG4J2-3258
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.0
> Environment: Java 17, Ubuntu 20.04.
>Reporter: Konstantinos Liakos
>Assignee: Carter Kozak
>Priority: Major
> Attachments: log4j2-appender-routing.xml, log4j2.xml
>
>
> A configuration like the below has stopped working since 2.17.0. The
> variables that originate from are not resolved to their actual
> values.
> {code:xml}
> $${env:LOGS_DIRECTORY} {code}
> {code:xml}
> fileName="${logs_dir}/${ctx:logFile}"{code}
>
> Works fine on 2.16.0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3317) After 2.17.1 upgarde, Route appenders with dynamic file writing are not working .
[
https://issues.apache.org/jira/browse/LOG4J2-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489558#comment-17489558
]
Carter Kozak commented on LOG4J2-3317:
--
Test coverage is the best option.
For what it's worth, I believe we do have similar types of tests, and fully
expect that case to work – our restriction is upon the evaluation of results of
a lookup e.g. {{{}$\{spring.application.name{ returning a lookup itself,
not lookups that are written to evaluate upon the result of another as you have
described (the difference is subtle, but in your case it's obvious that
{{lower}} is expected to be evaluated upon the result of the spring lookup, so
we allow it.
> After 2.17.1 upgarde, Route appenders with dynamic file writing are not
> working .
> --
>
> Key: LOG4J2-3317
> URL: https://issues.apache.org/jira/browse/LOG4J2-3317
> Project: Log4j 2
> Issue Type: Bug
> Environment: spring boot log4j2.
> deployed on wildfly server.
>Reporter: Srinivasa Babu
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> Hello Sir,
> With log4j2 2.13.3 , Route appenders with context pattern checks for dynamic
> file writing are working fine. After 2.17.1 the functionality is broken.
> I have upgraded to 2.17.1 and our java code, I am setting the ROUTINGKEY in
> threadcontext map. Also i set the system properties,
> log4j2.enableJndiLookup, log4j2.enableJndiJms, and
> log4j2.enableJndiContextSelector to true for all said tags after 2.17.1
> upgrade.
> When I check output file, its not writing the logs to Route File what we
> specify but general RollingFile logger appenders are working fine. Please let
> me know if you have faced this issue or any mitigation plan? Please let me
> know if you want any logs and i will share those if there is any specific
> procedure given.
>
> Calling the below Route from Async logging.
> here my example xml used the same as given in log4j2 documentaion.
>
> filePattern="./logs/${date:-MM}/default-%d\{-MM-dd}-%i.log.gz">
>
> %d\{ISO8601} [%t] %p %c\{3} - %m%n
>
>
>
>
>
>
>
>
> fileName="logs/other-${ctx:ROUTINGKEY}.log"
> filePattern="./logs/${date:-MM}/${ctx:ROUTINGKEY}{-}other{-}%d\{-MM-dd}-%i.log.gz">
>
> %d\{ISO8601} [%t] %p %c\{3} - %m%n
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (LOG4J2-3382) ${ctx:mdcValue} no longer populating in Property tag
[
https://issues.apache.org/jira/browse/LOG4J2-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak closed LOG4J2-3382.
Resolution: Fixed
The fix that I've committed shouldn't require any configuration changes like
the one described in my previous comment. Please try testing with a snapshot
build and let me know the results.
[https://github.com/apache/logging-log4j2/commit/17a77f5c27bda545de4b8eda46590401313e0be8]
> ${ctx:mdcValue} no longer populating in Property tag
>
>
> Key: LOG4J2-3382
> URL: https://issues.apache.org/jira/browse/LOG4J2-3382
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.17.0
>Reporter: Paul Brown
>Assignee: Carter Kozak
>Priority: Major
>
> Values added to the Thread Context are no longer accessible from Property
> tags.
> {{}}
> {{{} name="{}}}{{{}filename.transaction_log{}}}{{{}">${sys:access.log.location}/${web:contextPath}\{_}_{_}transaction\_$${ctx:txLogRecordType}.log{}}}
> {{ }}
> {{}}
> {{}}
> {{ }}
> {{ }}
> {{ }}
> {{ name="Rolling-Transaction-Log-${ctx:txLogRecordType}"}}
> {{ fileName="${filename.transaction_log}"}}
> {{
> filePattern="${filenamePattern.transaction_log}">}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
>
> Added to the MDC in Java:
> {{org.slf4j.MDC.put("txLogRecordType", eventType);}}
> The file produced now looks like:
> {{myservice_transaction_${ctx.txLogRecordType}_2022-01-27-16.log}}
> Prior to upgrading to log4j2 2.17.0, this interpolated as expected.
> Have also tried myserver_transaction_%X\{txLogRecordType}.log, but gives
> similar output file.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3317) After 2.17.1 upgarde, Route appenders with dynamic file writing are not working .
[
https://issues.apache.org/jira/browse/LOG4J2-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak resolved LOG4J2-3317.
--
Fix Version/s: 2.17.2
Resolution: Fixed
Please test using a snapshot build, and close the ticket once you're satisfied
> After 2.17.1 upgarde, Route appenders with dynamic file writing are not
> working .
> --
>
> Key: LOG4J2-3317
> URL: https://issues.apache.org/jira/browse/LOG4J2-3317
> Project: Log4j 2
> Issue Type: Bug
> Environment: spring boot log4j2.
> deployed on wildfly server.
>Reporter: Srinivasa Babu
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> Hello Sir,
> With log4j2 2.13.3 , Route appenders with context pattern checks for dynamic
> file writing are working fine. After 2.17.1 the functionality is broken.
> I have upgraded to 2.17.1 and our java code, I am setting the ROUTINGKEY in
> threadcontext map. Also i set the system properties,
> log4j2.enableJndiLookup, log4j2.enableJndiJms, and
> log4j2.enableJndiContextSelector to true for all said tags after 2.17.1
> upgrade.
> When I check output file, its not writing the logs to Route File what we
> specify but general RollingFile logger appenders are working fine. Please let
> me know if you have faced this issue or any mitigation plan? Please let me
> know if you want any logs and i will share those if there is any specific
> procedure given.
>
> Calling the below Route from Async logging.
> here my example xml used the same as given in log4j2 documentaion.
>
> filePattern="./logs/${date:-MM}/default-%d\{-MM-dd}-%i.log.gz">
>
> %d\{ISO8601} [%t] %p %c\{3} - %m%n
>
>
>
>
>
>
>
>
> fileName="logs/other-${ctx:ROUTINGKEY}.log"
> filePattern="./logs/${date:-MM}/${ctx:ROUTINGKEY}{-}other{-}%d\{-MM-dd}-%i.log.gz">
>
> %d\{ISO8601} [%t] %p %c\{3} - %m%n
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3317) After 2.17.1 upgarde, Route appenders with dynamic file writing are not working .
[
https://issues.apache.org/jira/browse/LOG4J2-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489111#comment-17489111
]
Carter Kozak commented on LOG4J2-3317:
--
This is fixed by
https://github.com/apache/logging-log4j2/commit/17a77f5c27bda545de4b8eda46590401313e0be8
> After 2.17.1 upgarde, Route appenders with dynamic file writing are not
> working .
> --
>
> Key: LOG4J2-3317
> URL: https://issues.apache.org/jira/browse/LOG4J2-3317
> Project: Log4j 2
> Issue Type: Bug
> Environment: spring boot log4j2.
> deployed on wildfly server.
>Reporter: Srinivasa Babu
>Assignee: Carter Kozak
>Priority: Major
>
> Hello Sir,
> With log4j2 2.13.3 , Route appenders with context pattern checks for dynamic
> file writing are working fine. After 2.17.1 the functionality is broken.
> I have upgraded to 2.17.1 and our java code, I am setting the ROUTINGKEY in
> threadcontext map. Also i set the system properties,
> log4j2.enableJndiLookup, log4j2.enableJndiJms, and
> log4j2.enableJndiContextSelector to true for all said tags after 2.17.1
> upgrade.
> When I check output file, its not writing the logs to Route File what we
> specify but general RollingFile logger appenders are working fine. Please let
> me know if you have faced this issue or any mitigation plan? Please let me
> know if you want any logs and i will share those if there is any specific
> procedure given.
>
> Calling the below Route from Async logging.
> here my example xml used the same as given in log4j2 documentaion.
>
> filePattern="./logs/${date:-MM}/default-%d\{-MM-dd}-%i.log.gz">
>
> %d\{ISO8601} [%t] %p %c\{3} - %m%n
>
>
>
>
>
>
>
>
> fileName="logs/other-${ctx:ROUTINGKEY}.log"
> filePattern="./logs/${date:-MM}/${ctx:ROUTINGKEY}{-}other{-}%d\{-MM-dd}-%i.log.gz">
>
> %d\{ISO8601} [%t] %p %c\{3} - %m%n
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3394) The 'rootLogger=${sys:root.logger:-INFO,console}' does not work
[
https://issues.apache.org/jira/browse/LOG4J2-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488202#comment-17488202
]
Carter Kozak commented on LOG4J2-3394:
--
I'm sure we can come up with a reasonable path forward for this!
> The 'rootLogger=${sys:root.logger:-INFO,console}' does not work
> ---
>
> Key: LOG4J2-3394
> URL: https://issues.apache.org/jira/browse/LOG4J2-3394
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Reporter: Duo Zhang
>Priority: Major
> Attachments: log4j2.err, log4j2.properties
>
>
> Tried the new feature introduced in LOG4J2-3341 in hbase.
> https://github.com/apache/hbase/pull/4096
> I built a tarball and try to start a standalone hbase instance locally, but
> log4j2 failed to load the system properties of rootLogger.
> Will upload the config and error output.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3394) The 'rootLogger=${sys:root.logger:-INFO,console}' does not work
[
https://issues.apache.org/jira/browse/LOG4J2-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487505#comment-17487505
]
Carter Kozak commented on LOG4J2-3394:
--
I see, the properties-specific configuration handling is evaluated prior to
lookups, which means the raw value including the raw lookup is interpreted as a
level. I think this is a strong counterexample against format-specific
configuration handling, as it can conflict with assumptions we make elsewhere.
I wonder if there’s a more general solution we can use to implement this
feature?
> The 'rootLogger=${sys:root.logger:-INFO,console}' does not work
> ---
>
> Key: LOG4J2-3394
> URL: https://issues.apache.org/jira/browse/LOG4J2-3394
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Reporter: Duo Zhang
>Priority: Major
> Attachments: log4j2.err, log4j2.properties
>
>
> Tried the new feature introduced in LOG4J2-3341 in hbase.
> https://github.com/apache/hbase/pull/4096
> I built a tarball and try to start a standalone hbase instance locally, but
> log4j2 failed to load the system properties of rootLogger.
> Will upload the config and error output.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3382) ${ctx:mdcValue} no longer populating in Property tag
[
https://issues.apache.org/jira/browse/LOG4J2-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485333#comment-17485333
]
Carter Kozak commented on LOG4J2-3382:
--
This PR addresses the ability to use properties within a routingappender route:
[https://github.com/apache/logging-log4j2/pull/732]
However, it would still require the:
{code:java}
${sys:access.log.location}/${web:contextPath}_transaction_$${ctx:txLogRecordType}.log{code}
to be modified to avoid escaping the {{{}$$\{ctx:txLogRecordType{:
{code:java}
${sys:access.log.location}/${web:contextPath}_transaction_${ctx:txLogRecordType}.log{code}
> ${ctx:mdcValue} no longer populating in Property tag
>
>
> Key: LOG4J2-3382
> URL: https://issues.apache.org/jira/browse/LOG4J2-3382
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.17.0
>Reporter: Paul Brown
>Assignee: Carter Kozak
>Priority: Major
>
> Values added to the Thread Context are no longer accessible from Property
> tags.
> {{}}
> {{{} name="{}}}{{{}filename.transaction_log{}}}{{{}">${sys:access.log.location}/${web:contextPath}\{_}_{_}transaction\_$${ctx:txLogRecordType}.log{}}}
> {{ }}
> {{}}
> {{}}
> {{ }}
> {{ }}
> {{ }}
> {{ name="Rolling-Transaction-Log-${ctx:txLogRecordType}"}}
> {{ fileName="${filename.transaction_log}"}}
> {{
> filePattern="${filenamePattern.transaction_log}">}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
>
> Added to the MDC in Java:
> {{org.slf4j.MDC.put("txLogRecordType", eventType);}}
> The file produced now looks like:
> {{myservice_transaction_${ctx.txLogRecordType}_2022-01-27-16.log}}
> Prior to upgrading to log4j2 2.17.0, this interpolated as expected.
> Have also tried myserver_transaction_%X\{txLogRecordType}.log, but gives
> similar output file.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3382) ${ctx:mdcValue} no longer populating in Property tag
[
https://issues.apache.org/jira/browse/LOG4J2-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17484851#comment-17484851
]
Carter Kozak edited comment on LOG4J2-3382 at 1/31/22, 6:33 PM:
Try replacing $${ctx:txLogRecordType} with ${ctx:txLogRecordType} in the file
path/template (not the routing key which still must be escaped)
was (Author: ckozak):
Try replacing $${ctx:txLogRecordType} with ${ctx:txLogRecordType}
> ${ctx:mdcValue} no longer populating in Property tag
>
>
> Key: LOG4J2-3382
> URL: https://issues.apache.org/jira/browse/LOG4J2-3382
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.17.0
>Reporter: Paul Brown
>Assignee: Carter Kozak
>Priority: Major
>
> Values added to the Thread Context are no longer accessible from Property
> tags.
> {{}}
> {{{} name="{}}}{{{}filename.transaction_log{}}}{{{}">${sys:access.log.location}/${web:contextPath}\{_}_{_}transaction\_$${ctx:txLogRecordType}.log{}}}
> {{ }}
> {{}}
> {{}}
> {{ }}
> {{ }}
> {{ }}
> {{ name="Rolling-Transaction-Log-${ctx:txLogRecordType}"}}
> {{ fileName="${filename.transaction_log}"}}
> {{
> filePattern="${filenamePattern.transaction_log}">}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
>
> Added to the MDC in Java:
> {{org.slf4j.MDC.put("txLogRecordType", eventType);}}
> The file produced now looks like:
> {{myservice_transaction_${ctx.txLogRecordType}_2022-01-27-16.log}}
> Prior to upgrading to log4j2 2.17.0, this interpolated as expected.
> Have also tried myserver_transaction_%X\{txLogRecordType}.log, but gives
> similar output file.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3382) ${ctx:mdcValue} no longer populating in Property tag
[
https://issues.apache.org/jira/browse/LOG4J2-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17484851#comment-17484851
]
Carter Kozak commented on LOG4J2-3382:
--
Try replacing $${ctx:txLogRecordType} with ${ctx:txLogRecordType}
> ${ctx:mdcValue} no longer populating in Property tag
>
>
> Key: LOG4J2-3382
> URL: https://issues.apache.org/jira/browse/LOG4J2-3382
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.17.0
>Reporter: Paul Brown
>Assignee: Carter Kozak
>Priority: Major
>
> Values added to the Thread Context are no longer accessible from Property
> tags.
> {{}}
> {{{} name="{}}}{{{}filename.transaction_log{}}}{{{}">${sys:access.log.location}/${web:contextPath}\{_}_{_}transaction\_$${ctx:txLogRecordType}.log{}}}
> {{ }}
> {{}}
> {{}}
> {{ }}
> {{ }}
> {{ }}
> {{ name="Rolling-Transaction-Log-${ctx:txLogRecordType}"}}
> {{ fileName="${filename.transaction_log}"}}
> {{
> filePattern="${filenamePattern.transaction_log}">}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
>
> Added to the MDC in Java:
> {{org.slf4j.MDC.put("txLogRecordType", eventType);}}
> The file produced now looks like:
> {{myservice_transaction_${ctx.txLogRecordType}_2022-01-27-16.log}}
> Prior to upgrading to log4j2 2.17.0, this interpolated as expected.
> Have also tried myserver_transaction_%X\{txLogRecordType}.log, but gives
> similar output file.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3382) ${ctx:mdcValue} no longer populating in Property tag
[
https://issues.apache.org/jira/browse/LOG4J2-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak reassigned LOG4J2-3382:
Assignee: Carter Kozak
> ${ctx:mdcValue} no longer populating in Property tag
>
>
> Key: LOG4J2-3382
> URL: https://issues.apache.org/jira/browse/LOG4J2-3382
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.17.0
>Reporter: Paul Brown
>Assignee: Carter Kozak
>Priority: Major
>
> Values added to the Thread Context are no longer accessible from Property
> tags.
> {{}}
> {{{} name="{}}}{{{}filename.transaction_log{}}}{{{}">${sys:access.log.location}/${web:contextPath}_{_}transaction_{_}$${ctx:txLogRecordType}.log{}}}
> {{ }}
> {{}}
> {{}}
> {{ }}
> {{ }}
> {{ }}
> {{ name="Rolling-Transaction-Log-${ctx:txLogRecordType}"}}
> {{ fileName="${filename.transaction_log}"}}
> {{
> filePattern="${filenamePattern.transaction_log}">}}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{ }}
> {{}}
>
> Added to the MDC in Java:
> {{org.slf4j.MDC.put("txLogRecordType", eventType);}}
> The file produced now looks like:
> {{myservice_transaction_${ctx.txLogRecordType}_2022-01-27-16.log}}
> Prior to upgrading to log4j2 2.17.0, this interpolated as expected.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (LOG4J2-3346) After 2.17.0 upgarde Route appenders with dynamic file writing are not working
[
https://issues.apache.org/jira/browse/LOG4J2-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak closed LOG4J2-3346.
Resolution: Duplicate
> After 2.17.0 upgarde Route appenders with dynamic file writing are not
> working
> ---
>
> Key: LOG4J2-3346
> URL: https://issues.apache.org/jira/browse/LOG4J2-3346
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.0
>Reporter: Nick Kom
>Assignee: Carter Kozak
>Priority: Major
>
> We switched from the version 2.11.1 to 2.17.0 and writing to separate files
> stopped working. Configuration log4j:
> {code:xml}
>
> ...
>
>
>
> fileName="${logPath}/task-${ctx:V_PID}.log"
>
> filePattern="${logArchPath}/task-${ctx:V_PID}-${archFile}"
> ignoreExceptions="false">
>
>
>
>
>
>
>
> ...
>
>
>
>
>
> {code}
> In code we use Slf4J logger (org.slf4j.Logger) and
> org.apache.logging.log4j.ThreadContext :
> {code:java}
> ThreadContext.put("V_PID", pid);
> org.slf4j.Logger logger
> =org.slf4j.LoggerFactory.getLogger(MessageFormat.format(...));
> {code}
> maven dependencies in pom.xml:
> {code:xml}
>
> 1.7.7
> 2.17.0
> ...
>
> org.slf4j
> slf4j-api
> ${slf4j.version}
>
>
> org.apache.logging.log4j
> log4j-slf4j-impl
> ${log4j2.version}
>
>
> org.apache.logging.log4j
> log4j-api
> ${log4j2.version}
>
>
> org.apache.logging.log4j
> log4j-core
> ${log4j2.version}
>
> ...
> {code}
> We use this in our web application which is deployed on Weblogic 12.2.1.0.0
> What can be wrong? Why aren't separate files (task-${ctx:V_PID}.log) created
> in the folder \{logPath}?
> Before library version 2.12.2 (inclusive),it's worked!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3333) Classloader deadlock in ThreadContextDataInjector
[
https://issues.apache.org/jira/browse/LOG4J2-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak resolved LOG4J2-.
--
Resolution: Fixed
I've resolved the issue on release-2.x for 2.17.2 – please verify from a
snapshot and close the issue when you're satisfied.
> Classloader deadlock in ThreadContextDataInjector
> -
>
> Key: LOG4J2-
> URL: https://issues.apache.org/jira/browse/LOG4J2-
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.1
>Reporter: Ryan Schmitt
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> I ran into a deadlock involving {{ThreadContextDataInjector}} and the "Thread
> Context Data Task" background thread. The basic idea is that the "main"
> thread holds the classloader lock (since log4j2 is initialized during class
> loading, as a rule) and tries to acquire the provider lock, while the "Thread
> Context Data Task" thread holds the provider lock and tries to load classes:
> {code}
> Found one Java-level deadlock:
> =
> "Thread Context Data Task":
> waiting to lock monitor 0x7fde50835958 (object 0x00077bbf51c8, a
> org.powermock.core.classloader.MockClassLoader),
> which is held by "main"
> "main":
> waiting for ownable synchronizer 0x000773e77ae8, (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "Thread Context Data Task"
> Java stack information for the threads listed above:
> ===
> "Thread Context Data Task":
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.getServiceProviders(ThreadContextDataInjector.java:85)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.initServiceProviders(ThreadContextDataInjector.java:73)
> at
> org.apache.logging.log4j.core.LoggerContext$ThreadContextDataTask.run(LoggerContext.java:785)
> at java.lang.Thread.run(Thread.java:748)
> "main":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000773e77ae8> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.initServiceProviders(ThreadContextDataInjector.java:70)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.getProviders(ThreadContextDataInjector.java:285)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.access$000(ThreadContextDataInjector.java:55)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector$ForDefaultThreadContextMap.(ThreadContextDataInjector.java:108)
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createDefaultInjector(ContextDataInjectorFactory.java:91)
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createInjector(ContextDataInjectorFactory.java:71)
> at
> org.apache.logging.log4j.core.impl.Log4jLogEvent.(Log4jLogEvent.java:58)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:643)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:196)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:137)
> at
> org.apache.logging.log
[jira] [Updated] (LOG4J2-3333) Classloader deadlock in ThreadContextDataInjector
[
https://issues.apache.org/jira/browse/LOG4J2-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak updated LOG4J2-:
-
Fix Version/s: 2.17.2
> Classloader deadlock in ThreadContextDataInjector
> -
>
> Key: LOG4J2-
> URL: https://issues.apache.org/jira/browse/LOG4J2-
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.1
>Reporter: Ryan Schmitt
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> I ran into a deadlock involving {{ThreadContextDataInjector}} and the "Thread
> Context Data Task" background thread. The basic idea is that the "main"
> thread holds the classloader lock (since log4j2 is initialized during class
> loading, as a rule) and tries to acquire the provider lock, while the "Thread
> Context Data Task" thread holds the provider lock and tries to load classes:
> {code}
> Found one Java-level deadlock:
> =
> "Thread Context Data Task":
> waiting to lock monitor 0x7fde50835958 (object 0x00077bbf51c8, a
> org.powermock.core.classloader.MockClassLoader),
> which is held by "main"
> "main":
> waiting for ownable synchronizer 0x000773e77ae8, (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "Thread Context Data Task"
> Java stack information for the threads listed above:
> ===
> "Thread Context Data Task":
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.getServiceProviders(ThreadContextDataInjector.java:85)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.initServiceProviders(ThreadContextDataInjector.java:73)
> at
> org.apache.logging.log4j.core.LoggerContext$ThreadContextDataTask.run(LoggerContext.java:785)
> at java.lang.Thread.run(Thread.java:748)
> "main":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000773e77ae8> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.initServiceProviders(ThreadContextDataInjector.java:70)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.getProviders(ThreadContextDataInjector.java:285)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.access$000(ThreadContextDataInjector.java:55)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector$ForDefaultThreadContextMap.(ThreadContextDataInjector.java:108)
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createDefaultInjector(ContextDataInjectorFactory.java:91)
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createInjector(ContextDataInjectorFactory.java:71)
> at
> org.apache.logging.log4j.core.impl.Log4jLogEvent.(Log4jLogEvent.java:58)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:643)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:196)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:137)
> at
> org.apache.logging.log4j.jcl.LogAdapter.getContext(LogAdapter.java:40)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(A
[jira] [Closed] (LOG4J2-3288) Interpolator non-plugin codepath doesn't include all log4j-core lookups
[
https://issues.apache.org/jira/browse/LOG4J2-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak closed LOG4J2-3288.
> Interpolator non-plugin codepath doesn't include all log4j-core lookups
> ---
>
> Key: LOG4J2-3288
> URL: https://issues.apache.org/jira/browse/LOG4J2-3288
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration, Core
>Affects Versions: 2.17.0
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> It appears that {{bundle}} {{{}event{}}}, and {{sd}} lookups are not
> registered.
> There's a comment suggesting that the PluginManager could be used, however
> that will require additional validation before I'm comfortable enabling it:
> Logging initialization is very static and tricky, and it's easy to produce
> deadlocks when referencing logging code within initialization.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3288) Interpolator non-plugin codepath doesn't include all log4j-core lookups
[
https://issues.apache.org/jira/browse/LOG4J2-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak resolved LOG4J2-3288.
--
Resolution: Fixed
Closing via
Commit 7ca3c4f5f206ca81dfdda2699703c9abc4d22624 in logging-log4j2's branch
refs/heads/release-2.x from Carter Kozak
Commit c062f55318cac4205c7f7606b8e3091f67999516 in logging-log4j2's branch
refs/heads/master from Carter Kozak
> Interpolator non-plugin codepath doesn't include all log4j-core lookups
> ---
>
> Key: LOG4J2-3288
> URL: https://issues.apache.org/jira/browse/LOG4J2-3288
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration, Core
>Affects Versions: 2.17.0
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> It appears that {{bundle}} {{{}event{}}}, and {{sd}} lookups are not
> registered.
> There's a comment suggesting that the PluginManager could be used, however
> that will require additional validation before I'm comfortable enabling it:
> Logging initialization is very static and tricky, and it's easy to produce
> deadlocks when referencing logging code within initialization.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3358) 2.17.1: JsonLayout Context no longer working.
[
https://issues.apache.org/jira/browse/LOG4J2-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak updated LOG4J2-3358:
-
Fix Version/s: 2.17.2
> 2.17.1: JsonLayout Context no longer working.
> -
>
> Key: LOG4J2-3358
> URL: https://issues.apache.org/jira/browse/LOG4J2-3358
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.17.1
>Reporter: Markus Duft
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> We're creating a RollingFileAppender programmatically using a JsonLayout.
> This uses fields using ${ctx:...} expansion. This stopped working when
> upgrading from 2.17.0 to 2.17.1.
> The code is as follows:
> {code:java}
> /**
> * Creates a rolling file appender that write audit entries to a
> programmatically readable JSON file.
> */
> private RollingFileAppender createJsonAppender(Path logDir) {
> List fields = new ArrayList<>();
>
> fields.add(KeyValuePair.newBuilder().setKey("who").setValue("${ctx:WHO}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("what").setValue("${ctx:WHAT}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("method").setValue("${ctx:METHOD}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("parameters").setValue("${ctx:PARAMETERS}").build());
>
> RollingFileAppender.Builder builder =
> RollingFileAppender.newBuilder();
> builder.setName("auditJsonLogger");
> builder.withFileName(logDir.resolve(LOG_JSON_FILENAME).toString());
>
> builder.withFilePattern(logDir.resolve(LOG_JSON_FILEPATTERN).toString());
> builder.withPolicy(SizeBasedTriggeringPolicy.createPolicy("10M"));
>
> builder.setLayout(JsonLayout.newBuilder().setCompact(true).setEventEol(true).setConfiguration(new
> DefaultConfiguration())
> .setAdditionalFields(fields.toArray(new
> KeyValuePair[0])).build());
> builder.withStrategy(
>
> DefaultRolloverStrategy.newBuilder().withCompressionLevelStr(String.valueOf(Deflater.DEFAULT_COMPRESSION))
>
> .withMax(Integer.toString(LOG_MAX_INDEX)).withFileIndex("min").build());
> return builder.build();
> } {code}
> We also tried to use %X\{...} as well as $${ctx:...} expansions instead to no
> avail. The log file always contains the *literal* string we use in
> .setValue(), i.e. lines like this:
> {noformat}
> {"instant":{"epochSecond":1642756242,"nanoOfSecond":271091900},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":65,"threadPriority":5,"who":"${ctx:WHO}","what":"${ctx:WHAT}","method":"${ctx:METHOD}","parameters":"${ctx:PARAMETERS}"}{noformat}
> Reverting to 2.17.0 will correctly give lines like this in the JSON file:
> {noformat}
> {"instant":{"epochSecond":1642756430,"nanoOfSecond":923210700},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":62,"threadPriority":5,"who":"marku","what":"ObjectConsistencyCheckOperation","method":"-","parameters":"{dryRun=false,
> roots=[io.bdeploy/demo/client-app/linux:1.0.0,
> io.bdeploy/demo/client-app/linux:2.0.0,
> io.bdeploy/demo/client-app/windows:1.0.0, ...]}"}{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3288) Interpolator non-plugin codepath doesn't include all log4j-core lookups
[
https://issues.apache.org/jira/browse/LOG4J2-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak updated LOG4J2-3288:
-
Fix Version/s: 2.17.2
> Interpolator non-plugin codepath doesn't include all log4j-core lookups
> ---
>
> Key: LOG4J2-3288
> URL: https://issues.apache.org/jira/browse/LOG4J2-3288
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration, Core
>Affects Versions: 2.17.0
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> It appears that {{bundle}} {{{}event{}}}, and {{sd}} lookups are not
> registered.
> There's a comment suggesting that the PluginManager could be used, however
> that will require additional validation before I'm comfortable enabling it:
> Logging initialization is very static and tricky, and it's easy to produce
> deadlocks when referencing logging code within initialization.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3358) 2.17.1: JsonLayout Context no longer working.
[
https://issues.apache.org/jira/browse/LOG4J2-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480313#comment-17480313
]
Carter Kozak commented on LOG4J2-3358:
--
[~mduft] Please verify with a snapshot and close this ticket once you're happy
with it – thank you for the report!
> 2.17.1: JsonLayout Context no longer working.
> -
>
> Key: LOG4J2-3358
> URL: https://issues.apache.org/jira/browse/LOG4J2-3358
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.17.1
>Reporter: Markus Duft
>Assignee: Carter Kozak
>Priority: Major
>
> We're creating a RollingFileAppender programmatically using a JsonLayout.
> This uses fields using ${ctx:...} expansion. This stopped working when
> upgrading from 2.17.0 to 2.17.1.
> The code is as follows:
> {code:java}
> /**
> * Creates a rolling file appender that write audit entries to a
> programmatically readable JSON file.
> */
> private RollingFileAppender createJsonAppender(Path logDir) {
> List fields = new ArrayList<>();
>
> fields.add(KeyValuePair.newBuilder().setKey("who").setValue("${ctx:WHO}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("what").setValue("${ctx:WHAT}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("method").setValue("${ctx:METHOD}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("parameters").setValue("${ctx:PARAMETERS}").build());
>
> RollingFileAppender.Builder builder =
> RollingFileAppender.newBuilder();
> builder.setName("auditJsonLogger");
> builder.withFileName(logDir.resolve(LOG_JSON_FILENAME).toString());
>
> builder.withFilePattern(logDir.resolve(LOG_JSON_FILEPATTERN).toString());
> builder.withPolicy(SizeBasedTriggeringPolicy.createPolicy("10M"));
>
> builder.setLayout(JsonLayout.newBuilder().setCompact(true).setEventEol(true).setConfiguration(new
> DefaultConfiguration())
> .setAdditionalFields(fields.toArray(new
> KeyValuePair[0])).build());
> builder.withStrategy(
>
> DefaultRolloverStrategy.newBuilder().withCompressionLevelStr(String.valueOf(Deflater.DEFAULT_COMPRESSION))
>
> .withMax(Integer.toString(LOG_MAX_INDEX)).withFileIndex("min").build());
> return builder.build();
> } {code}
> We also tried to use %X\{...} as well as $${ctx:...} expansions instead to no
> avail. The log file always contains the *literal* string we use in
> .setValue(), i.e. lines like this:
> {noformat}
> {"instant":{"epochSecond":1642756242,"nanoOfSecond":271091900},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":65,"threadPriority":5,"who":"${ctx:WHO}","what":"${ctx:WHAT}","method":"${ctx:METHOD}","parameters":"${ctx:PARAMETERS}"}{noformat}
> Reverting to 2.17.0 will correctly give lines like this in the JSON file:
> {noformat}
> {"instant":{"epochSecond":1642756430,"nanoOfSecond":923210700},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":62,"threadPriority":5,"who":"marku","what":"ObjectConsistencyCheckOperation","method":"-","parameters":"{dryRun=false,
> roots=[io.bdeploy/demo/client-app/linux:1.0.0,
> io.bdeploy/demo/client-app/linux:2.0.0,
> io.bdeploy/demo/client-app/windows:1.0.0, ...]}"}{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3358) 2.17.1: JsonLayout Context no longer working.
[
https://issues.apache.org/jira/browse/LOG4J2-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak resolved LOG4J2-3358.
--
Resolution: Fixed
> 2.17.1: JsonLayout Context no longer working.
> -
>
> Key: LOG4J2-3358
> URL: https://issues.apache.org/jira/browse/LOG4J2-3358
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.17.1
>Reporter: Markus Duft
>Assignee: Carter Kozak
>Priority: Major
>
> We're creating a RollingFileAppender programmatically using a JsonLayout.
> This uses fields using ${ctx:...} expansion. This stopped working when
> upgrading from 2.17.0 to 2.17.1.
> The code is as follows:
> {code:java}
> /**
> * Creates a rolling file appender that write audit entries to a
> programmatically readable JSON file.
> */
> private RollingFileAppender createJsonAppender(Path logDir) {
> List fields = new ArrayList<>();
>
> fields.add(KeyValuePair.newBuilder().setKey("who").setValue("${ctx:WHO}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("what").setValue("${ctx:WHAT}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("method").setValue("${ctx:METHOD}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("parameters").setValue("${ctx:PARAMETERS}").build());
>
> RollingFileAppender.Builder builder =
> RollingFileAppender.newBuilder();
> builder.setName("auditJsonLogger");
> builder.withFileName(logDir.resolve(LOG_JSON_FILENAME).toString());
>
> builder.withFilePattern(logDir.resolve(LOG_JSON_FILEPATTERN).toString());
> builder.withPolicy(SizeBasedTriggeringPolicy.createPolicy("10M"));
>
> builder.setLayout(JsonLayout.newBuilder().setCompact(true).setEventEol(true).setConfiguration(new
> DefaultConfiguration())
> .setAdditionalFields(fields.toArray(new
> KeyValuePair[0])).build());
> builder.withStrategy(
>
> DefaultRolloverStrategy.newBuilder().withCompressionLevelStr(String.valueOf(Deflater.DEFAULT_COMPRESSION))
>
> .withMax(Integer.toString(LOG_MAX_INDEX)).withFileIndex("min").build());
> return builder.build();
> } {code}
> We also tried to use %X\{...} as well as $${ctx:...} expansions instead to no
> avail. The log file always contains the *literal* string we use in
> .setValue(), i.e. lines like this:
> {noformat}
> {"instant":{"epochSecond":1642756242,"nanoOfSecond":271091900},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":65,"threadPriority":5,"who":"${ctx:WHO}","what":"${ctx:WHAT}","method":"${ctx:METHOD}","parameters":"${ctx:PARAMETERS}"}{noformat}
> Reverting to 2.17.0 will correctly give lines like this in the JSON file:
> {noformat}
> {"instant":{"epochSecond":1642756430,"nanoOfSecond":923210700},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":62,"threadPriority":5,"who":"marku","what":"ObjectConsistencyCheckOperation","method":"-","parameters":"{dryRun=false,
> roots=[io.bdeploy/demo/client-app/linux:1.0.0,
> io.bdeploy/demo/client-app/linux:2.0.0,
> io.bdeploy/demo/client-app/windows:1.0.0, ...]}"}{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3288) Interpolator non-plugin codepath doesn't include all log4j-core lookups
[
https://issues.apache.org/jira/browse/LOG4J2-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480303#comment-17480303
]
Carter Kozak commented on LOG4J2-3288:
--
[~rgoers] I'd like to reintroduce the reverted behavior based on
https://issues.apache.org/jira/browse/LOG4J2-3358 where the initial non-plugin
interpolator is still used throughout the configuration since it isn't created
based on nodes. There are several other places where new instances are created,
in which we'd expect them to support the full breadth of features.
PR is https://github.com/apache/logging-log4j2/pull/726
> Interpolator non-plugin codepath doesn't include all log4j-core lookups
> ---
>
> Key: LOG4J2-3288
> URL: https://issues.apache.org/jira/browse/LOG4J2-3288
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration, Core
>Affects Versions: 2.17.0
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
>
> It appears that {{bundle}} {{{}event{}}}, and {{sd}} lookups are not
> registered.
> There's a comment suggesting that the PluginManager could be used, however
> that will require additional validation before I'm comfortable enabling it:
> Logging initialization is very static and tricky, and it's easy to produce
> deadlocks when referencing logging code within initialization.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3358) 2.17.1: JsonLayout Context no longer working.
[
https://issues.apache.org/jira/browse/LOG4J2-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak reassigned LOG4J2-3358:
Assignee: Carter Kozak
> 2.17.1: JsonLayout Context no longer working.
> -
>
> Key: LOG4J2-3358
> URL: https://issues.apache.org/jira/browse/LOG4J2-3358
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.17.1
>Reporter: Markus Duft
>Assignee: Carter Kozak
>Priority: Major
>
> We're creating a RollingFileAppender programmatically using a JsonLayout.
> This uses fields using ${ctx:...} expansion. This stopped working when
> upgrading from 2.17.0 to 2.17.1.
> The code is as follows:
> {code:java}
> /**
> * Creates a rolling file appender that write audit entries to a
> programmatically readable JSON file.
> */
> private RollingFileAppender createJsonAppender(Path logDir) {
> List fields = new ArrayList<>();
>
> fields.add(KeyValuePair.newBuilder().setKey("who").setValue("${ctx:WHO}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("what").setValue("${ctx:WHAT}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("method").setValue("${ctx:METHOD}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("parameters").setValue("${ctx:PARAMETERS}").build());
>
> RollingFileAppender.Builder builder =
> RollingFileAppender.newBuilder();
> builder.setName("auditJsonLogger");
> builder.withFileName(logDir.resolve(LOG_JSON_FILENAME).toString());
>
> builder.withFilePattern(logDir.resolve(LOG_JSON_FILEPATTERN).toString());
> builder.withPolicy(SizeBasedTriggeringPolicy.createPolicy("10M"));
>
> builder.setLayout(JsonLayout.newBuilder().setCompact(true).setEventEol(true).setConfiguration(new
> DefaultConfiguration())
> .setAdditionalFields(fields.toArray(new
> KeyValuePair[0])).build());
> builder.withStrategy(
>
> DefaultRolloverStrategy.newBuilder().withCompressionLevelStr(String.valueOf(Deflater.DEFAULT_COMPRESSION))
>
> .withMax(Integer.toString(LOG_MAX_INDEX)).withFileIndex("min").build());
> return builder.build();
> } {code}
> We also tried to use %X\{...} as well as $${ctx:...} expansions instead to no
> avail. The log file always contains the *literal* string we use in
> .setValue(), i.e. lines like this:
> {noformat}
> {"instant":{"epochSecond":1642756242,"nanoOfSecond":271091900},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":65,"threadPriority":5,"who":"${ctx:WHO}","what":"${ctx:WHAT}","method":"${ctx:METHOD}","parameters":"${ctx:PARAMETERS}"}{noformat}
> Reverting to 2.17.0 will correctly give lines like this in the JSON file:
> {noformat}
> {"instant":{"epochSecond":1642756430,"nanoOfSecond":923210700},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":62,"threadPriority":5,"who":"marku","what":"ObjectConsistencyCheckOperation","method":"-","parameters":"{dryRun=false,
> roots=[io.bdeploy/demo/client-app/linux:1.0.0,
> io.bdeploy/demo/client-app/linux:2.0.0,
> io.bdeploy/demo/client-app/windows:1.0.0, ...]}"}{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3346) After 2.17.0 upgarde Route appenders with dynamic file writing are not working
[
https://issues.apache.org/jira/browse/LOG4J2-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak reassigned LOG4J2-3346:
Assignee: Carter Kozak
> After 2.17.0 upgarde Route appenders with dynamic file writing are not
> working
> ---
>
> Key: LOG4J2-3346
> URL: https://issues.apache.org/jira/browse/LOG4J2-3346
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.0
>Reporter: Nick Kom
>Assignee: Carter Kozak
>Priority: Major
>
> We switched from the version 2.11.1 to 2.17.0 and writing to separate files
> stopped working. Configuration log4j:
> {code:xml}
>
> ...
>
>
>
> fileName="${logPath}/task-${ctx:V_PID}.log"
>
> filePattern="${logArchPath}/task-${ctx:V_PID}-${archFile}"
> ignoreExceptions="false">
>
>
>
>
>
>
>
> ...
>
>
>
>
>
> {code}
> In code we use Slf4J logger (org.slf4j.Logger) and
> org.apache.logging.log4j.ThreadContext :
> {code:java}
> ThreadContext.put("V_PID", pid);
> org.slf4j.Logger logger
> =org.slf4j.LoggerFactory.getLogger(MessageFormat.format(...));
> {code}
> maven dependencies in pom.xml:
> {code:xml}
>
> 1.7.7
> 2.17.0
> ...
>
> org.slf4j
> slf4j-api
> ${slf4j.version}
>
>
> org.apache.logging.log4j
> log4j-slf4j-impl
> ${log4j2.version}
>
>
> org.apache.logging.log4j
> log4j-api
> ${log4j2.version}
>
>
> org.apache.logging.log4j
> log4j-core
> ${log4j2.version}
>
> ...
> {code}
> We use this in our web application which is deployed on Weblogic 12.2.1.0.0
> What can be wrong? Why aren't separate files (task-${ctx:V_PID}.log) created
> in the folder \{logPath}?
> Before library version 2.12.2 (inclusive),it's worked!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3317) After 2.17.1 upgarde, Route appenders with dynamic file writing are not working .
[
https://issues.apache.org/jira/browse/LOG4J2-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak reassigned LOG4J2-3317:
Assignee: Carter Kozak
> After 2.17.1 upgarde, Route appenders with dynamic file writing are not
> working .
> --
>
> Key: LOG4J2-3317
> URL: https://issues.apache.org/jira/browse/LOG4J2-3317
> Project: Log4j 2
> Issue Type: Bug
> Environment: spring boot log4j2.
> deployed on wildfly server.
>Reporter: Srinivasa Babu
>Assignee: Carter Kozak
>Priority: Major
>
> Hello Sir,
> With log4j2 2.13.3 , Route appenders with context pattern checks for dynamic
> file writing are working fine. After 2.17.1 the functionality is broken.
> I have upgraded to 2.17.1 and our java code, I am setting the ROUTINGKEY in
> threadcontext map. Also i set the system properties,
> log4j2.enableJndiLookup, log4j2.enableJndiJms, and
> log4j2.enableJndiContextSelector to true for all said tags after 2.17.1
> upgrade.
> When I check output file, its not writing the logs to Route File what we
> specify but general RollingFile logger appenders are working fine. Please let
> me know if you have faced this issue or any mitigation plan? Please let me
> know if you want any logs and i will share those if there is any specific
> procedure given.
>
> Calling the below Route from Async logging.
> here my example xml used the same as given in log4j2 documentaion.
>
> filePattern="./logs/${date:-MM}/default-%d\{-MM-dd}-%i.log.gz">
>
> %d\{ISO8601} [%t] %p %c\{3} - %m%n
>
>
>
>
>
>
>
>
> fileName="logs/other-${ctx:ROUTINGKEY}.log"
> filePattern="./logs/${date:-MM}/${ctx:ROUTINGKEY}{-}other{-}%d\{-MM-dd}-%i.log.gz">
>
> %d\{ISO8601} [%t] %p %c\{3} - %m%n
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3343) Add ability to use exclusion pattern filter on Map Resolver keys
[
https://issues.apache.org/jira/browse/LOG4J2-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17478722#comment-17478722
]
Carter Kozak commented on LOG4J2-3343:
--
I agree with Volkan here, I have a strong preference for simple minimal
components which can be easily understood used expressively. I could understand
if we decided for whatever reason that regex wasn't the correct primitive, and
wanted to use something else (which could express all possible regular
expressions), but I don't think that's the case here.
> Add ability to use exclusion pattern filter on Map Resolver keys
>
>
> Key: LOG4J2-3343
> URL: https://issues.apache.org/jira/browse/LOG4J2-3343
> Project: Log4j 2
> Issue Type: New Feature
> Components: JsonTemplateLayout
>Reporter: Matt Sicker
>Assignee: Matt Sicker
>Priority: Major
> Fix For: 2.17.2
>
>
> Map Resolver currently supports specifying a pattern to filter for allowed
> keys in the map being resolved. I'd like a complementary feature to specify a
> pattern to filter for excluded keys from the map being resolved. It may also
> be beneficial to provide a similar option for excluded keys as full string
> matches rather than always using a pattern.
> For an example use case, suppose I copy request HTTP header names and values
> into the ThreadContext for every request. In Spinnaker microservices, this
> includes custom headers like {{X-Spinnaker-Groups}} which contains a list of
> groups the authenticated user belongs to which are filled in by the Fiat
> microservice (used for integrating authentication and authorization with
> various providers and providing a facade over Spring Security). If I want to
> exclude this header from being logged, I can currently set a negative
> lookahead pattern like {{(?i(?!x-spinnaker-groups))}} which works effectively
> the same, but how many developers like reading regex incantations like these?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3333) Classloader deadlock in ThreadContextDataInjector
[
https://issues.apache.org/jira/browse/LOG4J2-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17478289#comment-17478289
]
Carter Kozak commented on LOG4J2-:
--
Thanks, [~rschmitt]! I'm working on a patch here:
[https://github.com/apache/logging-log4j2/pull/717]
Hoping to entirely remove the additional threads from the equation.
> Classloader deadlock in ThreadContextDataInjector
> -
>
> Key: LOG4J2-
> URL: https://issues.apache.org/jira/browse/LOG4J2-
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.1
>Reporter: Ryan Schmitt
>Assignee: Carter Kozak
>Priority: Major
>
> I ran into a deadlock involving {{ThreadContextDataInjector}} and the "Thread
> Context Data Task" background thread. The basic idea is that the "main"
> thread holds the classloader lock (since log4j2 is initialized during class
> loading, as a rule) and tries to acquire the provider lock, while the "Thread
> Context Data Task" thread holds the provider lock and tries to load classes:
> {code}
> Found one Java-level deadlock:
> =
> "Thread Context Data Task":
> waiting to lock monitor 0x7fde50835958 (object 0x00077bbf51c8, a
> org.powermock.core.classloader.MockClassLoader),
> which is held by "main"
> "main":
> waiting for ownable synchronizer 0x000773e77ae8, (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "Thread Context Data Task"
> Java stack information for the threads listed above:
> ===
> "Thread Context Data Task":
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.getServiceProviders(ThreadContextDataInjector.java:85)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.initServiceProviders(ThreadContextDataInjector.java:73)
> at
> org.apache.logging.log4j.core.LoggerContext$ThreadContextDataTask.run(LoggerContext.java:785)
> at java.lang.Thread.run(Thread.java:748)
> "main":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000773e77ae8> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.initServiceProviders(ThreadContextDataInjector.java:70)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.getProviders(ThreadContextDataInjector.java:285)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.access$000(ThreadContextDataInjector.java:55)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector$ForDefaultThreadContextMap.(ThreadContextDataInjector.java:108)
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createDefaultInjector(ContextDataInjectorFactory.java:91)
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createInjector(ContextDataInjectorFactory.java:71)
> at
> org.apache.logging.log4j.core.impl.Log4jLogEvent.(Log4jLogEvent.java:58)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:643)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:196)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter
[jira] [Assigned] (LOG4J2-3333) Classloader deadlock in ThreadContextDataInjector
[
https://issues.apache.org/jira/browse/LOG4J2-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak reassigned LOG4J2-:
Assignee: Carter Kozak
> Classloader deadlock in ThreadContextDataInjector
> -
>
> Key: LOG4J2-
> URL: https://issues.apache.org/jira/browse/LOG4J2-
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.1
>Reporter: Ryan Schmitt
>Assignee: Carter Kozak
>Priority: Major
>
> I ran into a deadlock involving {{ThreadContextDataInjector}} and the "Thread
> Context Data Task" background thread. The basic idea is that the "main"
> thread holds the classloader lock (since log4j2 is initialized during class
> loading, as a rule) and tries to acquire the provider lock, while the "Thread
> Context Data Task" thread holds the provider lock and tries to load classes:
> {code}
> Found one Java-level deadlock:
> =
> "Thread Context Data Task":
> waiting to lock monitor 0x7fde50835958 (object 0x00077bbf51c8, a
> org.powermock.core.classloader.MockClassLoader),
> which is held by "main"
> "main":
> waiting for ownable synchronizer 0x000773e77ae8, (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "Thread Context Data Task"
> Java stack information for the threads listed above:
> ===
> "Thread Context Data Task":
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.getServiceProviders(ThreadContextDataInjector.java:85)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.initServiceProviders(ThreadContextDataInjector.java:73)
> at
> org.apache.logging.log4j.core.LoggerContext$ThreadContextDataTask.run(LoggerContext.java:785)
> at java.lang.Thread.run(Thread.java:748)
> "main":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000773e77ae8> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.initServiceProviders(ThreadContextDataInjector.java:70)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.getProviders(ThreadContextDataInjector.java:285)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.access$000(ThreadContextDataInjector.java:55)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector$ForDefaultThreadContextMap.(ThreadContextDataInjector.java:108)
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createDefaultInjector(ContextDataInjectorFactory.java:91)
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createInjector(ContextDataInjectorFactory.java:71)
> at
> org.apache.logging.log4j.core.impl.Log4jLogEvent.(Log4jLogEvent.java:58)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:643)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:196)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:137)
> at
> org.apache.logging.log4j.jcl.LogAdapter.getContext(LogAdapter.java:40)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.jav
[jira] [Commented] (LOG4J2-3317) After 2.17.1 upgarde, Route appenders with dynamic file writing are not working .
[
https://issues.apache.org/jira/browse/LOG4J2-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17478198#comment-17478198
]
Carter Kozak commented on LOG4J2-3317:
--
Can you please provide the full contents of your configuration?
This document provides some details about the changes:
[https://github.com/apache/logging-log4j2/blob/release-2.x/docs/2.17.0-interpolation.md]
Only one level of interpolation is handled, so if you're referencing a property
from within a and that property includes something like
${ctx:SomeVariable}, it will not recursively be evaluated. You may need to
inline the value of the property into the route itself.
Without either a reproducer, or minimally a full copy of your configuration, I
cannot provide concrete advice.
> After 2.17.1 upgarde, Route appenders with dynamic file writing are not
> working .
> --
>
> Key: LOG4J2-3317
> URL: https://issues.apache.org/jira/browse/LOG4J2-3317
> Project: Log4j 2
> Issue Type: Bug
> Environment: spring boot log4j2.
> deployed on wildfly server.
>Reporter: Srinivasa Babu
>Priority: Major
>
> Hello Sir,
> With log4j2 2.13.3 , Route appenders with context pattern checks for dynamic
> file writing are working fine. After 2.17.1 the functionality is broken.
> I have upgraded to 2.17.1 and our java code, I am setting the ROUTINGKEY in
> threadcontext map. Also i set the system properties,
> log4j2.enableJndiLookup, log4j2.enableJndiJms, and
> log4j2.enableJndiContextSelector to true for all said tags after 2.17.1
> upgrade.
> When I check output file, its not writing the logs to Route File what we
> specify but general RollingFile logger appenders are working fine. Please let
> me know if you have faced this issue or any mitigation plan? Please let me
> know if you want any logs and i will share those if there is any specific
> procedure given.
>
> Calling the below Route from Async logging.
> here my example xml used the same as given in log4j2 documentaion.
>
> filePattern="./logs/${date:-MM}/default-%d\{-MM-dd}-%i.log.gz">
>
> %d\{ISO8601} [%t] %p %c\{3} - %m%n
>
>
>
>
>
>
>
>
> fileName="logs/other-${ctx:ROUTINGKEY}.log"
> filePattern="./logs/${date:-MM}/${ctx:ROUTINGKEY}{-}other{-}%d\{-MM-dd}-%i.log.gz">
>
> %d\{ISO8601} [%t] %p %c\{3} - %m%n
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3346) After 2.17.0 upgarde Route appenders with dynamic file writing are not working
[
https://issues.apache.org/jira/browse/LOG4J2-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17478077#comment-17478077
]
Carter Kozak commented on LOG4J2-3346:
--
Can you please provide the full contents of your configuration?
This document provides some details about the changes:
https://github.com/apache/logging-log4j2/blob/release-2.x/docs/2.17.0-interpolation.md
> After 2.17.0 upgarde Route appenders with dynamic file writing are not
> working
> ---
>
> Key: LOG4J2-3346
> URL: https://issues.apache.org/jira/browse/LOG4J2-3346
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.0
>Reporter: Nick Kom
>Priority: Major
>
> We switched from the version 2.11.1 to 2.17.0 and writing to separate files
> stopped working. Configuration log4j:
> {code:xml}
>
> ...
>
>
>
> fileName="${logPath}/task-${ctx:V_PID}.log"
>
> filePattern="${logArchPath}/task-${ctx:V_PID}-${archFile}"
> ignoreExceptions="false">
>
>
>
>
>
>
>
> ...
>
>
>
>
>
> {code}
> In code we use Slf4J logger (org.slf4j.Logger) and
> org.apache.logging.log4j.ThreadContext :
> {code:java}
> ThreadContext.put("V_PID", pid);
> org.slf4j.Logger logger
> =org.slf4j.LoggerFactory.getLogger(MessageFormat.format(...));
> {code}
> maven dependencies in pom.xml:
> {code:xml}
>
> 1.7.7
> 2.17.0
> ...
>
> org.slf4j
> slf4j-api
> ${slf4j.version}
>
>
> org.apache.logging.log4j
> log4j-slf4j-impl
> ${log4j2.version}
>
>
> org.apache.logging.log4j
> log4j-api
> ${log4j2.version}
>
>
> org.apache.logging.log4j
> log4j-core
> ${log4j2.version}
>
> ...
> {code}
> We use this in our web application which is deployed on Weblogic 12.2.1.0.0
> What can be wrong? Why aren't separate files (task-${ctx:V_PID}.log) created
> in the folder \{logPath}?
> Before library version 2.12.2 (inclusive),it's worked!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (LOG4J2-3345) log4j-jpl must handle parameters as MessageFormat args
[ https://issues.apache.org/jira/browse/LOG4J2-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carter Kozak closed LOG4J2-3345. > log4j-jpl must handle parameters as MessageFormat args > -- > > Key: LOG4J2-3345 > URL: https://issues.apache.org/jira/browse/LOG4J2-3345 > Project: Log4j 2 > Issue Type: Bug > Components: JPL Adapter >Affects Versions: 2.17.1 >Reporter: Carter Kozak >Assignee: Carter Kozak >Priority: Major > Fix For: 2.17.2 > > > Currently message parameters use the configured default messagefactory, which > provides no guarantees around the format used, however JPL API requires > MessageFormat style formatting. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3345) log4j-jpl must handle parameters as MessageFormat args
[ https://issues.apache.org/jira/browse/LOG4J2-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carter Kozak updated LOG4J2-3345: - Fix Version/s: 2.17.2 > log4j-jpl must handle parameters as MessageFormat args > -- > > Key: LOG4J2-3345 > URL: https://issues.apache.org/jira/browse/LOG4J2-3345 > Project: Log4j 2 > Issue Type: Bug > Components: JPL Adapter >Affects Versions: 2.17.1 >Reporter: Carter Kozak >Assignee: Carter Kozak >Priority: Major > Fix For: 2.17.2 > > > Currently message parameters use the configured default messagefactory, which > provides no guarantees around the format used, however JPL API requires > MessageFormat style formatting. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3345) log4j-jpl must handle parameters as MessageFormat args
[ https://issues.apache.org/jira/browse/LOG4J2-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carter Kozak resolved LOG4J2-3345. -- Resolution: Fixed > log4j-jpl must handle parameters as MessageFormat args > -- > > Key: LOG4J2-3345 > URL: https://issues.apache.org/jira/browse/LOG4J2-3345 > Project: Log4j 2 > Issue Type: Bug > Components: JPL Adapter >Affects Versions: 2.17.1 >Reporter: Carter Kozak >Assignee: Carter Kozak >Priority: Major > > Currently message parameters use the configured default messagefactory, which > provides no guarantees around the format used, however JPL API requires > MessageFormat style formatting. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (LOG4J2-3345) log4j-jpl must handle parameters as MessageFormat args
Carter Kozak created LOG4J2-3345: Summary: log4j-jpl must handle parameters as MessageFormat args Key: LOG4J2-3345 URL: https://issues.apache.org/jira/browse/LOG4J2-3345 Project: Log4j 2 Issue Type: Bug Components: JPL Adapter Affects Versions: 2.17.1 Reporter: Carter Kozak Assignee: Carter Kozak Currently message parameters use the configured default messagefactory, which provides no guarantees around the format used, however JPL API requires MessageFormat style formatting. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised
[
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17476415#comment-17476415
]
Carter Kozak commented on LOG4J2-3340:
--
pr#700 looks like a great usability improvement :)
> StatusLogger's log Level cannot be changed as advertised
>
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Michael Vorburger
>Priority: Major
> Fix For: 2.17.2
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation
> it picked, it multiple.
> I would like to be able to do this without a system property but using a
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you
> think it does, please suggest how.) I can see some stuff in StatusLogger
> related to its default log level been (only?) for StatusListener and
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised
[
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17476324#comment-17476324
]
Carter Kozak commented on LOG4J2-3340:
--
I have the following in one of my {{log4j2.StatusLogger.properties}}
configurations:
{noformat}
# simplelogStatusLoggerLevel applies only until the configuration is loaded
log4j2.simplelogStatusLoggerLevel = INFO{noformat}
I agree that it's confusing, it's odd because the configuration mutates the
global statuslogger config, however there may be zero to many configurations
and the last one to update "wins".
> StatusLogger's log Level cannot be changed as advertised
>
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Michael Vorburger
>Priority: Major
> Fix For: 2.17.2
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation
> it picked, it multiple.
> I would like to be able to do this without a system property but using a
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you
> think it does, please suggest how.) I can see some stuff in StatusLogger
> related to its default log level been (only?) for StatusListener and
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3331) After upgrading version 2.13, the className and lineNumber cannot be obtained
[
https://issues.apache.org/jira/browse/LOG4J2-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474641#comment-17474641
]
Carter Kozak commented on LOG4J2-3331:
--
Does your layout implement {{LocationAware}} and override the following?
{code:java}
@Override
public boolean requiresLocation() {
return true;
} {code}
I would also recommend a null check, because there are cases location info
cannot be collected.
> After upgrading version 2.13, the className and lineNumber cannot be obtained
> -
>
> Key: LOG4J2-3331
> URL: https://issues.apache.org/jira/browse/LOG4J2-3331
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.13.1, 2.17.0
>Reporter: Ning Ning Han
>Priority: Major
> Attachments: image-2022-01-12-23-34-25-594.png
>
>
> I upgraded the version of log4j to 2.13, which caused a problem as follows：
> 2022-01-12 23:29:09,846 Log4j2-TF-4-AsyncLoggerConfig-2 ERROR An exception
> occurred processing Appender Console java.lang.NullPointerException
> at
> com.test.lego.common.log.MyStandardLayout.toSerializable(MyStandardLayout.java:91)
> at
> com.test.lego.common.log.MyStandardLayout.toSerializable(MyStandardLayout.java:26)
> at
> org.apache.logging.log4j.core.layout.AbstractStringLayout.toByteArray(AbstractStringLayout.java:308)
> at
> org.apache.logging.log4j.core.layout.AbstractLayout.encode(AbstractLayout.java:210)
> at
> org.apache.logging.log4j.core.layout.AbstractLayout.encode(AbstractLayout.java:37)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.directEncodeEvent(AbstractOutputStreamAppender.java:197)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.tryAppend(AbstractOutputStreamAppender.java:190)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:181)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:543)
> at
> org.apache.logging.log4j.core.async.AsyncLoggerConfig.callAppenders(AsyncLoggerConfig.java:127)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:502)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:485)
> at
> org.apache.logging.log4j.core.async.AsyncLoggerConfig.log(AsyncLoggerConfig.java:121)
> at
> org.apache.logging.log4j.core.async.AsyncLoggerConfig.logToAsyncLoggerConfigsOnCurrentThread(AsyncLoggerConfig.java:169)
> at
> org.apache.logging.log4j.core.async.AsyncLoggerConfigDisruptor$Log4jEventWrapperHandler.onEvent(AsyncLoggerConfigDisruptor.java:111)
> at
> org.apache.logging.log4j.core.async.AsyncLoggerConfigDisruptor$Log4jEventWrapperHandler.onEvent(AsyncLoggerConfigDisruptor.java:97)
> at
> com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:169)
> at
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:126)
> at java.lang.Thread.run(Thread.java:748)
>
> key code of the MyStandardLayout :
> !image-2022-01-12-23-34-25-594.png!
> event.getSource is null
>
> This problem occurs in versions greater than 2.12
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3282) log4j-to-jul JDK Logging Bridge
[
https://issues.apache.org/jira/browse/LOG4J2-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak resolved LOG4J2-3282.
--
Fix Version/s: 2.17.2
Resolution: Fixed
> log4j-to-jul JDK Logging Bridge
> ---
>
> Key: LOG4J2-3282
> URL: https://issues.apache.org/jira/browse/LOG4J2-3282
> Project: Log4j 2
> Issue Type: Improvement
>Affects Versions: 2.17.0
>Reporter: Michael Vorburger
>Assignee: Michael Vorburger
>Priority: Major
> Fix For: 2.17.2
>
>
> I (we, internal project at work) would like to have a {{{}log4j-to-jul{}}}.
> So the "opposite" of [https://logging.apache.org/log4j/2.x/log4j-jul/] (from
> [https://github.com/apache/logging-log4j2/tree/master/log4j-jul]). The use
> case here is if one has an existing JUL-based set-up into which you would
> like to see logs from a library that has been coded against the Log4j API.
> Poking around
> [https://github.com/apache/logging-log4j2/tree/master/log4j-to-slf4j/src/main/java/org/apache/logging/slf4j],
> I hope this won't be very hard to do, unless I'm missing something. I want
> log4j-to-jul to only depend on log4j-api and nothing else, notably NOT
> log4j-core.
> Please assign this issue to me so that I can work on this and contribute it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (LOG4J2-3292) ExtendedLoggerWrapper.logMessage double-logs when location is requested
[ https://issues.apache.org/jira/browse/LOG4J2-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carter Kozak closed LOG4J2-3292. > ExtendedLoggerWrapper.logMessage double-logs when location is requested > --- > > Key: LOG4J2-3292 > URL: https://issues.apache.org/jira/browse/LOG4J2-3292 > Project: Log4j 2 > Issue Type: Bug > Components: API >Affects Versions: 2.17.0 >Reporter: Carter Kozak >Assignee: Carter Kozak >Priority: Major > Fix For: 2.17.1 > > > See https://github.com/apache/logging-log4j2/pull/667 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3292) ExtendedLoggerWrapper.logMessage double-logs when location is requested
[ https://issues.apache.org/jira/browse/LOG4J2-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carter Kozak resolved LOG4J2-3292. -- Resolution: Fixed > ExtendedLoggerWrapper.logMessage double-logs when location is requested > --- > > Key: LOG4J2-3292 > URL: https://issues.apache.org/jira/browse/LOG4J2-3292 > Project: Log4j 2 > Issue Type: Bug > Components: API >Affects Versions: 2.17.0 >Reporter: Carter Kozak >Assignee: Carter Kozak >Priority: Major > Fix For: 2.17.1 > > > See https://github.com/apache/logging-log4j2/pull/667 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (LOG4J2-3292) ExtendedLoggerWrapper.logMessage double-logs when location is requested
Carter Kozak created LOG4J2-3292: Summary: ExtendedLoggerWrapper.logMessage double-logs when location is requested Key: LOG4J2-3292 URL: https://issues.apache.org/jira/browse/LOG4J2-3292 Project: Log4j 2 Issue Type: Bug Components: API Affects Versions: 2.17.0 Reporter: Carter Kozak Assignee: Carter Kozak Fix For: 2.17.1 See https://github.com/apache/logging-log4j2/pull/667 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3289) log4j-to-slf4j should not re-format the result of Message.getFormattedMessage
[ https://issues.apache.org/jira/browse/LOG4J2-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carter Kozak reassigned LOG4J2-3289: Assignee: Carter Kozak > log4j-to-slf4j should not re-format the result of Message.getFormattedMessage > - > > Key: LOG4J2-3289 > URL: https://issues.apache.org/jira/browse/LOG4J2-3289 > Project: Log4j 2 > Issue Type: Bug > Components: SLF4J Bridge >Affects Versions: 2.17.0 >Reporter: Carter Kozak >Assignee: Carter Kozak >Priority: Major > Fix For: 2.17.1 > > > Both the formatted message result (for the configured MessageFactory) and the > parameter array are passed to slf4j, such that slf4j attempts to format the > already formatted result: > [https://github.com/apache/logging-log4j2/blob/20f9a97dbe5928c3b5077bcdd2a22ac92e941655/log4j-to-slf4j/src/main/java/org/apache/logging/slf4j/SLF4JLogger.java#L226-L256] > Caught a similar issue while reviewing this change, but realized it also > applies to the slf4j bridge: > [https://github.com/apache/logging-log4j2/pull/653#discussion_r775083351] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (LOG4J2-3289) log4j-to-slf4j should not re-format the result of Message.getFormattedMessage
[ https://issues.apache.org/jira/browse/LOG4J2-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carter Kozak closed LOG4J2-3289. > log4j-to-slf4j should not re-format the result of Message.getFormattedMessage > - > > Key: LOG4J2-3289 > URL: https://issues.apache.org/jira/browse/LOG4J2-3289 > Project: Log4j 2 > Issue Type: Bug > Components: SLF4J Bridge >Affects Versions: 2.17.0 >Reporter: Carter Kozak >Assignee: Carter Kozak >Priority: Major > Fix For: 2.17.1 > > > Both the formatted message result (for the configured MessageFactory) and the > parameter array are passed to slf4j, such that slf4j attempts to format the > already formatted result: > [https://github.com/apache/logging-log4j2/blob/20f9a97dbe5928c3b5077bcdd2a22ac92e941655/log4j-to-slf4j/src/main/java/org/apache/logging/slf4j/SLF4JLogger.java#L226-L256] > Caught a similar issue while reviewing this change, but realized it also > applies to the slf4j bridge: > [https://github.com/apache/logging-log4j2/pull/653#discussion_r775083351] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3289) log4j-to-slf4j should not re-format the result of Message.getFormattedMessage
[ https://issues.apache.org/jira/browse/LOG4J2-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carter Kozak resolved LOG4J2-3289. -- Resolution: Fixed > log4j-to-slf4j should not re-format the result of Message.getFormattedMessage > - > > Key: LOG4J2-3289 > URL: https://issues.apache.org/jira/browse/LOG4J2-3289 > Project: Log4j 2 > Issue Type: Bug > Components: SLF4J Bridge >Affects Versions: 2.17.0 >Reporter: Carter Kozak >Assignee: Carter Kozak >Priority: Major > Fix For: 2.17.1 > > > Both the formatted message result (for the configured MessageFactory) and the > parameter array are passed to slf4j, such that slf4j attempts to format the > already formatted result: > [https://github.com/apache/logging-log4j2/blob/20f9a97dbe5928c3b5077bcdd2a22ac92e941655/log4j-to-slf4j/src/main/java/org/apache/logging/slf4j/SLF4JLogger.java#L226-L256] > Caught a similar issue while reviewing this change, but realized it also > applies to the slf4j bridge: > [https://github.com/apache/logging-log4j2/pull/653#discussion_r775083351] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (LOG4J2-3289) log4j-to-slf4j should not re-format the result of Message.getFormattedMessage
Carter Kozak created LOG4J2-3289: Summary: log4j-to-slf4j should not re-format the result of Message.getFormattedMessage Key: LOG4J2-3289 URL: https://issues.apache.org/jira/browse/LOG4J2-3289 Project: Log4j 2 Issue Type: Bug Components: SLF4J Bridge Affects Versions: 2.17.0 Reporter: Carter Kozak Fix For: 2.17.1 Both the formatted message result (for the configured MessageFactory) and the parameter array are passed to slf4j, such that slf4j attempts to format the already formatted result: [https://github.com/apache/logging-log4j2/blob/20f9a97dbe5928c3b5077bcdd2a22ac92e941655/log4j-to-slf4j/src/main/java/org/apache/logging/slf4j/SLF4JLogger.java#L226-L256] Caught a similar issue while reviewing this change, but realized it also applies to the slf4j bridge: [https://github.com/apache/logging-log4j2/pull/653#discussion_r775083351] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3288) Interpolator non-plugin codepath doesn't include all log4j-core lookups
[
https://issues.apache.org/jira/browse/LOG4J2-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17465111#comment-17465111
]
Carter Kozak commented on LOG4J2-3288:
--
There are several other places which use this path to create a new
StrSubstitutor (or subclass) outside of the configuration, I'm think we want
those to support the full breadth of lookup types.
I'm experimenting with a change to avoid the dual-world approach and load all
plugins we detect here, which seems to pass tests:
[https://github.com/apache/logging-log4j2/pull/656]
> Interpolator non-plugin codepath doesn't include all log4j-core lookups
> ---
>
> Key: LOG4J2-3288
> URL: https://issues.apache.org/jira/browse/LOG4J2-3288
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration, Core
>Affects Versions: 2.17.0
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.1
>
>
> It appears that {{bundle}} {{{}event{}}}, and {{sd}} lookups are not
> registered.
> There's a comment suggesting that the PluginManager could be used, however
> that will require additional validation before I'm comfortable enabling it:
> Logging initialization is very static and tricky, and it's easy to produce
> deadlocks when referencing logging code within initialization.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (LOG4J2-3288) Interpolator non-plugin codepath doesn't include all log4j-core lookups
[
https://issues.apache.org/jira/browse/LOG4J2-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak closed LOG4J2-3288.
> Interpolator non-plugin codepath doesn't include all log4j-core lookups
> ---
>
> Key: LOG4J2-3288
> URL: https://issues.apache.org/jira/browse/LOG4J2-3288
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration, Core
>Affects Versions: 2.17.0
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.1
>
>
> It appears that {{bundle}} {{{}event{}}}, and {{sd}} lookups are not
> registered.
> There's a comment suggesting that the PluginManager could be used, however
> that will require additional validation before I'm comfortable enabling it:
> Logging initialization is very static and tricky, and it's easy to produce
> deadlocks when referencing logging code within initialization.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3288) Interpolator non-plugin codepath doesn't include all log4j-core lookups
[
https://issues.apache.org/jira/browse/LOG4J2-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak resolved LOG4J2-3288.
--
Resolution: Fixed
> Interpolator non-plugin codepath doesn't include all log4j-core lookups
> ---
>
> Key: LOG4J2-3288
> URL: https://issues.apache.org/jira/browse/LOG4J2-3288
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration, Core
>Affects Versions: 2.17.0
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.1
>
>
> It appears that {{bundle}} {{{}event{}}}, and {{sd}} lookups are not
> registered.
> There's a comment suggesting that the PluginManager could be used, however
> that will require additional validation before I'm comfortable enabling it:
> Logging initialization is very static and tricky, and it's easy to produce
> deadlocks when referencing logging code within initialization.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (LOG4J2-3288) Interpolator non-plugin codepath doesn't include all log4j-core lookups
Carter Kozak created LOG4J2-3288:
Summary: Interpolator non-plugin codepath doesn't include all
log4j-core lookups
Key: LOG4J2-3288
URL: https://issues.apache.org/jira/browse/LOG4J2-3288
Project: Log4j 2
Issue Type: Bug
Components: Configuration, Core
Affects Versions: 2.17.0
Reporter: Carter Kozak
Assignee: Carter Kozak
Fix For: 2.17.1
It appears that {{bundle}} {{{}event{}}}, and {{sd}} lookups are not registered.
There's a comment suggesting that the PluginManager could be used, however that
will require additional validation before I'm comfortable enabling it: Logging
initialization is very static and tricky, and it's easy to produce deadlocks
when referencing logging code within initialization.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3266) ${CTX :ThreadName} does not work
[
https://issues.apache.org/jira/browse/LOG4J2-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17465056#comment-17465056
]
Carter Kozak commented on LOG4J2-3266:
--
Not directly related to the reported problem, but you seem to be doing a
context-map lookup for a ThreadName property – if that's set from
{{java.lang.Thread.getName()}}, you may want to use {{${event:ThreadName}}}
instead, which uses the thread name associated with the LogEvent itself (no
interactions with the ThreadContext/MDC required).
> ${CTX :ThreadName} does not work
> --
>
> Key: LOG4J2-3266
> URL: https://issues.apache.org/jira/browse/LOG4J2-3266
> Project: Log4j 2
> Issue Type: Question
> Components: API
>Affects Versions: 2.17.0
>Reporter: wangbaohua
>Priority: Minor
>
> ${CTX :ThreadName} does not work at 2.17.0, but works fine below 2.16.0
> My configuration is as follows ：
> ---
>
>
>
>
>
>
>
> ${sys:logPath}
>
> 50M
>
> %d\{-MM-dd HH:mm:ss,SSS} %-5.5p [%t]
> %X\{codeline} -%m%n
>
> fatal
> warn
> debug
> info
> error
> trace
>
> summary
> 10
> ${LOG_HOME}/logs/log.error
> name="Thread_file">${LOG_HOME}/logs/log.${ctx:ThreadName}
> ${LOG_HOME}/logs/DLframe.log
> ${LOG_HOME}/logs/log.kafka
>
>
>
> KAFKA0:9092
>
> \{"time":"%d{-MM-dd
> HH:mm:ss}","App":"alarmEngine","hostName":"${env:HOSTNAME}","loggerName":"%c","line":"%L","level":"%p","thread":"%t","message":"%m"}
>
>
>
>
>
>
>
> filePattern="${LOG_HOME}/logs/log.error.%i">
>
>
>
>
>
>
>
>
>
>
>
>
> fileName="${Thread_file}"
> filePattern="${LOG_HOME}/logs/log.${ctx:ThreadName}.%i" append="true">
>
>
>
>
>
>
> onMismatch="NEUTRAL"/>
> onMismatch="NEUTRAL"/>
> onMismatch="NEUTRAL"/>
> onMismatch="NEUTRAL"/>
> onMismatch="NEUTRAL"/>
> onMismatch="DENY"/>
>
>
>
>
>
>
> filePattern="${LOG_HOME}/logs/DLframe.log.%i" append="true">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> filePattern="${LOG_HOME}/logs/log.kafka.%i" append="true">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> includeLocation="true">
>
>
>
>
>
> includeLocation="true">
>
>
>
>
>
>
> -
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3278) SpringLookup log4j2 2.17.0 version Invalidation
[
https://issues.apache.org/jira/browse/LOG4J2-3278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17465052#comment-17465052
]
Carter Kozak edited comment on LOG4J2-3278 at 12/24/21, 4:34 PM:
-
I think this may actually be the same issue as
https://issues.apache.org/jira/browse/LOG4J2-3204
The spring lookup package name was listed incorrectly, [~zhichun.zhang] can you
verify using the latest snapshot build?
(tagging [~vy] who may be interested in following)
was (Author: ckozak):
I think this may actually be the same issue as
https://issues.apache.org/jira/browse/LOG4J2-3204
The spring lookup package name was listed incorrectly, [~zhichun.zhang] can you
verify using the latest snapshot release?
(tagging [~vy] who may be interested in following)
> SpringLookup log4j2 2.17.0 version Invalidation
>
>
> Key: LOG4J2-3278
> URL: https://issues.apache.org/jira/browse/LOG4J2-3278
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.0
>Reporter: ZhangZhichun
>Priority: Major
> Attachments: JHJsonEventLayoutV1.json,
> image-2021-12-23-14-20-54-699.png, image-2021-12-23-14-22-17-392.png,
> image-2021-12-23-15-04-36-171.png, log-spring.xml
>
>
> SpringLookup 2.16.0 is ok,Invalid after update to 2.17.0.
> ${spring:spring.application.name} in log could not be resolved.
> my springboot version 2.4.12
> !image-2021-12-23-14-20-54-699.png!
> !image-2021-12-23-15-04-36-171.png!
> show log result:
> !image-2021-12-23-14-22-17-392.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3278) SpringLookup log4j2 2.17.0 version Invalidation
[
https://issues.apache.org/jira/browse/LOG4J2-3278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17465052#comment-17465052
]
Carter Kozak commented on LOG4J2-3278:
--
I think this may actually be the same issue as
https://issues.apache.org/jira/browse/LOG4J2-3204
The spring lookup package name was listed incorrectly, [~zhichun.zhang] can you
verify using the latest snapshot release?
(tagging [~vy] who may be interested in following)
> SpringLookup log4j2 2.17.0 version Invalidation
>
>
> Key: LOG4J2-3278
> URL: https://issues.apache.org/jira/browse/LOG4J2-3278
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.0
>Reporter: ZhangZhichun
>Priority: Major
> Attachments: JHJsonEventLayoutV1.json,
> image-2021-12-23-14-20-54-699.png, image-2021-12-23-14-22-17-392.png,
> image-2021-12-23-15-04-36-171.png, log-spring.xml
>
>
> SpringLookup 2.16.0 is ok,Invalid after update to 2.17.0.
> ${spring:spring.application.name} in log could not be resolved.
> my springboot version 2.4.12
> !image-2021-12-23-14-20-54-699.png!
> !image-2021-12-23-15-04-36-171.png!
> show log result:
> !image-2021-12-23-14-22-17-392.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3286) 2.17 has reverted LOG4J-2972 fix in AppenderControl but change not in history
[
https://issues.apache.org/jira/browse/LOG4J2-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17465049#comment-17465049
]
Carter Kozak commented on LOG4J2-3286:
--
> _Isn't catching Throwable considered a bad practice?_
I fear I provide this answer too frequently, but: It depends.
In most application code it's considered bad practice to catch and recover from
Error, however I wouldn't extend that to include infrastructure. I think the
answer is more obvious if you're writing a web-server: An Error should probably
result in a 500 response status, but not necessarily be allowed to terminate
the worker thread and terminate/leak the incoming connection. Similarly, when a
application code interacts with a logger, there's an expectation that it "just
works" (for some definition of works, it may or may not record data, but it
shouldn't throw!). Consider the following code block:
{code:java}
@Override
public void close() throws IOException {
log.debug("Closing {}", this);
releaseResources();
}{code}
I wouldn't want any sort of failure in log.debug to prevent
{{releaseResources()}} from being invoked!
The case is easier to make for some types of errors than others, but it's
easier to enumerate the types of errors we've seen in practice than those we
haven't.
Given log4j2 supports a wide range of plugins, some third-party plugins will
depend on other libraries that may be upgraded in ways that don't work at
runtime, throwing something like a NoClassDefFoundError or LinkageError. In
such a case, I'd still want the logging framework to continue processing my log
event, perhaps allowing it to be recorded by other appenders which aren't in a
broken state. If that's not what we're looking for, setting
{{ignore-exceptions="false"}} on the appender will allow exceptions to be
rethrown (although I expect they're caught again in AbstractLogger). You may
also consider using FailoverAppender with a synthetic appender (mocked?) and
use the interactions with the second appender to verify failures.
I broadened some of our catch blocks in 2.17.0 as a layer of defense in depth
against potential issues like CVE-2021-45105 – not as the primary protection,
we detect and avoid badness elsewhere, but if everything else goes wrong, the
logging framework should not be able to cause denial of service.
I've rambled long enough at this point, I hope my explanation was helpful :)
Let me know if you have further questions.
> 2.17 has reverted LOG4J-2972 fix in AppenderControl but change not in history
> -
>
> Key: LOG4J2-3286
> URL: https://issues.apache.org/jira/browse/LOG4J2-3286
> Project: Log4j 2
> Issue Type: Question
> Components: Appenders
>Affects Versions: 2.17.0
> Environment: Windows desktop running unit tests with log4j 2.17
>Reporter: Ben Thurley
>Priority: Major
>
> Upgrading to 2.17 to fix the slew of vulnerabilities has resulted in a change
> to error handling in the logs.
> Specifically in the class:
> org.apache.logging.log4j.core.config.AppenderControl
> There is a method called tryCallAppender() which as of 2.14.1 had been set to
> catch Exception. Looking at the history I can see no further changes to
> revert this to handling Throwable, however, comparing the source for 2.16.
> and 2.17 this is exactly what has changed.
> I don't believe this change should have reverted and if it should then why
> isn't there a commit for it in the history?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (LOG4J2-3286) 2.17 has reverted LOG4J-2972 fix in AppenderControl but change not in history
[ https://issues.apache.org/jira/browse/LOG4J2-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carter Kozak closed LOG4J2-3286. Resolution: Information Provided Closing as information provided. If there's a bug, please don't hesitate to let us know! > 2.17 has reverted LOG4J-2972 fix in AppenderControl but change not in history > - > > Key: LOG4J2-3286 > URL: https://issues.apache.org/jira/browse/LOG4J2-3286 > Project: Log4j 2 > Issue Type: Question > Components: Appenders >Affects Versions: 2.17.0 > Environment: Windows desktop running unit tests with log4j 2.17 >Reporter: Ben Thurley >Priority: Major > > Upgrading to 2.17 to fix the slew of vulnerabilities has resulted in a change > to error handling in the logs. > Specifically in the class: > org.apache.logging.log4j.core.config.AppenderControl > There is a method called tryCallAppender() which as of 2.14.1 had been set to > catch Exception. Looking at the history I can see no further changes to > revert this to handling Throwable, however, comparing the source for 2.16. > and 2.17 this is exactly what has changed. > I don't believe this change should have reverted and if it should then why > isn't there a commit for it in the history? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3286) 2.17 has reverted LOG4J-2972 fix in AppenderControl but change not in history
[ https://issues.apache.org/jira/browse/LOG4J2-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carter Kozak updated LOG4J2-3286: - Issue Type: Question (was: Bug) > 2.17 has reverted LOG4J-2972 fix in AppenderControl but change not in history > - > > Key: LOG4J2-3286 > URL: https://issues.apache.org/jira/browse/LOG4J2-3286 > Project: Log4j 2 > Issue Type: Question > Components: Appenders >Affects Versions: 2.17.0 > Environment: Windows desktop running unit tests with log4j 2.17 >Reporter: Ben Thurley >Priority: Major > > Upgrading to 2.17 to fix the slew of vulnerabilities has resulted in a change > to error handling in the logs. > Specifically in the class: > org.apache.logging.log4j.core.config.AppenderControl > There is a method called tryCallAppender() which as of 2.14.1 had been set to > catch Exception. Looking at the history I can see no further changes to > revert this to handling Throwable, however, comparing the source for 2.16. > and 2.17 this is exactly what has changed. > I don't believe this change should have reverted and if it should then why > isn't there a commit for it in the history? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3286) 2.17 has reverted LOG4J-2972 fix in AppenderControl but change not in history
[
https://issues.apache.org/jira/browse/LOG4J2-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17464765#comment-17464765
]
Carter Kozak commented on LOG4J2-3286:
--
The AsyncAppender fix (and tests which verify it) are still in the history and
passing. Is there a bug that you'd like to report? I admit I'm not sure what
you're asking.
You view the git history to a particular file like this:
{code:bash}
$ git log -p
./log4j-core/src/main/java/org/apache/logging/log4j/core/config/AppenderControl.java
commit 806023265f8c905b2dd1d81fd2458f64b2ea0b5e
Author: Carter Kozak
Date: Thu Dec 16 17:11:56 2021 -0500
Fix string substitution recursion
diff --git
a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AppenderControl.java
b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AppenderControl.java
index dc9d9900e..0c73a1f4b 100644
---
a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AppenderControl.java
+++
b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AppenderControl.java
@@ -161,8 +161,8 @@ public class AppenderControl extends AbstractFilterable {
appender.append(event);
} catch (final RuntimeException error) {
handleAppenderError(event, error);
-} catch (final Exception error) {
-handleAppenderError(event, new AppenderLoggingException(error));
+} catch (final Throwable throwable) {
+handleAppenderError(event, new
AppenderLoggingException(throwable));
}
}
commit 97ec707d69280ef57aed8fd5831dc4f3a75f7715
Author: Gary Gregory
Date: Wed Jul 28 11:05:20 2021 -0400
Add and resuse constants to avoid creating empty arrays over and over.
Also, the NoGcLayout was still allocating empty byte arrays for headers
and footers.
Full local build OK.
diff --git
a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AppenderControl.java
b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AppenderControl.java
index 58c1e5753..dc9d9900e 100644
---
a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AppenderControl.java
+++
b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AppenderControl.java
@@ -32,6 +32,11 @@ import org.apache.logging.log4j.util.PerformanceSensitive;
*/
public class AppenderControl extends AbstractFilterable {
+/**
+ * The empty array.
+ */
+static final AppenderControl[] EMPTY_ARRAY = {};
+
private final ThreadLocal recursive = new ThreadLocal<>();
private final Appender appender;
private final Level level;
commit 543bf6eacf174d7b64dc97442b65583baa67ea40
Author: Volkan Yazıcı
Date: Sat Jan 9 15:58:29 2021 +0100
LOG4J2-2972 Refactor AsyncAppender and AppenderControl for handling of
Throwables. (#452)
diff --git
a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AppenderControl.java
b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AppenderControl.java
index c5a0d2a26..58c1e5753 100644
---
a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AppenderControl.java
+++
b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AppenderControl.java
@@ -156,7 +156,7 @@ public class AppenderControl extends AbstractFilterable {
appender.append(event);
} catch (final RuntimeException error) {
handleAppenderError(event, error);
-} catch (final Throwable error) {
+} catch (final Exception error) {
handleAppenderError(event, new AppenderLoggingException(error));
}
}
commit 56436ad2176eac000d2821690e4373f097b76670
Author: Volkan Yazici
Date: Thu Nov 5 15:51:16 2020 +0100
Catch all type of exceptions in AppenderControl.
diff --git
a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AppenderControl.java
b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AppenderControl.java
index 8194ffc34..c5a0d2a26 100644
---
a/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AppenderControl.java
+++
b/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AppenderControl.java
@@ -154,10 +154,10 @@ public class AppenderControl extends AbstractFilterable {
private void tryCallAppender(final LogEvent event) {
try {
appender.append(event);
-} catch (final RuntimeException ex) {
-handleAppenderError(event, ex);
-} catch (final Exception ex) {
-handleAppenderError(event, new AppenderLoggingException(ex));
+} catch (final RuntimeException error) {
+handleAppenderError(event, error);
+} catch (final Throwable error) {
+handleAppenderError(event, new AppenderLoggingException(error));
}
}
{code}
> 2.17 has reverted LOG4J-2972 fix in AppenderControl but change not in history
> ---
[jira] [Resolved] (LOG4J2-3284) log4j-to-slf4j does not take the MessageFactory into account
[ https://issues.apache.org/jira/browse/LOG4J2-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carter Kozak resolved LOG4J2-3284. -- Resolution: Fixed > log4j-to-slf4j does not take the MessageFactory into account > > > Key: LOG4J2-3284 > URL: https://issues.apache.org/jira/browse/LOG4J2-3284 > Project: Log4j 2 > Issue Type: Bug > Components: SLF4J Bridge >Affects Versions: 2.17.0 >Reporter: Carter Kozak >Assignee: Carter Kozak >Priority: Major > Fix For: 2.17.1 > > > SLF4JLoggerContext.getLogger(String,MessageFactory) fails to take the > MessageFactory argument into account. > https://github.com/apache/logging-log4j2/pull/651 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (LOG4J2-3284) log4j-to-slf4j does not take the MessageFactory into account
[ https://issues.apache.org/jira/browse/LOG4J2-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carter Kozak closed LOG4J2-3284. Thanks for the contribution! > log4j-to-slf4j does not take the MessageFactory into account > > > Key: LOG4J2-3284 > URL: https://issues.apache.org/jira/browse/LOG4J2-3284 > Project: Log4j 2 > Issue Type: Bug > Components: SLF4J Bridge >Affects Versions: 2.17.0 >Reporter: Carter Kozak >Assignee: Carter Kozak >Priority: Major > Fix For: 2.17.1 > > > SLF4JLoggerContext.getLogger(String,MessageFactory) fails to take the > MessageFactory argument into account. > https://github.com/apache/logging-log4j2/pull/651 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3264) MapLookup should lookup MapMessage before properties
[
https://issues.apache.org/jira/browse/LOG4J2-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak resolved LOG4J2-3264.
--
Fix Version/s: 2.17.1
Resolution: Fixed
Please verify and close
> MapLookup should lookup MapMessage before properties
>
>
> Key: LOG4J2-3264
> URL: https://issues.apache.org/jira/browse/LOG4J2-3264
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Yanming Zhou
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.1
>
>
> According to
> [https://logging.apache.org/log4j/2.x/manual/lookups.html#MapLookup]
> {quote}
> Note that when used this way a value for "type" should be declared in the
> properties declaration to provide a default value in case the message is not
> a MapMessage or the MapMessage does not contain the key.
> {quote}
> If "type" is present with a MapMessage, then it will be picked not default
> value in the properties declaration, but the code show that the default value
> is always picked.
> [https://github.com/apache/logging-log4j2/blob/20f9a97dbe5928c3b5077bcdd2a22ac92e941655/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/MapLookup.java#L89-L104]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3284) log4j-to-slf4j does not take the MessageFactory into account
[ https://issues.apache.org/jira/browse/LOG4J2-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17464714#comment-17464714 ] Carter Kozak commented on LOG4J2-3284: -- I don't believe this Jira configuration allows us to assign tickets to folks who aren't committers. > log4j-to-slf4j does not take the MessageFactory into account > > > Key: LOG4J2-3284 > URL: https://issues.apache.org/jira/browse/LOG4J2-3284 > Project: Log4j 2 > Issue Type: Bug > Components: SLF4J Bridge >Affects Versions: 2.17.0 >Reporter: Carter Kozak >Assignee: Carter Kozak >Priority: Major > Fix For: 2.17.1 > > > SLF4JLoggerContext.getLogger(String,MessageFactory) fails to take the > MessageFactory argument into account. > https://github.com/apache/logging-log4j2/pull/651 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (LOG4J2-3284) log4j-to-slf4j does not take the MessageFactory into account
Carter Kozak created LOG4J2-3284: Summary: log4j-to-slf4j does not take the MessageFactory into account Key: LOG4J2-3284 URL: https://issues.apache.org/jira/browse/LOG4J2-3284 Project: Log4j 2 Issue Type: Bug Components: SLF4J Bridge Affects Versions: 2.17.0 Reporter: Carter Kozak Fix For: 2.17.1 SLF4JLoggerContext.getLogger(String,MessageFactory) fails to take the MessageFactory argument into account. https://github.com/apache/logging-log4j2/pull/651 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3284) log4j-to-slf4j does not take the MessageFactory into account
[ https://issues.apache.org/jira/browse/LOG4J2-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carter Kozak reassigned LOG4J2-3284: Assignee: Carter Kozak > log4j-to-slf4j does not take the MessageFactory into account > > > Key: LOG4J2-3284 > URL: https://issues.apache.org/jira/browse/LOG4J2-3284 > Project: Log4j 2 > Issue Type: Bug > Components: SLF4J Bridge >Affects Versions: 2.17.0 >Reporter: Carter Kozak >Assignee: Carter Kozak >Priority: Major > Fix For: 2.17.1 > > > SLF4JLoggerContext.getLogger(String,MessageFactory) fails to take the > MessageFactory argument into account. > https://github.com/apache/logging-log4j2/pull/651 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3278) SpringLookup log4j2 2.17.0 version Invalidation
[
https://issues.apache.org/jira/browse/LOG4J2-3278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17464709#comment-17464709
]
Carter Kozak commented on LOG4J2-3278:
--
In 2.17.0 we limited recursive evaluation of lookups at runtime. It would be
easier for me to confirm if you can post your entire logging configuration. I
have described the changes and their potential impacts in a post here:
https://github.com/apache/logging-log4j2/blob/release-2.x/docs/2.17.0-interpolation.md
[~richardgomez] This is not related to JNDI protocol restrictions.
> SpringLookup log4j2 2.17.0 version Invalidation
>
>
> Key: LOG4J2-3278
> URL: https://issues.apache.org/jira/browse/LOG4J2-3278
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.0
>Reporter: ZhangZhichun
>Priority: Major
> Attachments: image-2021-12-23-14-20-54-699.png,
> image-2021-12-23-14-22-17-392.png, image-2021-12-23-15-04-36-171.png
>
>
> SpringLookup 2.16.0 is ok,Invalid after update to 2.17.0.
> ${spring:spring.application.name} in log could not be resolved.
> my springboot version 2.4.12
> !image-2021-12-23-14-20-54-699.png!
> !image-2021-12-23-15-04-36-171.png!
> show log result:
> !image-2021-12-23-14-22-17-392.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3283) Add error-prone to build
[ https://issues.apache.org/jira/browse/LOG4J2-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17464702#comment-17464702 ] Carter Kozak commented on LOG4J2-3283: -- Yes, several years ago I added it to the master branch, but never back ported to release-2.x. Given we currently release the release-2.x branch (not master), I agree it makes more sense there. > Add error-prone to build > > > Key: LOG4J2-3283 > URL: https://issues.apache.org/jira/browse/LOG4J2-3283 > Project: Log4j 2 > Issue Type: Improvement > Components: Build >Reporter: Michael Vorburger >Priority: Major > > Would this project, the Log4j community, welcome a contribution to add > [https://errorprone.info|https://errorprone.info/] ? > The work would include [https://errorprone.info/docs/installation] and fixing > any warnings and errors found one time. > Contributors and committers would then have an additional quality check, > similar to Spotbugs & PMD which I can see you are already using. > Error Prone is [already used by many project at the > ASF|https://issues.apache.org/jira/issues/?jql=text%20~%20%22error-prone%22]. > I personally [led the integration of Error Prone into Apache > Fineract|https://issues.apache.org/jira/issues/?jql=text%20~%20%22error-prone%22%20and%20project%20%3D%20%22Apache%20Fineract%22%20]. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3258) RollingFile fileName containing variables does not work on 2.17.0
[
https://issues.apache.org/jira/browse/LOG4J2-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17464649#comment-17464649
]
Carter Kozak commented on LOG4J2-3258:
--
I've added a document with some background context as well as specific examples
here:
https://github.com/apache/logging-log4j2/blob/release-2.x/docs/2.17.0-interpolation.md
> RollingFile fileName containing variables does not work on 2.17.0
> -
>
> Key: LOG4J2-3258
> URL: https://issues.apache.org/jira/browse/LOG4J2-3258
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.0
> Environment: Java 17, Ubuntu 20.04.
>Reporter: Konstantinos Liakos
>Priority: Major
> Attachments: log4j2-appender-routing.xml, log4j2.xml
>
>
> A configuration like the below has stopped working since 2.17.0. The
> variables that originate from are not resolved to their actual
> values.
> {code:xml}
> $${env:LOGS_DIRECTORY} {code}
> {code:xml}
> fileName="${logs_dir}/${ctx:logFile}"{code}
>
> Works fine on 2.16.0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (LOG4J2-3270) Interpolator defaults should use only configuration properties
[ https://issues.apache.org/jira/browse/LOG4J2-3270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carter Kozak closed LOG4J2-3270. > Interpolator defaults should use only configuration properties > -- > > Key: LOG4J2-3270 > URL: https://issues.apache.org/jira/browse/LOG4J2-3270 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.17.0 >Reporter: Carter Kozak >Assignee: Carter Kozak >Priority: Major > Fix For: 2.17.1 > > > The MapLookup is currently used, but it should check MapMessage prior to the > property fallback, however that would have consequences in places the > properties are used as a simple place to define reusable values. -- This message was sent by Atlassian Jira (v8.20.1#820001)
