[jira] [Commented] (LOG4J2-3471) log4j-1.2-api 2.17.2 throws NullPointerException while removing appender with name as null
[ https://issues.apache.org/jira/browse/LOG4J2-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519318#comment-17519318 ] Rajesh commented on LOG4J2-3471: [~ggregory] Thanks for the quick fix. > log4j-1.2-api 2.17.2 throws NullPointerException while removing appender with > name as null > -- > > Key: LOG4J2-3471 > URL: https://issues.apache.org/jira/browse/LOG4J2-3471 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Rajesh >Assignee: Gary D. Gregory >Priority: Major > Fix For: 2.17.3 > > > The log4j 1.2 bridge for 2.17.2 throws null pointer exception while removing > Null appender > viz. org.apache.log4j.varia.NullAppender > The class AppenderAttachableImpl adds the null appender to the > concurrenthashmap as "null" and on removal there is no check for null and > removes the nullappender with name null hence the NullPointerexception. > Caused by: java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.remove(Unknown Source) > at > org.apache.log4j.helpers.AppenderAttachableImpl.removeAppender(AppenderAttachableImpl.java:93) > at org.apache.log4j.Category.removeAppender(Category.java:618) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [logging-log4j2] remkop commented on pull request #763: Added java logging with Asynchronous logger
remkop commented on PR #763: URL: https://github.com/apache/logging-log4j2/pull/763#issuecomment-1092382916 @ruhulmus Thank you for your patience and persistence. What you are proposing (if I understand correctly) is quite different from what we have at the moment. * All of the submodules currently in the log4j project produce JAR files that are published to Maven Central. Each submodule contains a `src/main` folder where the source code for the artifact lives, a `src/test` folder for the test code (test JAR files are note published to Maven), and a `src/site` folder with some documentation for that submodule that will be converted to HTML and published on the Log4j web site. * For documentation, we have "source" files under `logging-log4j2/src/site`: `src/site/asciidoc`, `src/site/markdown`, and `src/site/xdoc` (this is a bit cleaner in the 3.0 branch), these "source files" are converted to PDF and HTML and are published on the Log4j web site under https://logging.apache.org/log4j/2.x/manual What you are proposing is a different kind of documentation, essentially an example project that people can either browse via GitHub's web interface, or clone/download to build and modify it locally. This is an interesting idea, and I can see the value in something like that, not just for Async Loggers, but also for other features. (We have something similar in the https://github.com/apache/logging-log4j-audit-sample repo.) It may make sense to create a separate github repo for this. Perhaps we can call it something like `logging-log4j-examples`. This could be a documentation-only repo, that is not intended to publish artifacts. For the main Log4j repo (https://github.com/apache/logging-log4j), the threshold for accepting external contributions is quite high. One of the advantages of having a separate repo for example code is that we can be less strict about merging pull requests into that separate repo, so we can accept more contributions without spending much time on fine-tuning and polishing it. I wonder what the other Log4j committers think of this? -- 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-3471) log4j-1.2-api 2.17.2 throws NullPointerException while removing appender with name as null
[ https://issues.apache.org/jira/browse/LOG4J2-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519239#comment-17519239 ] ASF subversion and git services commented on LOG4J2-3471: - Commit fc0da3c3a24160eddc5ea573911b3c02949dc80f in logging-log4j2's branch refs/heads/master from Gary Gregory [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=fc0da3c3a2 ] [LOG4J2-3471] log4j-1.2-api-2.17.2 throws exception while removing appender with name as null. Make internal use of the ConcurrentHashMap null safe. > log4j-1.2-api 2.17.2 throws NullPointerException while removing appender with > name as null > -- > > Key: LOG4J2-3471 > URL: https://issues.apache.org/jira/browse/LOG4J2-3471 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Rajesh >Assignee: Gary D. Gregory >Priority: Major > Fix For: 2.17.3 > > > The log4j 1.2 bridge for 2.17.2 throws null pointer exception while removing > Null appender > viz. org.apache.log4j.varia.NullAppender > The class AppenderAttachableImpl adds the null appender to the > concurrenthashmap as "null" and on removal there is no check for null and > removes the nullappender with name null hence the NullPointerexception. > Caused by: java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.remove(Unknown Source) > at > org.apache.log4j.helpers.AppenderAttachableImpl.removeAppender(AppenderAttachableImpl.java:93) > at org.apache.log4j.Category.removeAppender(Category.java:618) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3471) log4j-1.2-api 2.17.2 throws NullPointerException while removing appender with name as null
[ https://issues.apache.org/jira/browse/LOG4J2-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519238#comment-17519238 ] ASF subversion and git services commented on LOG4J2-3471: - Commit 442979dc46a6aaa52fe9d184c335595cde5a7667 in logging-log4j2's branch refs/heads/master from Gary Gregory [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=442979dc46 ] [LOG4J2-3471] log4j-1.2-api-2.17.2 throws exception while removing appender with name as null. Make internal use of the ConcurrentHashMap null safe. > log4j-1.2-api 2.17.2 throws NullPointerException while removing appender with > name as null > -- > > Key: LOG4J2-3471 > URL: https://issues.apache.org/jira/browse/LOG4J2-3471 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Rajesh >Assignee: Gary D. Gregory >Priority: Major > Fix For: 2.17.3 > > > The log4j 1.2 bridge for 2.17.2 throws null pointer exception while removing > Null appender > viz. org.apache.log4j.varia.NullAppender > The class AppenderAttachableImpl adds the null appender to the > concurrenthashmap as "null" and on removal there is no check for null and > removes the nullappender with name null hence the NullPointerexception. > Caused by: java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.remove(Unknown Source) > at > org.apache.log4j.helpers.AppenderAttachableImpl.removeAppender(AppenderAttachableImpl.java:93) > at org.apache.log4j.Category.removeAppender(Category.java:618) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [logging-log4j2] ruhulmus commented on pull request #763: Added java logging with Asynchronous logger
ruhulmus commented on PR #763: URL: https://github.com/apache/logging-log4j2/pull/763#issuecomment-1092256016 > @ruhulmus, I also agree with Gary and Remko: I fail to see the point of this new Maven artifact. What does it have that is missing in the [official documentation](https://logging.apache.org/log4j/2.x/manual/async.html)? @ppkarwasz, Thanks for your feedback. It is an example and documentation of people who want to use Async logging in java projects. The main reason to share it within the community, it's an important use case for log4j2 with java and 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] ppkarwasz commented on a diff in pull request #815: [LOG4J2-2872] Normalizes level names
ppkarwasz commented on code in PR #815:
URL: https://github.com/apache/logging-log4j2/pull/815#discussion_r845563956
##
log4j-api/src/main/java/org/apache/logging/log4j/Level.java:
##
@@ -259,15 +258,23 @@ public String toString() {
* @throws java.lang.IllegalArgumentException if the name is null or
intValue is less than zero.
*/
public static Level forName(final String name, final int intValue) {
-final Level level = LEVELS.get(name);
Review Comment:
Yes, that make sense, although the main reason for this check is to prevent
an NPE in the `ConcurrentHashMap`.
--
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 diff in pull request #815: [LOG4J2-2872] Normalizes level names
garydgregory commented on code in PR #815:
URL: https://github.com/apache/logging-log4j2/pull/815#discussion_r845558255
##
log4j-api/src/main/java/org/apache/logging/log4j/Level.java:
##
@@ -276,9 +283,13 @@ public static Level forName(final String name, final int
intValue) {
*
* @param name The name of the Level.
* @return The Level or null.
+ * @throws java.lang.IllegalArgumentException if the name is null.
*/
public static Level getLevel(final String name) {
-return LEVELS.get(name);
+if (name == null) {
Review Comment:
See comment above.
--
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] [Work started] (LOG4J2-2872) Unable to parse Custom Log Levels
[
https://issues.apache.org/jira/browse/LOG4J2-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on LOG4J2-2872 started by Piotr Karwasz.
-
> Unable to parse Custom Log Levels
> -
>
> Key: LOG4J2-2872
> URL: https://issues.apache.org/jira/browse/LOG4J2-2872
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.13.3
>Reporter: Alla Gofman
>Assignee: Piotr Karwasz
>Priority: Major
>
> When I set the logger level to custom value I get exception although my
> custom levels was created on init.
> WARN Error while converting string [alert] to type [class
> org.apache.logging.log4j.Level]. Using default value [null].
> java.lang.IllegalArgumentException: Unknown level constant [ALERT].
>
> The CustomLevel not added to Level.LEVELS ( ConcurrentMap
> LEVELS).
> My configuration:
> {code:xml}
>
>
> ${cm.home}/../../proclog %d\{-MM-dd HH:mm:ss,SSS} %-2p [%t]
> (%logger\{1}:%L) - %m%n
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> filePattern="${log-path}/alerts%i.log">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> h2. {{Please see log in debug:}}
> {code}
> 2020-06-17 19:23:31,770 main DEBUG PluginManager 'Lookup' found 16 plugins
> 2020-06-17 19:23:31,772 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,773 main DEBUG createLevel(name="emerg", intLevel="0")
> 2020-06-17 19:23:31,773 main DEBUG Creating CustomLevel(name='emerg',
> intValue=0)
> 2020-06-17 19:23:31,774 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,774 main DEBUG createLevel(name="alert", intLevel="1")
> 2020-06-17 19:23:31,774 main DEBUG Creating CustomLevel(name='alert',
> intValue=1)
> 2020-06-17 19:23:31,774 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,775 main DEBUG createLevel(name="crit", intLevel="2")
> 2020-06-17 19:23:31,775 main DEBUG Creating CustomLevel(name='crit',
> intValue=2)
> 2020-06-17 19:23:31,775 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,776 main DEBUG createLevel(name="err", intLevel="3")
> 2020-06-17 19:23:31,776 main DEBUG Creating CustomLevel(name='err',
> intValue=3)
> 2020-06-17 19:23:31,776 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,776 main DEBUG createLevel(name="warning", intLevel="4")
> 2020-06-17 19:23:31,777 main DEBUG Creating CustomLevel(name='warning',
> intValue=4)
> 2020-06-17 19:23:31,777 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,777 main DEBUG createLevel(name="notice", intLevel="5")
> 2020-06-17 19:23:31,777 main DEBUG Creating CustomLevel(name='notice',
> intValue=5)
> 2020-06-17 19:23:31,778 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,778 main DEBUG createLevel(name="info", intLevel="6")
> 2020-06-17 19:23:31,779 main DEBUG Creating CustomLevel(name='info',
> intValue=6)
> 2020-06-17 19:23:31,779 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,780 main DEBUG createLevel(name="debug", intLevel="7")
> 2020-06-17 19:23:31,780 main DEBUG Creating CustomLevel(name='debug',
> intValue=7)
> 2020-06-17 19:23:31,780 main DEBUG Building Plugin[name=CustomLevels,
> class=org.apache.logging.log4j.core.config.CustomLevels].
> 2020-06-17 19:23:31,780 main DEBUG
> createCustomLevels(=\{CustomLevel[name=emerg, intLevel=0],
> CustomLevel[name=alert, intLevel=1], CustomLevel[name=crit, intLevel=2],
> CustomLevel[name=err, intLevel=3], CustomLevel[name=warning, intLevel=4],
> CustomLevel[name=notice, intLevel=5], CustomLevel[name=info, intLevel=6],
> CustomLevel[name=debug, intLevel=7]})
> ...
> 2020-06-17 19:23:31,864 main WARN Error while converting string [alert] to
> type [class org.apache.logging.log4j.Level]. Using default value [null].
> java.lang.IllegalArgumentException: Unknown level constant [ALERT].2020-06-17
> 19:23:31,864 main WARN Error while converting string [alert] to type [class
> org.apache.logging.log4j.Level]. Using default value [null].
>
[GitHub] [logging-log4j2] garydgregory commented on a diff in pull request #815: [LOG4J2-2872] Normalizes level names
garydgregory commented on code in PR #815:
URL: https://github.com/apache/logging-log4j2/pull/815#discussion_r845557940
##
log4j-api/src/main/java/org/apache/logging/log4j/Level.java:
##
@@ -259,15 +258,23 @@ public String toString() {
* @throws java.lang.IllegalArgumentException if the name is null or
intValue is less than zero.
*/
public static Level forName(final String name, final int intValue) {
-final Level level = LEVELS.get(name);
Review Comment:
Above we use Strings.isEmpty(name), shouldn't we use the same here?
--
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 commented on pull request #763: Added java logging with Asynchronous logger
ppkarwasz commented on PR #763: URL: https://github.com/apache/logging-log4j2/pull/763#issuecomment-1092193939 @ruhulmus, I also agree with Gary and Remko: I fail to see the point of this new Maven artifact. What does it have that is missing in the [official documentation](https://logging.apache.org/log4j/2.x/manual/async.html)? -- 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-3471) log4j-1.2-api 2.17.2 throws NullPointerException while removing appender with name as null
[ https://issues.apache.org/jira/browse/LOG4J2-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved LOG4J2-3471. - Fix Version/s: 2.17.3 Resolution: Fixed [~rajeshn] Thank you for your report. Please try a 2.17.3-SNAPSHOT from [https://repository.apache.org/content/repositories/snapshots/] TY! > log4j-1.2-api 2.17.2 throws NullPointerException while removing appender with > name as null > -- > > Key: LOG4J2-3471 > URL: https://issues.apache.org/jira/browse/LOG4J2-3471 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Rajesh >Assignee: Gary D. Gregory >Priority: Major > Fix For: 2.17.3 > > > The log4j 1.2 bridge for 2.17.2 throws null pointer exception while removing > Null appender > viz. org.apache.log4j.varia.NullAppender > The class AppenderAttachableImpl adds the null appender to the > concurrenthashmap as "null" and on removal there is no check for null and > removes the nullappender with name null hence the NullPointerexception. > Caused by: java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.remove(Unknown Source) > at > org.apache.log4j.helpers.AppenderAttachableImpl.removeAppender(AppenderAttachableImpl.java:93) > at org.apache.log4j.Category.removeAppender(Category.java:618) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [logging-log4j2] ppkarwasz opened a new pull request, #815: [LOG4J2-2872] Normalizes level names
ppkarwasz opened a new pull request, #815: URL: https://github.com/apache/logging-log4j2/pull/815 Calling `Level.forName` with a non upper case argument, can create a custom level that can not be retrieved using `Level.toLevel`. This PR fixes to upper case the keys in the `Level.LEVELS` map. -- 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-3471) log4j-1.2-api 2.17.2 throws NullPointerException while removing appender with name as null
[ https://issues.apache.org/jira/browse/LOG4J2-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519160#comment-17519160 ] ASF subversion and git services commented on LOG4J2-3471: - Commit cfb118e40484faa549a975d912473b4f739a8206 in logging-log4j2's branch refs/heads/release-2.x from Gary Gregory [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=cfb118e404 ] [LOG4J2-3471] log4j-1.2-api-2.17.2 throws exception while removing appender with name as null. Make internal use of the ConcurrentHashMap null safe. > log4j-1.2-api 2.17.2 throws NullPointerException while removing appender with > name as null > -- > > Key: LOG4J2-3471 > URL: https://issues.apache.org/jira/browse/LOG4J2-3471 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Rajesh >Assignee: Gary D. Gregory >Priority: Major > > The log4j 1.2 bridge for 2.17.2 throws null pointer exception while removing > Null appender > viz. org.apache.log4j.varia.NullAppender > The class AppenderAttachableImpl adds the null appender to the > concurrenthashmap as "null" and on removal there is no check for null and > removes the nullappender with name null hence the NullPointerexception. > Caused by: java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.remove(Unknown Source) > at > org.apache.log4j.helpers.AppenderAttachableImpl.removeAppender(AppenderAttachableImpl.java:93) > at org.apache.log4j.Category.removeAppender(Category.java:618) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3471) log4j-1.2-api-2.17.2 throws NullPointerException while removing appender with name as null
[ https://issues.apache.org/jira/browse/LOG4J2-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated LOG4J2-3471: Summary: log4j-1.2-api-2.17.2 throws NullPointerException while removing appender with name as null (was: log4j-1.2-api-2.17.2 throws exception while removing appender with name as null) > log4j-1.2-api-2.17.2 throws NullPointerException while removing appender with > name as null > -- > > Key: LOG4J2-3471 > URL: https://issues.apache.org/jira/browse/LOG4J2-3471 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Rajesh >Assignee: Gary D. Gregory >Priority: Major > > The log4j 1.2 bridge for 2.17.2 throws null pointer exception while removing > Null appender > viz. org.apache.log4j.varia.NullAppender > The class AppenderAttachableImpl adds the null appender to the > concurrenthashmap as "null" and on removal there is no check for null and > removes the nullappender with name null hence the NullPointerexception. > Caused by: java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.remove(Unknown Source) > at > org.apache.log4j.helpers.AppenderAttachableImpl.removeAppender(AppenderAttachableImpl.java:93) > at org.apache.log4j.Category.removeAppender(Category.java:618) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3471) log4j-1.2-api 2.17.2 throws NullPointerException while removing appender with name as null
[ https://issues.apache.org/jira/browse/LOG4J2-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated LOG4J2-3471: Summary: log4j-1.2-api 2.17.2 throws NullPointerException while removing appender with name as null (was: log4j-1.2-api-2.17.2 throws NullPointerException while removing appender with name as null) > log4j-1.2-api 2.17.2 throws NullPointerException while removing appender with > name as null > -- > > Key: LOG4J2-3471 > URL: https://issues.apache.org/jira/browse/LOG4J2-3471 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Rajesh >Assignee: Gary D. Gregory >Priority: Major > > The log4j 1.2 bridge for 2.17.2 throws null pointer exception while removing > Null appender > viz. org.apache.log4j.varia.NullAppender > The class AppenderAttachableImpl adds the null appender to the > concurrenthashmap as "null" and on removal there is no check for null and > removes the nullappender with name null hence the NullPointerexception. > Caused by: java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.remove(Unknown Source) > at > org.apache.log4j.helpers.AppenderAttachableImpl.removeAppender(AppenderAttachableImpl.java:93) > at org.apache.log4j.Category.removeAppender(Category.java:618) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3471) log4j-1.2-api-2.17.2 throws exception while removing appender with name as null
[ https://issues.apache.org/jira/browse/LOG4J2-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519158#comment-17519158 ] ASF subversion and git services commented on LOG4J2-3471: - Commit 5fc1e4957d9ba622d83bcf29c0aa3c54c34e19bf in logging-log4j2's branch refs/heads/release-2.x from Gary Gregory [ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5fc1e4957d ] [LOG4J2-3471] log4j-1.2-api-2.17.2 throws exception while removing appender with name as null. Make internal use of the ConcurrentHashMap null safe. > log4j-1.2-api-2.17.2 throws exception while removing appender with name as > null > --- > > Key: LOG4J2-3471 > URL: https://issues.apache.org/jira/browse/LOG4J2-3471 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Rajesh >Assignee: Gary D. Gregory >Priority: Major > > The log4j 1.2 bridge for 2.17.2 throws null pointer exception while removing > Null appender > viz. org.apache.log4j.varia.NullAppender > The class AppenderAttachableImpl adds the null appender to the > concurrenthashmap as "null" and on removal there is no check for null and > removes the nullappender with name null hence the NullPointerexception. > Caused by: java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.remove(Unknown Source) > at > org.apache.log4j.helpers.AppenderAttachableImpl.removeAppender(AppenderAttachableImpl.java:93) > at org.apache.log4j.Category.removeAppender(Category.java:618) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (LOG4J2-2872) Unable to parse Custom Log Levels
[
https://issues.apache.org/jira/browse/LOG4J2-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Karwasz reassigned LOG4J2-2872:
-
Assignee: Piotr Karwasz
> Unable to parse Custom Log Levels
> -
>
> Key: LOG4J2-2872
> URL: https://issues.apache.org/jira/browse/LOG4J2-2872
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.13.3
>Reporter: Alla Gofman
>Assignee: Piotr Karwasz
>Priority: Major
>
> When I set the logger level to custom value I get exception although my
> custom levels was created on init.
> WARN Error while converting string [alert] to type [class
> org.apache.logging.log4j.Level]. Using default value [null].
> java.lang.IllegalArgumentException: Unknown level constant [ALERT].
>
> The CustomLevel not added to Level.LEVELS ( ConcurrentMap
> LEVELS).
> My configuration:
> {code:xml}
>
>
> ${cm.home}/../../proclog %d\{-MM-dd HH:mm:ss,SSS} %-2p [%t]
> (%logger\{1}:%L) - %m%n
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> filePattern="${log-path}/alerts%i.log">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> h2. {{Please see log in debug:}}
> {code}
> 2020-06-17 19:23:31,770 main DEBUG PluginManager 'Lookup' found 16 plugins
> 2020-06-17 19:23:31,772 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,773 main DEBUG createLevel(name="emerg", intLevel="0")
> 2020-06-17 19:23:31,773 main DEBUG Creating CustomLevel(name='emerg',
> intValue=0)
> 2020-06-17 19:23:31,774 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,774 main DEBUG createLevel(name="alert", intLevel="1")
> 2020-06-17 19:23:31,774 main DEBUG Creating CustomLevel(name='alert',
> intValue=1)
> 2020-06-17 19:23:31,774 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,775 main DEBUG createLevel(name="crit", intLevel="2")
> 2020-06-17 19:23:31,775 main DEBUG Creating CustomLevel(name='crit',
> intValue=2)
> 2020-06-17 19:23:31,775 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,776 main DEBUG createLevel(name="err", intLevel="3")
> 2020-06-17 19:23:31,776 main DEBUG Creating CustomLevel(name='err',
> intValue=3)
> 2020-06-17 19:23:31,776 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,776 main DEBUG createLevel(name="warning", intLevel="4")
> 2020-06-17 19:23:31,777 main DEBUG Creating CustomLevel(name='warning',
> intValue=4)
> 2020-06-17 19:23:31,777 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,777 main DEBUG createLevel(name="notice", intLevel="5")
> 2020-06-17 19:23:31,777 main DEBUG Creating CustomLevel(name='notice',
> intValue=5)
> 2020-06-17 19:23:31,778 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,778 main DEBUG createLevel(name="info", intLevel="6")
> 2020-06-17 19:23:31,779 main DEBUG Creating CustomLevel(name='info',
> intValue=6)
> 2020-06-17 19:23:31,779 main DEBUG Building Plugin[name=CustomLevel,
> class=org.apache.logging.log4j.core.config.CustomLevelConfig].
> 2020-06-17 19:23:31,780 main DEBUG createLevel(name="debug", intLevel="7")
> 2020-06-17 19:23:31,780 main DEBUG Creating CustomLevel(name='debug',
> intValue=7)
> 2020-06-17 19:23:31,780 main DEBUG Building Plugin[name=CustomLevels,
> class=org.apache.logging.log4j.core.config.CustomLevels].
> 2020-06-17 19:23:31,780 main DEBUG
> createCustomLevels(=\{CustomLevel[name=emerg, intLevel=0],
> CustomLevel[name=alert, intLevel=1], CustomLevel[name=crit, intLevel=2],
> CustomLevel[name=err, intLevel=3], CustomLevel[name=warning, intLevel=4],
> CustomLevel[name=notice, intLevel=5], CustomLevel[name=info, intLevel=6],
> CustomLevel[name=debug, intLevel=7]})
> ...
> 2020-06-17 19:23:31,864 main WARN Error while converting string [alert] to
> type [class org.apache.logging.log4j.Level]. Using default value [null].
> java.lang.IllegalArgumentException: Unknown level constant [ALERT].2020-06-17
> 19:23:31,864 main WARN Error while converting string [alert] to type [class
> org.apache.logging.log4j.Level]. Using default value
[jira] [Assigned] (LOG4J2-3471) log4j-1.2-api-2.17.2 throws exception while removing appender with name as null
[ https://issues.apache.org/jira/browse/LOG4J2-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory reassigned LOG4J2-3471: --- Assignee: Gary D. Gregory > log4j-1.2-api-2.17.2 throws exception while removing appender with name as > null > --- > > Key: LOG4J2-3471 > URL: https://issues.apache.org/jira/browse/LOG4J2-3471 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Rajesh >Assignee: Gary D. Gregory >Priority: Major > > The log4j 1.2 bridge for 2.17.2 throws null pointer exception while removing > Null appender > viz. org.apache.log4j.varia.NullAppender > The class AppenderAttachableImpl adds the null appender to the > concurrenthashmap as "null" and on removal there is no check for null and > removes the nullappender with name null hence the NullPointerexception. > Caused by: java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.remove(Unknown Source) > at > org.apache.log4j.helpers.AppenderAttachableImpl.removeAppender(AppenderAttachableImpl.java:93) > at org.apache.log4j.Category.removeAppender(Category.java:618) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3463) java.util.ServiceConfigurationError: org.apache.logging.log4j.spi.Provider: Provider org.apache.logging.log4j.core.impl.Log4jProvider not a subtype
[ https://issues.apache.org/jira/browse/LOG4J2-3463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory reassigned LOG4J2-3463: --- Assignee: (was: Gary D. Gregory) > java.util.ServiceConfigurationError: org.apache.logging.log4j.spi.Provider: > Provider org.apache.logging.log4j.core.impl.Log4jProvider not a subtype > --- > > Key: LOG4J2-3463 > URL: https://issues.apache.org/jira/browse/LOG4J2-3463 > Project: Log4j 2 > Issue Type: Bug > Components: API, Core, Log4j 1.2 bridge, Web/Servlet >Affects Versions: 2.17.3 > Environment: Configuration: > Using bridge api 2.17.3 latest snapshot. Also using log4j-web, log4j-api, > log4j-core (all 2.17.3 snapshot). A wrapper class is used for configuration > across applications running on tomcat. >Reporter: Swapnil Markhedkar >Priority: Blocker > Attachments: Provider error.txt > > > Came across this error while using tomcat at application level. Similar to > https://issues.apache.org/jira/browse/LOG4J2-2055, but error persists even > when added 2.10 jars. > In depth stack trace has been attached as text file. > NOTE: Tomcat server and it's logging is working fine. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3463) java.util.ServiceConfigurationError: org.apache.logging.log4j.spi.Provider: Provider org.apache.logging.log4j.core.impl.Log4jProvider not a subtype
[ https://issues.apache.org/jira/browse/LOG4J2-3463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory reassigned LOG4J2-3463: --- Assignee: Gary D. Gregory > java.util.ServiceConfigurationError: org.apache.logging.log4j.spi.Provider: > Provider org.apache.logging.log4j.core.impl.Log4jProvider not a subtype > --- > > Key: LOG4J2-3463 > URL: https://issues.apache.org/jira/browse/LOG4J2-3463 > Project: Log4j 2 > Issue Type: Bug > Components: API, Core, Log4j 1.2 bridge, Web/Servlet >Affects Versions: 2.17.3 > Environment: Configuration: > Using bridge api 2.17.3 latest snapshot. Also using log4j-web, log4j-api, > log4j-core (all 2.17.3 snapshot). A wrapper class is used for configuration > across applications running on tomcat. >Reporter: Swapnil Markhedkar >Assignee: Gary D. Gregory >Priority: Blocker > Attachments: Provider error.txt > > > Came across this error while using tomcat at application level. Similar to > https://issues.apache.org/jira/browse/LOG4J2-2055, but error persists even > when added 2.10 jars. > In depth stack trace has been attached as text file. > NOTE: Tomcat server and it's logging is working fine. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [logging-log4j2] ruhulmus commented on pull request #763: Added java logging with Asynchronous logger
ruhulmus commented on PR #763: URL: https://github.com/apache/logging-log4j2/pull/763#issuecomment-1092154845 Hi @remkop, Did you review the latest one? may I ask What is the additional process for the merge :)? or any additional thing needed? Looking for your 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
[jira] [Comment Edited] (LOG4J2-3467) Update from Log4J 2.17.1 to 2.17.2 breaks application
[
https://issues.apache.org/jira/browse/LOG4J2-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519122#comment-17519122
]
Piotr Karwasz edited comment on LOG4J2-3467 at 4/7/22 7:32 PM:
---
[~veita],
Yes, the configuration code in the third party library never did any
configuration at all before 2.17.2.
Anyway I think this issue might have some merit: {{PropertyConfigurator}}
probably shouldn't allow configuration without some opt-in option (e.g.
{{{}log4j1.compatibility="true"){}}}. [~ggregory], what do you think? We never
documented that {{log4j-1.2-api}} can be used to perform programmatic
configuration, so maybe we can disable the configuration methods by default?
was (Author: pkarwasz):
[~veita],
Yes, the configuration code in the third party library never did any
configuration at all before 2.17.2.
Anyway I think this issue might have some merit: {{PropertyConfigurator}}
probably shouldn't allow configuration without some opt-in option (e.g.
{{{}log4j1.compatibility="true"{}}}. [~ggregory], what do you think? We never
documented that {{log4j-1.2-api}} can be used to perform programmatic
configuration, so maybe we can disable the configuration methods by default?
> Update from Log4J 2.17.1 to 2.17.2 breaks application
> -
>
> Key: LOG4J2-3467
> URL: https://issues.apache.org/jira/browse/LOG4J2-3467
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.2
>Reporter: Alexander Veit
>Priority: Major
>
> We have an application that uses a third-party library which seems to
> reconfigure Log4J according to its needs. This worked for quite some years
> with various Log4J versions.
> After upgrading from Log4J 2.17.1 to 2.17.2 a call to the library immediately
> stops logging completely in the sense that no further logging is performed
> until restarting the JVM.
> We've tried to identify the change that leads to the problem. Our best guess
> is PropertyConfigurator, line 164 in
> https://github.com/apache/logging-log4j2/commit/73a2cd1cd0e94c7f4f36e4ac9dc72380d30750ef#diff-607596a6cadd10faf2dbeefc4e03092264b8e0dbe23fb89ffa6505d644602c9dR164
> Note that according to semantic versioning such breaking changes should not
> occur when only the patch version is incremented. ;-)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3467) Update from Log4J 2.17.1 to 2.17.2 breaks application
[
https://issues.apache.org/jira/browse/LOG4J2-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519122#comment-17519122
]
Piotr Karwasz commented on LOG4J2-3467:
---
[~veita],
Yes, the configuration code in the third party library never did any
configuration at all before 2.17.2.
Anyway I think this issue might have some merit: {{PropertyConfigurator}}
probably shouldn't allow configuration without some opt-in option (e.g.
{{{}log4j1.compatibility="true"{}}}. [~ggregory], what do you think? We never
documented that {{log4j-1.2-api}} can be used to perform programmatic
configuration, so maybe we can disable the configuration methods by default?
> Update from Log4J 2.17.1 to 2.17.2 breaks application
> -
>
> Key: LOG4J2-3467
> URL: https://issues.apache.org/jira/browse/LOG4J2-3467
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.2
>Reporter: Alexander Veit
>Priority: Major
>
> We have an application that uses a third-party library which seems to
> reconfigure Log4J according to its needs. This worked for quite some years
> with various Log4J versions.
> After upgrading from Log4J 2.17.1 to 2.17.2 a call to the library immediately
> stops logging completely in the sense that no further logging is performed
> until restarting the JVM.
> We've tried to identify the change that leads to the problem. Our best guess
> is PropertyConfigurator, line 164 in
> https://github.com/apache/logging-log4j2/commit/73a2cd1cd0e94c7f4f36e4ac9dc72380d30750ef#diff-607596a6cadd10faf2dbeefc4e03092264b8e0dbe23fb89ffa6505d644602c9dR164
> Note that according to semantic versioning such breaking changes should not
> occur when only the patch version is incremented. ;-)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3463) java.util.ServiceConfigurationError: org.apache.logging.log4j.spi.Provider: Provider org.apache.logging.log4j.core.impl.Log4jProvider not a subtype
[
https://issues.apache.org/jira/browse/LOG4J2-3463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519092#comment-17519092
]
Piotr Karwasz commented on LOG4J2-3463:
---
Hello [~smarkhedkar],
my PR has a rather high risk-to-reward ratio, so I will not rush to merge it
until I check many usage cases.
You can however compile the library yourself. This requires:
# installing a Java 8 and Java 9+ (e.g. Java 11) JDK on your system,
# setting {{JAVA_HOME}} to the path of the Java 8 JDK.
# cloning the branch of the PR:
{noformat}
git clone https://github.com/ppkarwasz/logging-log4j2.git
{noformat}
# installing the appropriate {{toolchains.xml}} file in the {{.m2}} folder of
your home directory and adapting the paths to the ones used by your system,
# running the Maven wrapper in the project's directory:
{noformat}
./mvnw -DskipTests=true clean install
{noformat}
The freshly compiled jars will be in your local Maven repository ({{.m2}}
directory in your home directory).
> java.util.ServiceConfigurationError: org.apache.logging.log4j.spi.Provider:
> Provider org.apache.logging.log4j.core.impl.Log4jProvider not a subtype
> ---
>
> Key: LOG4J2-3463
> URL: https://issues.apache.org/jira/browse/LOG4J2-3463
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core, Log4j 1.2 bridge, Web/Servlet
>Affects Versions: 2.17.3
> Environment: Configuration:
> Using bridge api 2.17.3 latest snapshot. Also using log4j-web, log4j-api,
> log4j-core (all 2.17.3 snapshot). A wrapper class is used for configuration
> across applications running on tomcat.
>Reporter: Swapnil Markhedkar
>Priority: Blocker
> Attachments: Provider error.txt
>
>
> Came across this error while using tomcat at application level. Similar to
> https://issues.apache.org/jira/browse/LOG4J2-2055, but error persists even
> when added 2.10 jars.
> In depth stack trace has been attached as text file.
> NOTE: Tomcat server and it's logging is working fine.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (LOG4J2-3471) log4j-1.2-api-2.17.2 throws exception while removing appender with name as null
Rajesh created LOG4J2-3471: -- Summary: log4j-1.2-api-2.17.2 throws exception while removing appender with name as null Key: LOG4J2-3471 URL: https://issues.apache.org/jira/browse/LOG4J2-3471 Project: Log4j 2 Issue Type: Bug Affects Versions: 2.17.2 Reporter: Rajesh The log4j 1.2 bridge for 2.17.2 throws null pointer exception while removing Null appender viz. org.apache.log4j.varia.NullAppender The class AppenderAttachableImpl adds the null appender to the concurrenthashmap as "null" and on removal there is no check for null and removes the nullappender with name null hence the NullPointerexception. Caused by: java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.remove(Unknown Source) at org.apache.log4j.helpers.AppenderAttachableImpl.removeAppender(AppenderAttachableImpl.java:93) at org.apache.log4j.Category.removeAppender(Category.java:618) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [logging-log4j2] vy commented on pull request #814: [DOC] add blank line for markdown rendering
vy commented on PR #814: URL: https://github.com/apache/logging-log4j2/pull/814#issuecomment-1091781306 Thanks @kevinjmh! -- 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 merged pull request #814: [DOC] add blank line for markdown rendering
vy merged PR #814: URL: https://github.com/apache/logging-log4j2/pull/814 -- 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-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=17518894#comment-17518894
]
Jan Mosig commented on LOG4J2-3470:
---
The application's configuration is this:
{code}
{code}
As for the configuration within the cloud I don't really know. If you also need
it, I could investigate.
> 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] [Commented] (LOG4J2-3467) Update from Log4J 2.17.1 to 2.17.2 breaks application
[ https://issues.apache.org/jira/browse/LOG4J2-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518891#comment-17518891 ] Alexander Veit commented on LOG4J2-3467: OK. Is my interpretation correct that the configuration code in the third-part library might never have worked? If so, this issue could probably closed (we are currently in contact with the vendor who has pledged to fix the issue on their side). > Update from Log4J 2.17.1 to 2.17.2 breaks application > - > > Key: LOG4J2-3467 > URL: https://issues.apache.org/jira/browse/LOG4J2-3467 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.17.2 >Reporter: Alexander Veit >Priority: Major > > We have an application that uses a third-party library which seems to > reconfigure Log4J according to its needs. This worked for quite some years > with various Log4J versions. > After upgrading from Log4J 2.17.1 to 2.17.2 a call to the library immediately > stops logging completely in the sense that no further logging is performed > until restarting the JVM. > We've tried to identify the change that leads to the problem. Our best guess > is PropertyConfigurator, line 164 in > https://github.com/apache/logging-log4j2/commit/73a2cd1cd0e94c7f4f36e4ac9dc72380d30750ef#diff-607596a6cadd10faf2dbeefc4e03092264b8e0dbe23fb89ffa6505d644602c9dR164 > Note that according to semantic versioning such breaking changes should not > occur when only the patch version is incremented. ;-) -- 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=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] [Created] (LOG4J2-3470) Expressions in property values are not expanded anymore
Jan Mosig created LOG4J2-3470:
-
Summary: 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
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)
[GitHub] [logging-log4j2] kevinjmh opened a new pull request, #814: [DOC] add blank line for markdown rendering
kevinjmh opened a new pull request, #814: URL: https://github.com/apache/logging-log4j2/pull/814  some titles are not rendered correctly. -- 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-3469) Create new builder from existing Appender
[
https://issues.apache.org/jira/browse/LOG4J2-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518627#comment-17518627
]
Ralph Goers commented on LOG4J2-3469:
-
Once a configuration has started you cannot modify the filename the Appender
writes to.
Our position is that programmatic configuration is to be avoided as it makes
applications too tied to the internals of Log4j, which is why so many
applications have yet to upgrade from Log4j 1.x. Instead, we have added things
like Arbiters to allow you to choose which components you want to use
dynamically during initialization. In general, we suggest that if we haven't
provided something that will allow you to do what you need in the configuration
file that a Jira issue be opened requesting a feature to do it.
I should note that I believe all 3 of your bullets could be solved by using
[Arbiters|https://logging.apache.org/log4j/2.x/manual/configuration.html#Arbiters].
However, we do understand that no matter how hard we try to explain that it is
a bad idea that people still want to do it. To that end I will try to respond
to some of your options.
Modifying the Node tree - So long as you know what you are doing this is very
safe. In a sense that is exactly what Arbiters do - they evaluate some
condition and then either include the nodes or they don't.
Yes, you can override preConfigure(). But again, you are doing the same thing
an Arbiter would do.
> Create new builder from existing Appender
> -
>
> Key: LOG4J2-3469
> URL: https://issues.apache.org/jira/browse/LOG4J2-3469
> Project: Log4j 2
> Issue Type: New Feature
> Components: Configuration, Configurators, Core
>Affects Versions: 2.17.2
>Reporter: Jody Garnett
>Priority: Minor
> Attachments: DEFAULT_LOGGING.xml
>
>
>
> The documentation covers both [Initialize Log4j by Combining Configuration
> File with Programmatic
> Configuration|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Hybrid]
> and [Programmatically Modifying the Current Configuration after
> Initialization|https://logging.apache.org/log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_Configuration_after_Initialization].
>
> However both these techniques are limited as to what they can accomplish:
> * MyXMLConfiguration.doConfigure() is shown adding an appender, via
> addLogger method
> * A custom configuration super.setup() method is shown using
> config.addLogger() and then ctx.updateLoggers().
> My challenge is to programatically update the configuration to:
> * Override logfile output location, either directly modifying appender, or
> modifying config property used by appender.
> * Optionally Filter out any RollingFileAppender or FileAppender appenders
> * Optionally suppress (filter out) any Console loggers if asked
> I am seeking an api used to pre-process configuration objects if one is
> available.
> In the past when using a fluent / builder API there is an option to
> jump-start a builder with the configuration of an existing object. This
> approach would allow a builder to be loaded with an existing appender;
> revised, and a new appender generated as a replacement.
> {code:java}
> @Override protected void doConfigure() {
> super.doConfigure();
> getProperties().put("GEOSERVER_LOG_LOCATION","geoserver.log");
> Appender appender = getAppenders("geoserverlogfile");
> if( appender instanceof RollingFileAppender){
> RollingFileAppender fileAppender =(RollingFileAppender) appender;
> RollingFileAppender replacement =
> RollingFileAppender.newBuilder(fileAppender)
> .withFileName("${GEOSERVER_LOG_LOCATION}.log")
> .withFilePattern("${GEOSERVER_LOG_LOCATION}-%i.log")
> .build();
>
> getAppenders().remove("geoserverlogfile");
> addAppender(replacement);
> }
> }{code}
> The alternative is verbose and may miss copying new parameters added over
> time.
> Alternatives considered:
> *MyXMLConfiguration.setup()* prior to super.setup(): Unclear how easy/safe it
> is to to modify _rootNode_ structure directly? Is this what is intended by
> the documentation.
> {code:java}
> public void setup() {
> for( Node child : rootNode.getChildren()){
> if ("Properties".equals(child.getName())){
> for( Node property : child.getChildren() ){
> if( property.getAttributes().containsKey("name") &&
>
> property.getAttributes().get("name").equals("GEOSERVER_LOG_LOCATION")) {
> // override value with current GEOSERVER_LOG_LOCATION
> property.setValue("foo.log");
> }
> }
> }
> }
> super.setup();
> }{code}
>
