[GitHub] [logging-log4j2] dfa1 commented on pull request #770: Initial support for detached markers in SLF4J binding
dfa1 commented on pull request #770: URL: https://github.com/apache/logging-log4j2/pull/770#issuecomment-1047476853 @garydgregory thank you for the review... please have a look now, I wrote few unit tests -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (LOG4J2-3410) Log4j 1.2 bridge throws a ClassCastException when logging a Map with non-String keys
[
https://issues.apache.org/jira/browse/LOG4J2-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495819#comment-17495819
]
Barry Sham edited comment on LOG4J2-3410 at 2/22/22, 1:58 AM:
--
Dear [~ggregory] and [~ppkarwasz],
We updated our testing repo to test MultiKeyMap with nested objects including
null value:
[shin779/log4j-multikeymap
(github.com)|https://github.com/shin779/log4j-multikeymap]
With combination of 2.17.2 snapshots below:
* log4j-1.2-api-2.17.2-20220221.163807-124.jar
* log4j-api-2.17.2-20220221.163807-115.jar
* log4j-core-2.17.2-20220221.163807-112.jar
It is confirmed the debug message can be logged without Exception.
We will keep track the status and update our library after the change released.
Thanks for making the world better.
was (Author: bcfsham):
Dear [~ggregory] and [~ppkarwasz],
We updated our testing repo to test MultiKeyMap with nested objects including
null value:
[shin779/log4j-multikeymap
(github.com)|https://github.com/shin779/log4j-multikeymap]
With combination of 2.17.2 snapshots below:
* log4j-1.2-api-2.17.2-20220221.163807-124.jar
* log4j-api-2.17.2-20220221.163807-115.jar
* log4j-core-2.17.2-20220221.163807-112.jar
It is confirmed the out debug message can be logged without Exception.
We will keep track the status and update our library after the change released.
Thanks for making the world better.
> Log4j 1.2 bridge throws a ClassCastException when logging a Map with
> non-String keys
>
>
> Key: LOG4J2-3410
> URL: https://issues.apache.org/jira/browse/LOG4J2-3410
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.13.0, 2.17.1
> Environment: OS: Windows 10 Enterprise 64bit
> Java version: zulu8.31.0.1-jdk8.0.181-win_x64{*}{*}
>Reporter: Barry Sham
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> Our existing business logic contains a debug message which print out a
> {_}org.apache.commons.collections.map.MultiKeyMap{_}:
>
> {code:java}
> MultiKeyMap prnMap = MultiKeyMap.decorate(new LinkedMap());
> prnMap.put("0", "1", "2");
> logger.debug(prnMap);
> {code}
>
> in {*}log4j-1.2-api 2.12.4{*}, it can be print out
> {color:#4c9aff}properly{color}:
>
> {code:java}
> {MultiKey[0, 1]=2}{code}
>
> However it becomes an {color:#FF}ClassCastException {color}+since
> *2.13.0* (including the latest {*}2.17.1{*})+
> {code:java}
> Exception in thread "main" java.lang.ClassCastException:
> org.apache.commons.collections.keyvalue.MultiKey cannot be cast to
> java.lang.String
> at
> org.apache.logging.log4j.util.SortedArrayStringMap.(SortedArrayStringMap.java:154)
> at org.apache.logging.log4j.message.MapMessage.(MapMessage.java:125)
> at org.apache.log4j.Category.maybeLog(Category.java:507)
> at org.apache.log4j.Category.debug(Category.java:243)
> at sideproject.sideproject.App.proeces(App.java:25)
> at sideproject.sideproject.App.main(App.java:17){code}
> As the map can print out using *System.out* +without issue,+ we are wondering
> if it is a bug in Apache Log4j 1.x Compatibility API
> A GitHub Project is prepared for reference: [shin779/log4j-multikeymap
> (github.com)|https://github.com/shin779/log4j-multikeymap]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3410) Log4j 1.2 bridge throws a ClassCastException when logging a Map with non-String keys
[
https://issues.apache.org/jira/browse/LOG4J2-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495819#comment-17495819
]
Barry Sham commented on LOG4J2-3410:
Dear [~ggregory] and [~ppkarwasz],
We updated our testing repo to test MultiKeyMap with nested objects including
null value:
[shin779/log4j-multikeymap
(github.com)|https://github.com/shin779/log4j-multikeymap]
With combination of 2.17.2 snapshots below:
* log4j-1.2-api-2.17.2-20220221.163807-124.jar
* log4j-api-2.17.2-20220221.163807-115.jar
* log4j-core-2.17.2-20220221.163807-112.jar
It is confirmed the out debug message can be logged without Exception.
We will keep track the status and update our library after the change released.
Thanks for making the world better.
> Log4j 1.2 bridge throws a ClassCastException when logging a Map with
> non-String keys
>
>
> Key: LOG4J2-3410
> URL: https://issues.apache.org/jira/browse/LOG4J2-3410
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.13.0, 2.17.1
> Environment: OS: Windows 10 Enterprise 64bit
> Java version: zulu8.31.0.1-jdk8.0.181-win_x64{*}{*}
>Reporter: Barry Sham
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> Our existing business logic contains a debug message which print out a
> {_}org.apache.commons.collections.map.MultiKeyMap{_}:
>
> {code:java}
> MultiKeyMap prnMap = MultiKeyMap.decorate(new LinkedMap());
> prnMap.put("0", "1", "2");
> logger.debug(prnMap);
> {code}
>
> in {*}log4j-1.2-api 2.12.4{*}, it can be print out
> {color:#4c9aff}properly{color}:
>
> {code:java}
> {MultiKey[0, 1]=2}{code}
>
> However it becomes an {color:#FF}ClassCastException {color}+since
> *2.13.0* (including the latest {*}2.17.1{*})+
> {code:java}
> Exception in thread "main" java.lang.ClassCastException:
> org.apache.commons.collections.keyvalue.MultiKey cannot be cast to
> java.lang.String
> at
> org.apache.logging.log4j.util.SortedArrayStringMap.(SortedArrayStringMap.java:154)
> at org.apache.logging.log4j.message.MapMessage.(MapMessage.java:125)
> at org.apache.log4j.Category.maybeLog(Category.java:507)
> at org.apache.log4j.Category.debug(Category.java:243)
> at sideproject.sideproject.App.proeces(App.java:25)
> at sideproject.sideproject.App.main(App.java:17){code}
> As the map can print out using *System.out* +without issue,+ we are wondering
> if it is a bug in Apache Log4j 1.x Compatibility API
> A GitHub Project is prepared for reference: [shin779/log4j-multikeymap
> (github.com)|https://github.com/shin779/log4j-multikeymap]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4cxx] LeeGDavis commented on pull request #105: Prevent static initialization order faults by using local statics
LeeGDavis commented on pull request #105: URL: https://github.com/apache/logging-log4cxx/pull/105#issuecomment-1047317100 Thanks @rm5248. I'll give that a try. I'll see what I can do about a test case too. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4cxx] rm5248 commented on pull request #105: Prevent static initialization order faults by using local statics
rm5248 commented on pull request #105: URL: https://github.com/apache/logging-log4cxx/pull/105#issuecomment-1047304623 You could try using a vcpkg overlay to build a custom version of log4cxx. See the [vcpkg documentation](https://github.com/microsoft/vcpkg/blob/master/docs/specifications/ports-overlay.md) for more information on that. I think that you can just copy the [provided portfiles](https://github.com/microsoft/vcpkg/tree/master/ports/log4cxx) and point it at a specific tag/URL if you need to. Ultimately this is a rather complicated thing to solve, and there's really not much we can do to fix it - applications need to make sure that things shutdown correctly. If you do have a specific test case though, that would be useful. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4cxx] LeeGDavis commented on pull request #105: Prevent static initialization order faults by using local statics
LeeGDavis commented on pull request #105: URL: https://github.com/apache/logging-log4cxx/pull/105#issuecomment-1047299349 I think we're running into this issue after and upgrade to 0.12.1 from 0.11.0. Is there any way to tests this or what is currently in [apache:next_stable](https://github.com/apache/logging-log4cxx/tree/next_stable) using vcpkg? Happy to contribute any feedback. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-chainsaw] rm5248 opened a new pull request #11: Remove log4j1
rm5248 opened a new pull request #11: URL: https://github.com/apache/logging-chainsaw/pull/11 Remove the hard dependency on log4j1. General changes: - Removed database stuff for the time being - Created a new `ChainsawLoggingEvent` to be independent of log4j1 - Changed build so it plays nicely with netbeans Known issues: - Can crash when loading some things from old chainsaw config files. You may need to remove your ~/.chainsaw directory(or just delete all java serialized objects in this directory) - Documentation for receivers does not show up when configuring a receiver. This needs to be made better in general since showing the javadoc is kinda cool but also pretty useless. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on a change in pull request #769: Slf4j binding minor cleanups
garydgregory commented on a change in pull request #769:
URL: https://github.com/apache/logging-log4j2/pull/769#discussion_r811446174
##
File path:
log4j-slf4j-impl/src/main/java/org/apache/logging/slf4j/Log4jMDCAdapter.java
##
@@ -52,8 +52,7 @@ public void clear() {
}
@Override
-@SuppressWarnings("unchecked") // nothing we can do about this, restricted
by SLF4J API
-public void setContextMap(@SuppressWarnings("rawtypes") final Map map) {
+public void setContextMap(final Map map) {
Review comment:
Seems ok then. Thank you for the info.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] dfa1 commented on a change in pull request #769: Slf4j binding minor cleanups
dfa1 commented on a change in pull request #769:
URL: https://github.com/apache/logging-log4j2/pull/769#discussion_r811438451
##
File path:
log4j-slf4j-impl/src/main/java/org/apache/logging/slf4j/Log4jMDCAdapter.java
##
@@ -52,8 +52,7 @@ public void clear() {
}
@Override
-@SuppressWarnings("unchecked") // nothing we can do about this, restricted
by SLF4J API
-public void setContextMap(@SuppressWarnings("rawtypes") final Map map) {
+public void setContextMap(final Map map) {
Review comment:
thanks for your time! :-)
Given that SLF4J interface is:
```
public void setContextMap(Map contextMap);
```
I don't know if this is really a problem... however, I can easily revert :)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] dfa1 commented on a change in pull request #769: Slf4j binding minor cleanups
dfa1 commented on a change in pull request #769:
URL: https://github.com/apache/logging-log4j2/pull/769#discussion_r811438451
##
File path:
log4j-slf4j-impl/src/main/java/org/apache/logging/slf4j/Log4jMDCAdapter.java
##
@@ -52,8 +52,7 @@ public void clear() {
}
@Override
-@SuppressWarnings("unchecked") // nothing we can do about this, restricted
by SLF4J API
-public void setContextMap(@SuppressWarnings("rawtypes") final Map map) {
+public void setContextMap(final Map map) {
Review comment:
thanks for your time! :-)
Given that SLF4J interface is:
```
public void setContextMap(Map contextMap);
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #770: Initial support for detached markers in SLF4J binding
garydgregory commented on pull request #770: URL: https://github.com/apache/logging-log4j2/pull/770#issuecomment-1047241499 Hi @dfa1 Thank you for the PR. You will need to add tests to this PR to prove the code does what you say it does. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] dfa1 opened a new pull request #770: Initial support for detached markers in SLF4J binding
dfa1 opened a new pull request #770: URL: https://github.com/apache/logging-log4j2/pull/770 Hello all, please accept this small patch from a long time user of log4j: it will enable using log4j 2.x in several applications here at @six-group! This proposal allows creating detached `Markers` as specified by the `IMarkerFactory` interface. A detached marker allows the caller to inject non-constant data that can be used to implement structured logging (my use-case). Because of this, they cannot be cached in `Log4jMarkerFactory.markerMap` or converted. Please let me know if you require additional modifications (e.g. unit tests perhaps?) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on a change in pull request #769: Slf4j binding minor cleanups
garydgregory commented on a change in pull request #769:
URL: https://github.com/apache/logging-log4j2/pull/769#discussion_r811434361
##
File path:
log4j-slf4j-impl/src/main/java/org/apache/logging/slf4j/Log4jMDCAdapter.java
##
@@ -52,8 +52,7 @@ public void clear() {
}
@Override
-@SuppressWarnings("unchecked") // nothing we can do about this, restricted
by SLF4J API
-public void setContextMap(@SuppressWarnings("rawtypes") final Map map) {
+public void setContextMap(final Map map) {
Review comment:
This will break source compatibility, does it matter?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (LOG4J2-3393) JSON template layout performance regression
[
https://issues.apache.org/jira/browse/LOG4J2-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495763#comment-17495763
]
ASF subversion and git services commented on LOG4J2-3393:
-
Commit e7d40044157c0e19f9a1e89d1a0f1b8615c80237 in logging-log4j2's branch
refs/heads/LOG4J2-3393 from Volkan Yazici
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=e7d4004 ]
LOG4J2-3393 Remove redundant branching in JsonTemplateLayout.
> JSON template layout performance regression
> ---
>
> Key: LOG4J2-3393
> URL: https://issues.apache.org/jira/browse/LOG4J2-3393
> Project: Log4j 2
> Issue Type: Improvement
> Components: JsonTemplateLayout
>Affects Versions: 2.17.1
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> JTL performance is used to be on par with \{{log4j2-ecs-layout}}, though this
> is not the case anymore, there is a slight degradation. This story aims to
> investigate what is going on and fix it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3393) JSON template layout performance regression
[
https://issues.apache.org/jira/browse/LOG4J2-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495764#comment-17495764
]
ASF subversion and git services commented on LOG4J2-3393:
-
Commit 510606eab351270ecc646bbf7f88ca105f9dca84 in logging-log4j2's branch
refs/heads/LOG4J2-3393 from Volkan Yazici
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=510606e ]
LOG4J2-3393 Inline context acquisition in JsonTemplateLayout.
> JSON template layout performance regression
> ---
>
> Key: LOG4J2-3393
> URL: https://issues.apache.org/jira/browse/LOG4J2-3393
> Project: Log4j 2
> Issue Type: Improvement
> Components: JsonTemplateLayout
>Affects Versions: 2.17.1
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> JTL performance is used to be on par with \{{log4j2-ecs-layout}}, though this
> is not the case anymore, there is a slight degradation. This story aims to
> investigate what is going on and fix it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] dfa1 opened a new pull request #769: Slf4j binding minor cleanups
dfa1 opened a new pull request #769: URL: https://github.com/apache/logging-log4j2/pull/769 Minor cleanups in SLF4J bindings Including removal of [SLF4JLoggingException](https://github.com/apache/logging-log4j2/commit/d993a4faf17c1e5380e0eb87c02ee9d69318eb68) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] ppkarwasz opened a new pull request #768: Improves behavior of failing Log4j 1.x builders
ppkarwasz opened a new pull request #768: URL: https://github.com/apache/logging-log4j2/pull/768 If a Builder fails due to a missing property, it return `null`. This activates the fallback _"instantiate by class name"_ mechanism that will fail with `NoClassDefFoundException` in the best scenario or will instantiate a native Log4j 1.x component in the worst scenario. A better approach, IMHO, is to an empty wrapper, which deactivates the fallback mechanism, but will be unwrapped to `null` soon after and removed from the configuration. This PR also increases the level of status logger messages to `ERROR` if the condition prevents the instantiation of the component. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #764: Log4j 1.2 bridge supports global threshold
garydgregory commented on pull request #764: URL: https://github.com/apache/logging-log4j2/pull/764#issuecomment-1047183989 @ppkarwasz Thank you for your PR. If you are looking for more fixes to investigate, please have a look at the disabled tests in `org.apache.log4j.xml.DOMTestCase`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] garydgregory merged pull request #764: Adds Log4j 1.x global threshold
garydgregory merged pull request #764: URL: https://github.com/apache/logging-log4j2/pull/764 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LOG4J2-3407) PropertiesConfiguration.parseAppender NPE when logger refers to non-existent appender
[
https://issues.apache.org/jira/browse/LOG4J2-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495733#comment-17495733
]
ASF subversion and git services commented on LOG4J2-3407:
-
Commit 362fe76dff4310836ee3c6d111d895fda97831c1 in logging-log4j2's branch
refs/heads/release-2.x from Gary Gregory
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=362fe76 ]
[LOG4J2-3407] Log4j 1.2 bridge Check for non-existent appender when
parsing properties #761.
> PropertiesConfiguration.parseAppender NPE when logger refers to non-existent
> appender
> -
>
> Key: LOG4J2-3407
> URL: https://issues.apache.org/jira/browse/LOG4J2-3407
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
>Reporter: Kenny MacLeod
>Priority: Minor
> Fix For: 2.17.2
>
> Attachments: LOG4J2-3407.patch
>
>
> When parsing a {{log4j.proprties}} file that contains a logger that refers to
> a non-existent appender, you get a NPE.
> While this is clearly a malformed configuration, Log4j 1.2.x silently ignored
> this, and the log4j2 bridge should be as tolerant.
> Note that {{PropertiesConfiguration#parseLogger}} is already tolerant of the
> appender being missing (it does a null check on the result of
> {{{}parseAppender{}}}), but {{parseAppender}} itself is not tolerant.
> An example config would be:
> {noformat}
> log4j.logger.mylogger=INFO, myappender
> # log4j.appender.myappender=org.apache.log4j.ConsoleAppender
> {noformat}
> The appender has been commented out, to illustrate the bug.
> Stack trace from log4j 2.17.1:
> {noformat}
> Caused by: java.lang.NullPointerException
> at
> org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:72)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:428)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:406)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLoggers(PropertiesConfiguration.java:351)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:304)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:93)
> at
> org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:60)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:293)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:626)
> 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.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:55)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:47)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:33)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:363)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:388)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] ppkarwasz commented on a change in pull request #767: Provide a uniform Log4j 1.x message factory
ppkarwasz commented on a change in pull request #767:
URL: https://github.com/apache/logging-log4j2/pull/767#discussion_r811369316
##
File path:
log4j-api/src/main/java/org/apache/logging/log4j/util/SortedArrayStringMap.java
##
@@ -128,6 +128,21 @@
private boolean immutable;
private transient boolean iterating;
+/**
+ * Transforms a generic map to a {@link StringMap} by mapping the keys to
+ * {@link String}.
+ *
+ * @param map a generic map
+ * @return a {@link StringMap}
+ */
+public static SortedArrayStringMap fromGenericMap(final Map map) {
Review comment:
@garydgregory: after your fix it is not needed anymore.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on a change in pull request #767: [LOG4J2-3410] Fix ClassCastException when key is not a string
garydgregory commented on a change in pull request #767:
URL: https://github.com/apache/logging-log4j2/pull/767#discussion_r811358091
##
File path:
log4j-api/src/main/java/org/apache/logging/log4j/util/SortedArrayStringMap.java
##
@@ -128,6 +128,21 @@
private boolean immutable;
private transient boolean iterating;
+/**
+ * Transforms a generic map to a {@link StringMap} by mapping the keys to
+ * {@link String}.
+ *
+ * @param map a generic map
+ * @return a {@link StringMap}
+ */
+public static SortedArrayStringMap fromGenericMap(final Map map) {
Review comment:
I don't think this is needed, would you check your tests against HEAD,
without any main changes?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Resolved] (LOG4J2-3407) PropertiesConfiguration.parseAppender NPE when logger refers to non-existent appender
[
https://issues.apache.org/jira/browse/LOG4J2-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LOG4J2-3407.
-
Fix Version/s: 2.17.2
Resolution: Fixed
[~kennymacleod.atl]
In git branch {{{}release-2.x{}}}.
Please verify and close this ticket.
TY!
> PropertiesConfiguration.parseAppender NPE when logger refers to non-existent
> appender
> -
>
> Key: LOG4J2-3407
> URL: https://issues.apache.org/jira/browse/LOG4J2-3407
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
>Reporter: Kenny MacLeod
>Priority: Minor
> Fix For: 2.17.2
>
> Attachments: LOG4J2-3407.patch
>
>
> When parsing a {{log4j.proprties}} file that contains a logger that refers to
> a non-existent appender, you get a NPE.
> While this is clearly a malformed configuration, Log4j 1.2.x silently ignored
> this, and the log4j2 bridge should be as tolerant.
> Note that {{PropertiesConfiguration#parseLogger}} is already tolerant of the
> appender being missing (it does a null check on the result of
> {{{}parseAppender{}}}), but {{parseAppender}} itself is not tolerant.
> An example config would be:
> {noformat}
> log4j.logger.mylogger=INFO, myappender
> # log4j.appender.myappender=org.apache.log4j.ConsoleAppender
> {noformat}
> The appender has been commented out, to illustrate the bug.
> Stack trace from log4j 2.17.1:
> {noformat}
> Caused by: java.lang.NullPointerException
> at
> org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:72)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:428)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:406)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLoggers(PropertiesConfiguration.java:351)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:304)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:93)
> at
> org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:60)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:293)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:626)
> 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.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:55)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:47)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:33)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:363)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:388)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] garydgregory merged pull request #761: LOG4J2-3407 Log4j 1.2 bridge Check for non-existent appender when parsing properties
garydgregory merged pull request #761: URL: https://github.com/apache/logging-log4j2/pull/761 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LOG4J2-3407) PropertiesConfiguration.parseAppender NPE when logger refers to non-existent appender
[
https://issues.apache.org/jira/browse/LOG4J2-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495621#comment-17495621
]
ASF subversion and git services commented on LOG4J2-3407:
-
Commit 14fa165935faca61f5dc168a70925c87555e4cca in logging-log4j2's branch
refs/heads/release-2.x from Kenny MacLeod
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=14fa165 ]
LOG4J2-3407 Check for non-existent appender when parsing properties (#761)
> PropertiesConfiguration.parseAppender NPE when logger refers to non-existent
> appender
> -
>
> Key: LOG4J2-3407
> URL: https://issues.apache.org/jira/browse/LOG4J2-3407
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
>Reporter: Kenny MacLeod
>Priority: Minor
> Attachments: LOG4J2-3407.patch
>
>
> When parsing a {{log4j.proprties}} file that contains a logger that refers to
> a non-existent appender, you get a NPE.
> While this is clearly a malformed configuration, Log4j 1.2.x silently ignored
> this, and the log4j2 bridge should be as tolerant.
> Note that {{PropertiesConfiguration#parseLogger}} is already tolerant of the
> appender being missing (it does a null check on the result of
> {{{}parseAppender{}}}), but {{parseAppender}} itself is not tolerant.
> An example config would be:
> {noformat}
> log4j.logger.mylogger=INFO, myappender
> # log4j.appender.myappender=org.apache.log4j.ConsoleAppender
> {noformat}
> The appender has been commented out, to illustrate the bug.
> Stack trace from log4j 2.17.1:
> {noformat}
> Caused by: java.lang.NullPointerException
> at
> org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:72)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:428)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:406)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLoggers(PropertiesConfiguration.java:351)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:304)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:93)
> at
> org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:60)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:293)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:626)
> 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.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:55)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:47)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:33)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:363)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:388)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3410) Log4j 1.2 bridge throws a ClassCastException when logging a Map with non-String keys
[
https://issues.apache.org/jira/browse/LOG4J2-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LOG4J2-3410.
-
Fix Version/s: 2.17.2
Resolution: Fixed
Hi [~bcfsham] ,
Thank you for reporting your issue. I fixed this in the {{release-2.x}} branch
in git. Please try a local build or a snapshot build from
[https://repository.apache.org/content/repositories/snapshots/]
It appears that the message logged might be a bit odd depending on the kind of
{{Map}} logged. See the new test for details:
{{/log4j-1.2-api/src/test/java/org/apache/log4j/LoggerJira3410Test.java}}
> Log4j 1.2 bridge throws a ClassCastException when logging a Map with
> non-String keys
>
>
> Key: LOG4J2-3410
> URL: https://issues.apache.org/jira/browse/LOG4J2-3410
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.13.0, 2.17.1
> Environment: OS: Windows 10 Enterprise 64bit
> Java version: zulu8.31.0.1-jdk8.0.181-win_x64{*}{*}
>Reporter: Barry Sham
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> Our existing business logic contains a debug message which print out a
> {_}org.apache.commons.collections.map.MultiKeyMap{_}:
>
> {code:java}
> MultiKeyMap prnMap = MultiKeyMap.decorate(new LinkedMap());
> prnMap.put("0", "1", "2");
> logger.debug(prnMap);
> {code}
>
> in {*}log4j-1.2-api 2.12.4{*}, it can be print out
> {color:#4c9aff}properly{color}:
>
> {code:java}
> {MultiKey[0, 1]=2}{code}
>
> However it becomes an {color:#FF}ClassCastException {color}+since
> *2.13.0* (including the latest {*}2.17.1{*})+
> {code:java}
> Exception in thread "main" java.lang.ClassCastException:
> org.apache.commons.collections.keyvalue.MultiKey cannot be cast to
> java.lang.String
> at
> org.apache.logging.log4j.util.SortedArrayStringMap.(SortedArrayStringMap.java:154)
> at org.apache.logging.log4j.message.MapMessage.(MapMessage.java:125)
> at org.apache.log4j.Category.maybeLog(Category.java:507)
> at org.apache.log4j.Category.debug(Category.java:243)
> at sideproject.sideproject.App.proeces(App.java:25)
> at sideproject.sideproject.App.main(App.java:17){code}
> As the map can print out using *System.out* +without issue,+ we are wondering
> if it is a bug in Apache Log4j 1.x Compatibility API
> A GitHub Project is prepared for reference: [shin779/log4j-multikeymap
> (github.com)|https://github.com/shin779/log4j-multikeymap]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3410) Log4j 1.2 bridge throws a ClassCastException when logging a Map with non-String keys
[
https://issues.apache.org/jira/browse/LOG4J2-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495617#comment-17495617
]
ASF subversion and git services commented on LOG4J2-3410:
-
Commit 51da8e2a50a841bbe1aafe929e3ef29d2f3aa1f2 in logging-log4j2's branch
refs/heads/release-2.x from Gary Gregory
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=51da8e2 ]
[LOG4J2-3410] Log4j 1.2 bridge throws a ClassCastException when logging
a Map with non-String keys.
> Log4j 1.2 bridge throws a ClassCastException when logging a Map with
> non-String keys
>
>
> Key: LOG4J2-3410
> URL: https://issues.apache.org/jira/browse/LOG4J2-3410
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.13.0, 2.17.1
> Environment: OS: Windows 10 Enterprise 64bit
> Java version: zulu8.31.0.1-jdk8.0.181-win_x64{*}{*}
>Reporter: Barry Sham
>Assignee: Gary D. Gregory
>Priority: Major
>
> Our existing business logic contains a debug message which print out a
> {_}org.apache.commons.collections.map.MultiKeyMap{_}:
>
> {code:java}
> MultiKeyMap prnMap = MultiKeyMap.decorate(new LinkedMap());
> prnMap.put("0", "1", "2");
> logger.debug(prnMap);
> {code}
>
> in {*}log4j-1.2-api 2.12.4{*}, it can be print out
> {color:#4c9aff}properly{color}:
>
> {code:java}
> {MultiKey[0, 1]=2}{code}
>
> However it becomes an {color:#FF}ClassCastException {color}+since
> *2.13.0* (including the latest {*}2.17.1{*})+
> {code:java}
> Exception in thread "main" java.lang.ClassCastException:
> org.apache.commons.collections.keyvalue.MultiKey cannot be cast to
> java.lang.String
> at
> org.apache.logging.log4j.util.SortedArrayStringMap.(SortedArrayStringMap.java:154)
> at org.apache.logging.log4j.message.MapMessage.(MapMessage.java:125)
> at org.apache.log4j.Category.maybeLog(Category.java:507)
> at org.apache.log4j.Category.debug(Category.java:243)
> at sideproject.sideproject.App.proeces(App.java:25)
> at sideproject.sideproject.App.main(App.java:17){code}
> As the map can print out using *System.out* +without issue,+ we are wondering
> if it is a bug in Apache Log4j 1.x Compatibility API
> A GitHub Project is prepared for reference: [shin779/log4j-multikeymap
> (github.com)|https://github.com/shin779/log4j-multikeymap]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work started] (LOG4J2-3410) Log4j 1.2 bridge throws a ClassCastException when logging a Map with non-String keys
[
https://issues.apache.org/jira/browse/LOG4J2-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on LOG4J2-3410 started by Gary D. Gregory.
---
> Log4j 1.2 bridge throws a ClassCastException when logging a Map with
> non-String keys
>
>
> Key: LOG4J2-3410
> URL: https://issues.apache.org/jira/browse/LOG4J2-3410
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.13.0, 2.17.1
> Environment: OS: Windows 10 Enterprise 64bit
> Java version: zulu8.31.0.1-jdk8.0.181-win_x64{*}{*}
>Reporter: Barry Sham
>Assignee: Gary D. Gregory
>Priority: Major
>
> Our existing business logic contains a debug message which print out a
> {_}org.apache.commons.collections.map.MultiKeyMap{_}:
>
> {code:java}
> MultiKeyMap prnMap = MultiKeyMap.decorate(new LinkedMap());
> prnMap.put("0", "1", "2");
> logger.debug(prnMap);
> {code}
>
> in {*}log4j-1.2-api 2.12.4{*}, it can be print out
> {color:#4c9aff}properly{color}:
>
> {code:java}
> {MultiKey[0, 1]=2}{code}
>
> However it becomes an {color:#FF}ClassCastException {color}+since
> *2.13.0* (including the latest {*}2.17.1{*})+
> {code:java}
> Exception in thread "main" java.lang.ClassCastException:
> org.apache.commons.collections.keyvalue.MultiKey cannot be cast to
> java.lang.String
> at
> org.apache.logging.log4j.util.SortedArrayStringMap.(SortedArrayStringMap.java:154)
> at org.apache.logging.log4j.message.MapMessage.(MapMessage.java:125)
> at org.apache.log4j.Category.maybeLog(Category.java:507)
> at org.apache.log4j.Category.debug(Category.java:243)
> at sideproject.sideproject.App.proeces(App.java:25)
> at sideproject.sideproject.App.main(App.java:17){code}
> As the map can print out using *System.out* +without issue,+ we are wondering
> if it is a bug in Apache Log4j 1.x Compatibility API
> A GitHub Project is prepared for reference: [shin779/log4j-multikeymap
> (github.com)|https://github.com/shin779/log4j-multikeymap]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3410) Log4j 1.2 bridge throws a ClassCastException when logging a Map with non-String keys
[
https://issues.apache.org/jira/browse/LOG4J2-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory reassigned LOG4J2-3410:
---
Assignee: Gary D. Gregory
> Log4j 1.2 bridge throws a ClassCastException when logging a Map with
> non-String keys
>
>
> Key: LOG4J2-3410
> URL: https://issues.apache.org/jira/browse/LOG4J2-3410
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.13.0, 2.17.1
> Environment: OS: Windows 10 Enterprise 64bit
> Java version: zulu8.31.0.1-jdk8.0.181-win_x64{*}{*}
>Reporter: Barry Sham
>Assignee: Gary D. Gregory
>Priority: Major
>
> Our existing business logic contains a debug message which print out a
> {_}org.apache.commons.collections.map.MultiKeyMap{_}:
>
> {code:java}
> MultiKeyMap prnMap = MultiKeyMap.decorate(new LinkedMap());
> prnMap.put("0", "1", "2");
> logger.debug(prnMap);
> {code}
>
> in {*}log4j-1.2-api 2.12.4{*}, it can be print out
> {color:#4c9aff}properly{color}:
>
> {code:java}
> {MultiKey[0, 1]=2}{code}
>
> However it becomes an {color:#FF}ClassCastException {color}+since
> *2.13.0* (including the latest {*}2.17.1{*})+
> {code:java}
> Exception in thread "main" java.lang.ClassCastException:
> org.apache.commons.collections.keyvalue.MultiKey cannot be cast to
> java.lang.String
> at
> org.apache.logging.log4j.util.SortedArrayStringMap.(SortedArrayStringMap.java:154)
> at org.apache.logging.log4j.message.MapMessage.(MapMessage.java:125)
> at org.apache.log4j.Category.maybeLog(Category.java:507)
> at org.apache.log4j.Category.debug(Category.java:243)
> at sideproject.sideproject.App.proeces(App.java:25)
> at sideproject.sideproject.App.main(App.java:17){code}
> As the map can print out using *System.out* +without issue,+ we are wondering
> if it is a bug in Apache Log4j 1.x Compatibility API
> A GitHub Project is prepared for reference: [shin779/log4j-multikeymap
> (github.com)|https://github.com/shin779/log4j-multikeymap]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3410) Log4j 1.x Compatibility API - ClassCastException when logging a Map with non-String keys
[
https://issues.apache.org/jira/browse/LOG4J2-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LOG4J2-3410:
Summary: Log4j 1.x Compatibility API - ClassCastException when logging a
Map with non-String keys (was: Log4j 1.x Compatibility API -
ClassCastException when logging MultiKeyMap)
> Log4j 1.x Compatibility API - ClassCastException when logging a Map with
> non-String keys
>
>
> Key: LOG4J2-3410
> URL: https://issues.apache.org/jira/browse/LOG4J2-3410
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.13.0, 2.17.1
> Environment: OS: Windows 10 Enterprise 64bit
> Java version: zulu8.31.0.1-jdk8.0.181-win_x64{*}{*}
>Reporter: Barry Sham
>Priority: Major
>
> Our existing business logic contains a debug message which print out a
> {_}org.apache.commons.collections.map.MultiKeyMap{_}:
>
> {code:java}
> MultiKeyMap prnMap = MultiKeyMap.decorate(new LinkedMap());
> prnMap.put("0", "1", "2");
> logger.debug(prnMap);
> {code}
>
> in {*}log4j-1.2-api 2.12.4{*}, it can be print out
> {color:#4c9aff}properly{color}:
>
> {code:java}
> {MultiKey[0, 1]=2}{code}
>
> However it becomes an {color:#FF}ClassCastException {color}+since
> *2.13.0* (including the latest {*}2.17.1{*})+
> {code:java}
> Exception in thread "main" java.lang.ClassCastException:
> org.apache.commons.collections.keyvalue.MultiKey cannot be cast to
> java.lang.String
> at
> org.apache.logging.log4j.util.SortedArrayStringMap.(SortedArrayStringMap.java:154)
> at org.apache.logging.log4j.message.MapMessage.(MapMessage.java:125)
> at org.apache.log4j.Category.maybeLog(Category.java:507)
> at org.apache.log4j.Category.debug(Category.java:243)
> at sideproject.sideproject.App.proeces(App.java:25)
> at sideproject.sideproject.App.main(App.java:17){code}
> As the map can print out using *System.out* +without issue,+ we are wondering
> if it is a bug in Apache Log4j 1.x Compatibility API
> A GitHub Project is prepared for reference: [shin779/log4j-multikeymap
> (github.com)|https://github.com/shin779/log4j-multikeymap]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3410) Log4j 1.2 bridge throws a ClassCastException when logging a Map with non-String keys
[
https://issues.apache.org/jira/browse/LOG4J2-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LOG4J2-3410:
Summary: Log4j 1.2 bridge throws a ClassCastException when logging a Map
with non-String keys (was: Log4j 1.x Compatibility API - ClassCastException
when logging a Map with non-String keys)
> Log4j 1.2 bridge throws a ClassCastException when logging a Map with
> non-String keys
>
>
> Key: LOG4J2-3410
> URL: https://issues.apache.org/jira/browse/LOG4J2-3410
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.13.0, 2.17.1
> Environment: OS: Windows 10 Enterprise 64bit
> Java version: zulu8.31.0.1-jdk8.0.181-win_x64{*}{*}
>Reporter: Barry Sham
>Priority: Major
>
> Our existing business logic contains a debug message which print out a
> {_}org.apache.commons.collections.map.MultiKeyMap{_}:
>
> {code:java}
> MultiKeyMap prnMap = MultiKeyMap.decorate(new LinkedMap());
> prnMap.put("0", "1", "2");
> logger.debug(prnMap);
> {code}
>
> in {*}log4j-1.2-api 2.12.4{*}, it can be print out
> {color:#4c9aff}properly{color}:
>
> {code:java}
> {MultiKey[0, 1]=2}{code}
>
> However it becomes an {color:#FF}ClassCastException {color}+since
> *2.13.0* (including the latest {*}2.17.1{*})+
> {code:java}
> Exception in thread "main" java.lang.ClassCastException:
> org.apache.commons.collections.keyvalue.MultiKey cannot be cast to
> java.lang.String
> at
> org.apache.logging.log4j.util.SortedArrayStringMap.(SortedArrayStringMap.java:154)
> at org.apache.logging.log4j.message.MapMessage.(MapMessage.java:125)
> at org.apache.log4j.Category.maybeLog(Category.java:507)
> at org.apache.log4j.Category.debug(Category.java:243)
> at sideproject.sideproject.App.proeces(App.java:25)
> at sideproject.sideproject.App.main(App.java:17){code}
> As the map can print out using *System.out* +without issue,+ we are wondering
> if it is a bug in Apache Log4j 1.x Compatibility API
> A GitHub Project is prepared for reference: [shin779/log4j-multikeymap
> (github.com)|https://github.com/shin779/log4j-multikeymap]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] ppkarwasz commented on a change in pull request #767: [LOG4J2-3410] Fix ClassCastException when key is not a string
ppkarwasz commented on a change in pull request #767:
URL: https://github.com/apache/logging-log4j2/pull/767#discussion_r811231397
##
File path: log4j-1.2-api/src/main/java/org/apache/log4j/Category.java
##
@@ -309,15 +309,10 @@ private void fireRemoveAppenderEvent(final Appender
appender) {
public void forcedLog(final String fqcn, final Priority level, final
Object message, final Throwable t) {
final org.apache.logging.log4j.Level lvl =
org.apache.logging.log4j.Level.toLevel(level.toString());
+final Message msg = LegacyMessageFactory.INSTANCE.newMessage(message);
if (logger instanceof ExtendedLogger) {
-@SuppressWarnings("unchecked")
-final Message msg = message instanceof Message ? (Message) message
-: message instanceof Map ? new MapMessage((Map) message) : new
ObjectMessage(message);
((ExtendedLogger) logger).logMessage(fqcn, lvl, null, msg, t);
} else {
-final ObjectRenderer renderer = get(message.getClass());
-final Message msg = message instanceof Message ? (Message) message
-: renderer != null ? new RenderedMessage(renderer, message) :
new ObjectMessage(message);
Review comment:
The `RenderedMessage` case is omitted, since this would require a
stateful `MessageFactory` (per category).
Anyway there is currently no way to add elements to the `RendererMap`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] ppkarwasz opened a new pull request #767: [LOG4J2-3410] Fix ClassCastException when key is not a string
ppkarwasz opened a new pull request #767: URL: https://github.com/apache/logging-log4j2/pull/767 This PR provides a `MessageFactory` that decides the type of message based on the runtime type of the logged object (cf. [LOG4J2-3080](https://issues.apache.org/jira/browse/LOG4J2-3080)). If the logged object is a map, it is converted into a `StringMap` in a typesafe way. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LOG4J2-3409) workaround for jackson-mapper-asl-1.9.13.jar security vulnerability @ flume-ng
[ https://issues.apache.org/jira/browse/LOG4J2-3409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495574#comment-17495574 ] Ralph Goers commented on LOG4J2-3409: - I had hoped it would have been out weeks ago, but after so long without a release getting Flume's dependencies updated has been a challenge. I had to come back to work on Log4j to get its next release out. I believe I have most of the hard stuff done but it is impossible to say since there are still a few dependencies I have yet to investigate. Unlike Log4j, right now I am pretty much the only one working on Flume. > workaround for jackson-mapper-asl-1.9.13.jar security vulnerability @ flume-ng > -- > > Key: LOG4J2-3409 > URL: https://issues.apache.org/jira/browse/LOG4J2-3409 > Project: Log4j 2 > Issue Type: Bug > Components: Flume Appender >Affects Versions: 2.17.1 > Environment: java 11 >Reporter: alexander kravchik >Priority: Major > > Dear colleagues, > we are using log4j2 with flume-ng appender. > The below vulnerabilities are found in the dependent > jackson-mapper-asl-1.9.13.jar : > cve-2019-10202 > cve-2019-10172 > etc... > Please advise if this will be fixed and planned ETA in case it is already > fixed > Thanks , > Sasha -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3409) workaround for jackson-mapper-asl-1.9.13.jar security vulnerability @ flume-ng
[ https://issues.apache.org/jira/browse/LOG4J2-3409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495563#comment-17495563 ] alexander kravchik commented on LOG4J2-3409: ok great news - do you have estimation when it will be released ? > workaround for jackson-mapper-asl-1.9.13.jar security vulnerability @ flume-ng > -- > > Key: LOG4J2-3409 > URL: https://issues.apache.org/jira/browse/LOG4J2-3409 > Project: Log4j 2 > Issue Type: Bug > Components: Flume Appender >Affects Versions: 2.17.1 > Environment: java 11 >Reporter: alexander kravchik >Priority: Major > > Dear colleagues, > we are using log4j2 with flume-ng appender. > The below vulnerabilities are found in the dependent > jackson-mapper-asl-1.9.13.jar : > cve-2019-10202 > cve-2019-10172 > etc... > Please advise if this will be fixed and planned ETA in case it is already > fixed > Thanks , > Sasha -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3409) workaround for jackson-mapper-asl-1.9.13.jar security vulnerability @ flume-ng
[ https://issues.apache.org/jira/browse/LOG4J2-3409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495528#comment-17495528 ] Ralph Goers commented on LOG4J2-3409: - The thing is, once Flume 1.10.0 is released Log4J will upgrade to use it and this problem will go away. Creating an issue for Flume is kind of pointless since I am just going to close it since it has already been fixed. I just need the time to finish the other dependency upgrades and get a release pit. > workaround for jackson-mapper-asl-1.9.13.jar security vulnerability @ flume-ng > -- > > Key: LOG4J2-3409 > URL: https://issues.apache.org/jira/browse/LOG4J2-3409 > Project: Log4j 2 > Issue Type: Bug > Components: Flume Appender >Affects Versions: 2.17.1 > Environment: java 11 >Reporter: alexander kravchik >Priority: Major > > Dear colleagues, > we are using log4j2 with flume-ng appender. > The below vulnerabilities are found in the dependent > jackson-mapper-asl-1.9.13.jar : > cve-2019-10202 > cve-2019-10172 > etc... > Please advise if this will be fixed and planned ETA in case it is already > fixed > Thanks , > Sasha -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [logging-log4j2] ruhulmus edited a comment on pull request #763: Added java logging with Asynchronous logger
ruhulmus edited a comment on pull request #763: URL: https://github.com/apache/logging-log4j2/pull/763#issuecomment-1046775984 > @ruhulmus If this is an example for people, showing them how to use Async logging, then what would be the best place so that people can easily find it? Maybe in the docs? What does it add that the existing docs are missing? (And would it be an idea to improve the existing docs, if that is the case.) @remkop, I have moved the project under the Docs directory and made detailed documentation with examples for the user's better understanding. I believe it will be helpful for the community. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] ruhulmus commented on pull request #763: Added java logging with Asynchronous logger
ruhulmus commented on pull request #763: URL: https://github.com/apache/logging-log4j2/pull/763#issuecomment-1046775984 > @ruhulmus If this is an example for people, showing them how to use Async logging, then what would be the best place so that people can easily find it? Maybe in the docs? What does it add that the existing docs are missing? (And would it be an idea to improve the existing docs, if that is the case.) @remkop, I have moved the projects under the Docs directory and made detailed documentation with examples for the user's better understanding. I believe it will be helpful for the community. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LOG4J2-3389) Log42j: Provide the capability to Rollover all appenders in an application on Shutdown
[ https://issues.apache.org/jira/browse/LOG4J2-3389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495446#comment-17495446 ] Brian Antao commented on LOG4J2-3389: - It would be nice to have OnShutdownTriggeringPolicy be implemented as part of a new log4j2 release so we don't have to duplicate its implementation in each application. > Log42j: Provide the capability to Rollover all appenders in an application on > Shutdown > -- > > Key: LOG4J2-3389 > URL: https://issues.apache.org/jira/browse/LOG4J2-3389 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders, Configuration >Affects Versions: 2.17.1 > Environment: All, provide the feature as an implementation that can > be defined in the Log4j2 Configuration >Reporter: Brian Antao >Assignee: Ralph Goers >Priority: Major > Labels: Configuration, config.xml, log4j2 > > I have seen many issues raised in StackOverflow for different variations of > finding a good solution to rolling over of all appenders in an application > on Shutdown. But no clear and best solution emerges. > Hence raising this issue which we in our organisation also have a great and > urgent Need for. > What we need is: > A Rollover strategy that we can include in all appenders in the Log4j2 > Configuration, in the Appender definition to properly rollover the associated > log files on Shutdown. > The full rollover functionality needs to be defined fully in the > Configuration only and no need for Java Code to be written to call the > LogManager.Shutdown() method. > This feature would be a tremendous boost particularly managing log files > associated with multiple pods in Kubernetes deployed applications. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3410) Log4j 1.x Compatibility API - ClassCastException when logging MultiKeyMap
[
https://issues.apache.org/jira/browse/LOG4J2-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495444#comment-17495444
]
Piotr P. Karwasz commented on LOG4J2-3410:
--
To me it also seems like a bug in
[{{Category#forcedLog}}|https://github.com/apache/logging-log4j2/blob/e0a53b06c67769b87f5bf3c67681cbd2fa5b1cd6/log4j-1.2-api/src/main/java/org/apache/log4j/Category.java#L310]
and
[{{Category#maybeLog}}|https://github.com/apache/logging-log4j2/blob/e0a53b06c67769b87f5bf3c67681cbd2fa5b1cd6/log4j-1.2-api/src/main/java/org/apache/log4j/Category.java#L561]:
not all maps are String maps.
This should probably be refactored into a special {{MessageFactory}} for Log4j
1.x bridge. I could write a PR tonight.
> Log4j 1.x Compatibility API - ClassCastException when logging MultiKeyMap
> -
>
> Key: LOG4J2-3410
> URL: https://issues.apache.org/jira/browse/LOG4J2-3410
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.13.0, 2.17.1
> Environment: OS: Windows 10 Enterprise 64bit
> Java version: zulu8.31.0.1-jdk8.0.181-win_x64{*}{*}
>Reporter: Barry Sham
>Priority: Major
>
> Our existing business logic contains a debug message which print out a
> {_}org.apache.commons.collections.map.MultiKeyMap{_}:
>
> {code:java}
> MultiKeyMap prnMap = MultiKeyMap.decorate(new LinkedMap());
> prnMap.put("0", "1", "2");
> logger.debug(prnMap);
> {code}
>
> in {*}log4j-1.2-api 2.12.4{*}, it can be print out
> {color:#4c9aff}properly{color}:
>
> {code:java}
> {MultiKey[0, 1]=2}{code}
>
> However it becomes an {color:#FF}ClassCastException {color}+since
> *2.13.0* (including the latest {*}2.17.1{*})+
> {code:java}
> Exception in thread "main" java.lang.ClassCastException:
> org.apache.commons.collections.keyvalue.MultiKey cannot be cast to
> java.lang.String
> at
> org.apache.logging.log4j.util.SortedArrayStringMap.(SortedArrayStringMap.java:154)
> at org.apache.logging.log4j.message.MapMessage.(MapMessage.java:125)
> at org.apache.log4j.Category.maybeLog(Category.java:507)
> at org.apache.log4j.Category.debug(Category.java:243)
> at sideproject.sideproject.App.proeces(App.java:25)
> at sideproject.sideproject.App.main(App.java:17){code}
> As the map can print out using *System.out* +without issue,+ we are wondering
> if it is a bug in Apache Log4j 1.x Compatibility API
> A GitHub Project is prepared for reference: [shin779/log4j-multikeymap
> (github.com)|https://github.com/shin779/log4j-multikeymap]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-parent] dependabot[bot] closed pull request #2: Bump apache from 23 to 24
dependabot[bot] closed pull request #2: URL: https://github.com/apache/logging-parent/pull/2 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-parent] dependabot[bot] commented on pull request #2: Bump apache from 23 to 24
dependabot[bot] commented on pull request #2: URL: https://github.com/apache/logging-parent/pull/2#issuecomment-1046688982 Superseded by #4. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-parent] dependabot[bot] opened a new pull request #4: Bump apache from 24 to 25
dependabot[bot] opened a new pull request #4: URL: https://github.com/apache/logging-parent/pull/4 Bumps [apache](https://github.com/apache/maven-apache-parent) from 24 to 25. Commits See full diff in https://github.com/apache/maven-apache-parent/commits";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LOG4J2-3409) workaround for jackson-mapper-asl-1.9.13.jar security vulnerability @ flume-ng
[ https://issues.apache.org/jira/browse/LOG4J2-3409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495413#comment-17495413 ] alexander kravchik commented on LOG4J2-3409: Hi Matt & Ralph, I opened the issue on log4j as the dependency of jackson-mapper-asl as I saw it here [ASF Git Repos - logging-log4j2.git/blob - log4j-flume-ng/pom.xml (apache.org)|https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-flume-ng/pom.xml;h=eb18d9d98dd610cecbb1b1c14126e3d4b11c41c0;hb=11dafda0c43eb31cca67f3b0ed0ca9b81780db76#l89] According to the maven repository: * jackson-mapper-asl [Maven Repository: org.codehaus.jackson » jackson-mapper-asl (mvnrepository.com)|https://mvnrepository.com/artifact/org.codehaus.jackson/jackson-mapper-asl] was replaced with [Maven Repository: com.fasterxml.jackson.core » jackson-databind (mvnrepository.com)|https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind] * jackson-core-asl [ASF Git Repos - logging-log4j2.git/blob - log4j-flume-ng/pom.xml (apache.org)|https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-flume-ng/pom.xml;h=eb18d9d98dd610cecbb1b1c14126e3d4b11c41c0;hb=11dafda0c43eb31cca67f3b0ed0ca9b81780db76#l85] was replaced with [Maven Repository: com.fasterxml.jackson.core » jackson-core (mvnrepository.com)|https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-core] I also opened the issue on Flume [FLUME-3407] workaround for jackson-mapper-asl-1.9.13.jar @ flume-ng - ASF JIRA (apache.org), it seems it has more vulnerabilities. Can you recheck from your end again as I do not think flume can fix this, the next version of flume will not need this jackson dependency - but the dependency is still on your end according to the pom Kind Regards Sasha > workaround for jackson-mapper-asl-1.9.13.jar security vulnerability @ flume-ng > -- > > Key: LOG4J2-3409 > URL: https://issues.apache.org/jira/browse/LOG4J2-3409 > Project: Log4j 2 > Issue Type: Bug > Components: Flume Appender >Affects Versions: 2.17.1 > Environment: java 11 >Reporter: alexander kravchik >Priority: Major > > Dear colleagues, > we are using log4j2 with flume-ng appender. > The below vulnerabilities are found in the dependent > jackson-mapper-asl-1.9.13.jar : > cve-2019-10202 > cve-2019-10172 > etc... > Please advise if this will be fixed and planned ETA in case it is already > fixed > Thanks , > Sasha -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (LOG4J2-3410) Log4j 1.x Compatibility API - ClassCastException when logging MultiKeyMap
Barry Sham created LOG4J2-3410:
--
Summary: Log4j 1.x Compatibility API - ClassCastException when
logging MultiKeyMap
Key: LOG4J2-3410
URL: https://issues.apache.org/jira/browse/LOG4J2-3410
Project: Log4j 2
Issue Type: Bug
Components: Log4j 1.2 bridge
Affects Versions: 2.17.1, 2.13.0
Environment: OS: Windows 10 Enterprise 64bit
Java version: zulu8.31.0.1-jdk8.0.181-win_x64{*}{*}
Reporter: Barry Sham
Our existing business logic contains a debug message which print out a
{_}org.apache.commons.collections.map.MultiKeyMap{_}:
{code:java}
MultiKeyMap prnMap = MultiKeyMap.decorate(new LinkedMap());
prnMap.put("0", "1", "2");
logger.debug(prnMap);
{code}
in {*}log4j-1.2-api 2.12.4{*}, it can be print out
{color:#4c9aff}properly{color}:
{code:java}
{MultiKey[0, 1]=2}{code}
However it becomes an {color:#FF}ClassCastException {color}+since *2.13.0*
(including the latest {*}2.17.1{*})+
{code:java}
Exception in thread "main" java.lang.ClassCastException:
org.apache.commons.collections.keyvalue.MultiKey cannot be cast to
java.lang.String
at
org.apache.logging.log4j.util.SortedArrayStringMap.(SortedArrayStringMap.java:154)
at org.apache.logging.log4j.message.MapMessage.(MapMessage.java:125)
at org.apache.log4j.Category.maybeLog(Category.java:507)
at org.apache.log4j.Category.debug(Category.java:243)
at sideproject.sideproject.App.proeces(App.java:25)
at sideproject.sideproject.App.main(App.java:17){code}
As the map can print out using *System.out* +without issue,+ we are wondering
if it is a bug in Apache Log4j 1.x Compatibility API
A GitHub Project is prepared for reference: [shin779/log4j-multikeymap
(github.com)|https://github.com/shin779/log4j-multikeymap]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] vy merged pull request #766: Bump kubernetes-client from 4.6.1 to 5.12.1
vy merged pull request #766: URL: https://github.com/apache/logging-log4j2/pull/766 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] vy commented on pull request #750: Bump liquibase-core from 3.5.5 to 3.10.3
vy commented on pull request #750: URL: https://github.com/apache/logging-log4j2/pull/750#issuecomment-1046619861 @garydgregory see #503 for some more context. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
