[jira] [Commented] (LOG4J2-3436) Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname
[ https://issues.apache.org/jira/browse/LOG4J2-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507353#comment-17507353 ] Ragini Gawande commented on LOG4J2-3436: [~pkarwasz] I am using RHEL 7.6 and 'uname -n' and 'hostname' is giving correct hostname [root@rag101ga ~]# uname -n rag101ga [root@rag101ga ~]# hostname rag101ga > Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname > -- > > Key: LOG4J2-3436 > URL: https://issues.apache.org/jira/browse/LOG4J2-3436 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders, Log4j 1.2 bridge > Environment: Using log4j 2 bridge API: snapshot version of 2.17.3 > log4j-1.2-api-2.17.3.jar >Reporter: Ragini Gawande >Assignee: Piotr Karwasz >Priority: Blocker > > We are trying to use syslogAppender for our logging but in the logs its > prints localhost.localdomain instead of actual hostname > <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1 > com.test.common.logging.Test | FINE#com.test.common.logging.Level - Can > print FINE > <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1 > com.test.common.logging.Test | INFO#com.test.common.logging.Level - Can > print Info > > Here we are using snapshot version of log4j 2.17.3 > This issue was not seen when using log4j 2.17.1 > > Additional info: > JDK 1.8 > -Dlog4j1.compatibility=true -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [logging-log4j2] dependabot[bot] opened a new pull request #802: Bump activemq-broker from 5.16.4 to 5.17.0
dependabot[bot] opened a new pull request #802: URL: https://github.com/apache/logging-log4j2/pull/802 Bumps [activemq-broker](https://github.com/apache/activemq) from 5.16.4 to 5.17.0. Commits https://github.com/apache/activemq/commit/1f3ccad9bb330cbd7468f9f10ac0b542e7f8b51b";>1f3ccad [maven-release-plugin] prepare release activemq-5.17.0 https://github.com/apache/activemq/commit/a9cb53bd38b322d755fb0617caf2e5662a53f2d0";>a9cb53b Cancel 5.17.0 release https://github.com/apache/activemq/commit/17330be854f917dc5d8ed45acafc3e2367db55f5";>17330be [AMQ-8533] Fix maven-bundle-plugin instructions to avoid shading all packages https://github.com/apache/activemq/commit/482a5e819d6f48ba0a4781c7c6c59d415c655727";>482a5e8 AMQ-8530 - Update to geronimo-annotation_1.3_spec https://github.com/apache/activemq/commit/f25ff1bca268d1ae4dbbb386db3873a362abf607";>f25ff1b AMQ-8528: Fix test failures in integration module https://github.com/apache/activemq/commit/15a2f3de2c87f305f640321ed5d79b31a416d67b";>15a2f3d NO-JIRA: Activate quick-tests by default (https://github-redirect.dependabot.com/apache/activemq/issues/792";>#792) https://github.com/apache/activemq/commit/25823845118ed6e4d8127b7e6063115cf7660fff";>2582384 [maven-release-plugin] prepare for next development iteration https://github.com/apache/activemq/commit/8ad238bb7de6307b6b18aa6b72e36a557940c2af";>8ad238b [maven-release-plugin] prepare release activemq-5.17.0 https://github.com/apache/activemq/commit/f48ac346ab121194c6a5e6f8f8075b5bc4fb030b";>f48ac34 Fix scm section https://github.com/apache/activemq/commit/f5e37f7615b2fd816af33eb1ee5de62c76861dda";>f5e37f7 Update spring.schema in preparation for 5.17.0 release Additional commits viewable in https://github.com/apache/activemq/compare/activemq-5.16.4...activemq-5.17.0";>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
[GitHub] [logging-log4j2] dependabot[bot] opened a new pull request #801: Bump jmh.version from 1.21 to 1.34
dependabot[bot] opened a new pull request #801: URL: https://github.com/apache/logging-log4j2/pull/801 Bumps `jmh.version` from 1.21 to 1.34. Updates `jmh-core` from 1.21 to 1.34 Updates `jmh-generator-annprocess` from 1.21 to 1.34 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] [Created] (LOG4J2-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.
Pooja Pandey created LOG4J2-3437: Summary: Log4j 1.x bridge Request to support programmatically configuring Log4j. Key: LOG4J2-3437 URL: https://issues.apache.org/jira/browse/LOG4J2-3437 Project: Log4j 2 Issue Type: Bug Components: Log4j 1.2 bridge Affects Versions: 2.17.2 Reporter: Pooja Pandey As per log4j migration documentation ([https://logging.apache.org/log4j/2.x/manual/migration.html),|https://logging.apache.org/log4j/2.x/manual/migration.html)] I understand that currently log4j 1.x bridge 2.17.2 doesn't support programmatically configuring log4j appenders. * Limitations of the Log4j 1.x bridge* # *They must not programmatically configure Log4j.* In our application, we have a requirement where we need to add many FileAppender programmatically with various log threshold values. Hoping to get this feature supported in future versions for log4j1.x bridge. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [logging-log4j2] LF-Lin commented on pull request #800: LOG4J2-3019: Fix HtmlLayoutTest on Windows
LF-Lin commented on pull request #800:
URL: https://github.com/apache/logging-log4j2/pull/800#issuecomment-1068601032
Also, I reproduced the result in this
[issue](https://issues.apache.org/jira/browse/LOG4J2-3019) by adding the
following lines in
[testLayoutWithDatePatternFixedFormat()](https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-core/src/test/java/org/apache/logging/log4j/core/layout/HtmlLayoutTest.java#L239),
```java
Locale.setDefault(new Locale("en", "NL")); // en_NL --> 02 Nov
Locale.setDefault(Locale.Category.FORMAT, new Locale("nl", "NL")); // nl_NL
--> 02 nov
```
the result will be: `[ERROR]
HtmlLayoutTest.testLayoutWithDatePatternFixedFormat:242->testLayoutWithDatePatternFixedFormat:273
Incorrect date=02 Nov 2012 21:34:02,123, format=DATE, timezone=GMT+8
==> expected: <02 nov 2012 21:34:02,123> but was: <02 Nov 2012
21:34:02,123> `
--
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] LF-Lin opened a new pull request #800: LOG4J2-3019: Fix HtmlLayoutTest on Windows
LF-Lin opened a new pull request #800: URL: https://github.com/apache/logging-log4j2/pull/800 This PR fixes the [issue](https://issues.apache.org/jira/browse/LOG4J2-3019) that `HtmlLayoutTest.testLayoutWithDatePatternFixedFormat` test fails on Windows. AFAIK, this test only fails in a special case on Windows, that is, the _Windows display language_ and _Regional format_ are inconsistent. For example, my settings are: ``` Windows display language: zh_CN Regional format: en_NL ``` the result will be: `[ERROR] HtmlLayoutTest.testLayoutWithDatePatternFixedFormat:245->testLayoutWithDatePatternFixedFormat:277 Incorrect date=02 十一月 2012 21:34:02,123, format=DATE, timezone=GMT+8 ==> expected: <02 Nov 2012 21:32,123> but was: <02 十一月 2012 21:34:02,123>` - I think the reason is that - the actual value that generated from `layout` at [line 255](https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-core/src/test/java/org/apache/logging/log4j/core/layout/HtmlLayoutTest.java#L255) using `Locale.getDefault()` (zh_CN, which causes `02 十一月`), - the expected value that generated from `DateTimeFormatter.ofPattern()` at [line 269](https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-core/src/test/java/org/apache/logging/log4j/core/layout/HtmlLayoutTest.java#L269) using `Locale.Category.FORMAT` (en_NL, which causes `02 Nov`). It is easy to avoid this issue by manually setting the `locale` argument for `DateTimeFormatter.ofPattern()`, and the results will use the `Locale.getDefault()`. -- 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-3436) Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname
[
https://issues.apache.org/jira/browse/LOG4J2-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507201#comment-17507201
]
Piotr Karwasz edited comment on LOG4J2-3436 at 3/15/22, 10:01 PM:
--
[~ragini]: which OS are you using?
If it is a UNIX derivative, what does '{{uname -n}}' or '{{hostname}}' give
you as hostname?
was (Author: pkarwasz):
[~ragini]: which OS are you using?
If it is a UNIX derivative, what does {{uname -a}} give you as hostname?
> Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname
> --
>
> Key: LOG4J2-3436
> URL: https://issues.apache.org/jira/browse/LOG4J2-3436
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Log4j 1.2 bridge
> Environment: Using log4j 2 bridge API: snapshot version of 2.17.3
> log4j-1.2-api-2.17.3.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
>
> We are trying to use syslogAppender for our logging but in the logs its
> prints localhost.localdomain instead of actual hostname
> <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1
> com.test.common.logging.Test | FINE#com.test.common.logging.Level - Can
> print FINE
> <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1
> com.test.common.logging.Test | INFO#com.test.common.logging.Level - Can
> print Info
>
> Here we are using snapshot version of log4j 2.17.3
> This issue was not seen when using log4j 2.17.1
>
> Additional info:
> JDK 1.8
> -Dlog4j1.compatibility=true
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3432) RollingFileAppender fails after 100 backup cycles if filePattern contains "%04i" .
[
https://issues.apache.org/jira/browse/LOG4J2-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507202#comment-17507202
]
Ralph Goers commented on LOG4J2-3432:
-
Yes, all maintenance fixes go in the next release. But my point still applies.
When we know nothing has changed asking them to verify against the latest
release is just a waster of their time.
> RollingFileAppender fails after 100 backup cycles if filePattern contains
> "%04i" .
> --
>
> Key: LOG4J2-3432
> URL: https://issues.apache.org/jira/browse/LOG4J2-3432
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1, 2.17.2
> Environment: * Red Hat Enterprise Linux Server release 6.10 (Santiago)
> * java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
> * 301873 Mar 9 07:53 log4j-api-2.17.1.jar
> 1790452 Mar 9 07:53 log4j-core-2.17.1.jar
>
>Reporter: Carl Smotricz
>Assignee: Ralph Goers
>Priority: Major
> Attachments: Main.java, log4j2.xml, runit.sh
>
>
> If a {{%i}} formatter in a filePattern includes a width specifier, e.g. "%4i"
> or "%04i", file renaming fails after a certain fixed number of cycles. After
> that, successive backups are renamed to the maximum cycle number and
> overwrite previous files of that same cycle number, regardless of min and max
> settings on the appender. Here are some failure modes I've found by testing:
> * if {{filePattern}} contains {{{}%06i{}}}, cycling breaks after 100.
> * if {{filePattern}} contains {{{}%006i{}}}, it breaks after 100 also.
> * if {{filePattern}} contains {{{}%6i{}}}, it breaks after 10.
> * if {{filePattern}} contains {{%06i}} and
> {{{}DefaultRolloverStrategy.min{}}}=1, {{{}max{}}}=9, it breaks after
> just 1.
> Now, the doc doesn't mention the %i spec supporting width and leading zero
> modifiers in the manner of printf() or String.format() . Yet, those
> variations (which I think other users will also be tempted to try) work -
> until they don't. So apparently width and padding on that spec are
> implemented but buggy.
> The doc for RollingRandomAccessFileAppender explicitly recommends these
> format modifiers:
> {quote}... and/or a %i which represents an integer counter. The integer
> counter allows specifying a padding, like %3i for space-padding the counter
> to 3 digits or (usually more useful) %03i for zero-padding the counter to 3
> digits.
> {quote}
> ...but I haven't verified that the problem occurs with that appender as well.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3436) Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname
[
https://issues.apache.org/jira/browse/LOG4J2-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507201#comment-17507201
]
Piotr Karwasz commented on LOG4J2-3436:
---
[~ragini]: which OS are you using?
If it is a UNIX derivative, what does {{uname -a}} give you as hostname?
> Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname
> --
>
> Key: LOG4J2-3436
> URL: https://issues.apache.org/jira/browse/LOG4J2-3436
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Log4j 1.2 bridge
> Environment: Using log4j 2 bridge API: snapshot version of 2.17.3
> log4j-1.2-api-2.17.3.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
>
> We are trying to use syslogAppender for our logging but in the logs its
> prints localhost.localdomain instead of actual hostname
> <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1
> com.test.common.logging.Test | FINE#com.test.common.logging.Level - Can
> print FINE
> <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1
> com.test.common.logging.Test | INFO#com.test.common.logging.Level - Can
> print Info
>
> Here we are using snapshot version of log4j 2.17.3
> This issue was not seen when using log4j 2.17.1
>
> Additional info:
> JDK 1.8
> -Dlog4j1.compatibility=true
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3359) Facility and priority missing in Syslog message when Syslog log appender and pattern layout is used with log4j1-2 bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Karwasz reassigned LOG4J2-3359:
-
Assignee: Piotr Karwasz (was: Gary D. Gregory)
> Facility and priority missing in Syslog message when Syslog log appender and
> pattern layout is used with log4j1-2 bridge API
> -
>
> Key: LOG4J2-3359
> URL: https://issues.apache.org/jira/browse/LOG4J2-3359
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
> Environment: This issue is reproducible with log4j-2.17.1 &
> log4j-2-17-2
> JDK 1.8
> -Dlog4j1.compatibility=true
> log4j.properties file :-
> log4j.rootLogger=DEBUG,SYSLOG
> log4j.appender.SYSLOG=org.apache.log4j.net.SyslogAppender
> log4j.appender.SYSLOG.Threshold=DEBUG
> log4j.appender.SYSLOG.SyslogHost=localhost:514
> log4j.appender.SYSLOG.protocol=UDP
> log4j.appender.SYSLOG.Facility=LOCAL1
> log4j.appender.SYSLOG.layout=org.apache.log4j.PatternLayout
> log4j.appender.SYSLOG.layout.ConversionPattern=${hostName} MyMain[%pid] :%t:
> %c %-4p - %m%n
>Reporter: Tukesh
>Assignee: Piotr Karwasz
>Priority: Blocker
> Attachments: LoggerExample.java, bug_fac_pri.pcapng,
> bug_fac_pri2.pcapng.pcap, log4j.properties
>
>
> FACILITY and PRIORITY is not included when log4j bridge API sends SysLog
> message. Please find the attached pcap files.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3436) Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname
[ https://issues.apache.org/jira/browse/LOG4J2-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Karwasz updated LOG4J2-3436: -- Component/s: Appenders > Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname > -- > > Key: LOG4J2-3436 > URL: https://issues.apache.org/jira/browse/LOG4J2-3436 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders, Log4j 1.2 bridge > Environment: Using log4j 2 bridge API: snapshot version of 2.17.3 > log4j-1.2-api-2.17.3.jar >Reporter: Ragini Gawande >Assignee: Piotr Karwasz >Priority: Blocker > > We are trying to use syslogAppender for our logging but in the logs its > prints localhost.localdomain instead of actual hostname > <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1 > com.test.common.logging.Test | FINE#com.test.common.logging.Level - Can > print FINE > <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1 > com.test.common.logging.Test | INFO#com.test.common.logging.Level - Can > print Info > > Here we are using snapshot version of log4j 2.17.3 > This issue was not seen when using log4j 2.17.1 > > Additional info: > JDK 1.8 > -Dlog4j1.compatibility=true -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3436) Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname
[ https://issues.apache.org/jira/browse/LOG4J2-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Karwasz reassigned LOG4J2-3436: - Assignee: Piotr Karwasz > Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname > -- > > Key: LOG4J2-3436 > URL: https://issues.apache.org/jira/browse/LOG4J2-3436 > Project: Log4j 2 > Issue Type: Bug > Components: Log4j 1.2 bridge > Environment: Using log4j 2 bridge API: snapshot version of 2.17.3 > log4j-1.2-api-2.17.3.jar >Reporter: Ragini Gawande >Assignee: Piotr Karwasz >Priority: Blocker > > We are trying to use syslogAppender for our logging but in the logs its > prints localhost.localdomain instead of actual hostname > <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1 > com.test.common.logging.Test | FINE#com.test.common.logging.Level - Can > print FINE > <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1 > com.test.common.logging.Test | INFO#com.test.common.logging.Level - Can > print Info > > Here we are using snapshot version of log4j 2.17.3 > This issue was not seen when using log4j 2.17.1 > > Additional info: > JDK 1.8 > -Dlog4j1.compatibility=true -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (LOG4J2-3436) Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname
Ragini Gawande created LOG4J2-3436: -- Summary: Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname Key: LOG4J2-3436 URL: https://issues.apache.org/jira/browse/LOG4J2-3436 Project: Log4j 2 Issue Type: Bug Components: Log4j 1.2 bridge Environment: Using log4j 2 bridge API: snapshot version of 2.17.3 log4j-1.2-api-2.17.3.jar Reporter: Ragini Gawande We are trying to use syslogAppender for our logging but in the logs its prints localhost.localdomain instead of actual hostname <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1 com.test.common.logging.Test | FINE#com.test.common.logging.Level - Can print FINE <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1 com.test.common.logging.Test | INFO#com.test.common.logging.Level - Can print Info Here we are using snapshot version of log4j 2.17.3 This issue was not seen when using log4j 2.17.1 Additional info: JDK 1.8 -Dlog4j1.compatibility=true -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3359) Facility and priority missing in Syslog message when Syslog log appender and pattern layout is used with log4j1-2 bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507128#comment-17507128
]
Piotr Karwasz commented on LOG4J2-3359:
---
The correct formatting of custom Log4j 1.x level names in all appenders,
requires a custom layout for the Log4j 1.x SyslogAppender.
> Facility and priority missing in Syslog message when Syslog log appender and
> pattern layout is used with log4j1-2 bridge API
> -
>
> Key: LOG4J2-3359
> URL: https://issues.apache.org/jira/browse/LOG4J2-3359
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
> Environment: This issue is reproducible with log4j-2.17.1 &
> log4j-2-17-2
> JDK 1.8
> -Dlog4j1.compatibility=true
> log4j.properties file :-
> log4j.rootLogger=DEBUG,SYSLOG
> log4j.appender.SYSLOG=org.apache.log4j.net.SyslogAppender
> log4j.appender.SYSLOG.Threshold=DEBUG
> log4j.appender.SYSLOG.SyslogHost=localhost:514
> log4j.appender.SYSLOG.protocol=UDP
> log4j.appender.SYSLOG.Facility=LOCAL1
> log4j.appender.SYSLOG.layout=org.apache.log4j.PatternLayout
> log4j.appender.SYSLOG.layout.ConversionPattern=${hostName} MyMain[%pid] :%t:
> %c %-4p - %m%n
>Reporter: Tukesh
>Assignee: Gary D. Gregory
>Priority: Blocker
> Attachments: LoggerExample.java, bug_fac_pri.pcapng,
> bug_fac_pri2.pcapng.pcap, log4j.properties
>
>
> FACILITY and PRIORITY is not included when log4j bridge API sends SysLog
> message. Please find the attached pcap files.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3419) Unable to create custom logging level using log4j 2 Bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Karwasz resolved LOG4J2-3419.
---
Resolution: Fixed
[~ragini]: I compiled a new snapshot, can you check if it fixes your level
formatting problem?
The output of the {{SyslogAppender}} should still contain
"level_name#level_class_name", but this problem depends upon a solution of
LOG4J2-3359. Other appenders should display just "level_name".
> Unable to create custom logging level using log4j 2 Bridge API
> --
>
> Key: LOG4J2-3419
> URL: https://issues.apache.org/jira/browse/LOG4J2-3419
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: Using log4j 2 bridge API: log4j-1.2-api-2.17.1.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
> Fix For: 2.17.3
>
> Attachments: DemoCustom.zip
>
>
> Unable to create custom logging level using log4j 2 Bridge API
> Following did not create a custom logging level
> *public static final int FINE_INT = 13000;*
> *public static final Level FINE = new Level(FINE_INT, "FINE", 7);*
>
> Using FINE logging level is considered to be DEBUG level by default while
> printing it
> *Adding log:*
> log.log({*}Level.FINE{*},"PRINT: Level.FINE log");
>
> *Expected log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *FINE* - PRINT:
> Level.FINE log
>
> *Actual log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *DEBUG* - PRINT:
> Level.FINE log
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3419) Unable to create custom logging level using log4j 2 Bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17507076#comment-17507076
]
ASF subversion and git services commented on LOG4J2-3419:
-
Commit 291e03611acaf3abd93c800352eb5644fd4554ca in logging-log4j2's branch
refs/heads/release-2.x from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=291e036 ]
[LOG4J2-3419] Add a Log4j 1.x level name pattern converter
When custom levels are in play the names of Log4j 1.x custom levels
(which are not unique) and those of Log4j 2.x custom levels (which must
be unique) do not match.
There is a need therefore for a pattern converter specific to Log4j 1.x.
> Unable to create custom logging level using log4j 2 Bridge API
> --
>
> Key: LOG4J2-3419
> URL: https://issues.apache.org/jira/browse/LOG4J2-3419
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: Using log4j 2 bridge API: log4j-1.2-api-2.17.1.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
> Fix For: 2.17.3
>
> Attachments: DemoCustom.zip
>
>
> Unable to create custom logging level using log4j 2 Bridge API
> Following did not create a custom logging level
> *public static final int FINE_INT = 13000;*
> *public static final Level FINE = new Level(FINE_INT, "FINE", 7);*
>
> Using FINE logging level is considered to be DEBUG level by default while
> printing it
> *Adding log:*
> log.log({*}Level.FINE{*},"PRINT: Level.FINE log");
>
> *Expected log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *FINE* - PRINT:
> Level.FINE log
>
> *Actual log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *DEBUG* - PRINT:
> Level.FINE log
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] ppkarwasz merged pull request #794: [LOG4J2-3419] Add a Log4j 1.x level name pattern converter
ppkarwasz merged pull request #794: URL: https://github.com/apache/logging-log4j2/pull/794 -- 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 #799: Update CustomConfiguration.java
garydgregory commented on pull request #799: URL: https://github.com/apache/logging-log4j2/pull/799#issuecomment-1068121753 Why? In general, do not touch the license headers unless it is broken. There is no such URL anyway. -- 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] carterkozak commented on a change in pull request #797: LOG4J2-3393 Improve JsonTemplateLayout performance.
carterkozak commented on a change in pull request #797:
URL: https://github.com/apache/logging-log4j2/pull/797#discussion_r827098067
##
File path:
log4j-layout-template-json/src/main/java/org/apache/logging/log4j/layout/template/json/resolver/MessageResolver.java
##
@@ -134,7 +134,10 @@ private static void resolveString(
jsonWriter.writeObjectStart();
jsonWriter.writeObjectKey(fallbackKey);
}
-if (message instanceof StringBuilderFormattable) {
+if (message instanceof CharSequence) {
Review comment:
Is this an optimization for SimpleMessage? I wonder if there's something
we can do better in `jsonWriter.writeString(StringBuilderFormattable)`? in the
SimpleMessage/ReusableSimpleMessage case, I suspect we would do better using
`getFormattedMessage()` as `StringBuilder.append(String)` is faster than
iterating over a charsequence. Note that this would allocate in the case that
the message value is a non-string charsequence.
StringBuilderFormattable handling writes from the original message to an
intermediate StringBuilder, which is escaped into the final StringBuilder. I
think we could probably optimize this process, for instance I think we always
call `quoteString(formattableBuffer, 0, length);` which uses
`StringBuilder.append(cs,start,end)` rather than `StringBuilder.append(cs)` --
unfortunately only the latter appears to be special-cased for
AbstractStringBuilder.
--
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] DavidChinedu23 opened a new pull request #799: Update CustomConfiguration.java
DavidChinedu23 opened a new pull request #799: URL: https://github.com/apache/logging-log4j2/pull/799 Added 2020 to Apache license. -- 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-3419) Unable to create custom logging level using log4j 2 Bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17506952#comment-17506952
]
Piotr Karwasz commented on LOG4J2-3419:
---
[~ragini]: you should open a separate ticket for the last issue, which involves
the {{SyslogAppender}} not custom levels in Log4j 1.x.
The is probably due to a change in your Java version or your system, but if you
are using the BSD syslog format the hostname MUST NOT contain the FQDN of the
machine and this should be enforced by Log4j.
> Unable to create custom logging level using log4j 2 Bridge API
> --
>
> Key: LOG4J2-3419
> URL: https://issues.apache.org/jira/browse/LOG4J2-3419
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: Using log4j 2 bridge API: log4j-1.2-api-2.17.1.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
> Fix For: 2.17.3
>
> Attachments: DemoCustom.zip
>
>
> Unable to create custom logging level using log4j 2 Bridge API
> Following did not create a custom logging level
> *public static final int FINE_INT = 13000;*
> *public static final Level FINE = new Level(FINE_INT, "FINE", 7);*
>
> Using FINE logging level is considered to be DEBUG level by default while
> printing it
> *Adding log:*
> log.log({*}Level.FINE{*},"PRINT: Level.FINE log");
>
> *Expected log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *FINE* - PRINT:
> Level.FINE log
>
> *Actual log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *DEBUG* - PRINT:
> Level.FINE log
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3419) Unable to create custom logging level using log4j 2 Bridge API
[
https://issues.apache.org/jira/browse/LOG4J2-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17506927#comment-17506927
]
Ragini Gawande commented on LOG4J2-3419:
[~pkarwasz]
We have seen one more issue after using the new snapshot of version 2.17.3
<13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1
com.test.common.logging.Test | FINE#com.test.common.logging.Level - Can print
FINE
<13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1
com.test.common.logging.Test | INFO#com.test.common.logging.Level - Can print
Info
Here instead of printing the actual hostname its printing localhost.localdomain
This issue was not seen when using 2.17.1
> Unable to create custom logging level using log4j 2 Bridge API
> --
>
> Key: LOG4J2-3419
> URL: https://issues.apache.org/jira/browse/LOG4J2-3419
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: Using log4j 2 bridge API: log4j-1.2-api-2.17.1.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
> Fix For: 2.17.3
>
> Attachments: DemoCustom.zip
>
>
> Unable to create custom logging level using log4j 2 Bridge API
> Following did not create a custom logging level
> *public static final int FINE_INT = 13000;*
> *public static final Level FINE = new Level(FINE_INT, "FINE", 7);*
>
> Using FINE logging level is considered to be DEBUG level by default while
> printing it
> *Adding log:*
> log.log({*}Level.FINE{*},"PRINT: Level.FINE log");
>
> *Expected log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *FINE* - PRINT:
> Level.FINE log
>
> *Actual log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *DEBUG* - PRINT:
> Level.FINE log
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] ppkarwasz opened a new pull request #798: Try to appease CodeQL
ppkarwasz opened a new pull request #798: URL: https://github.com/apache/logging-log4j2/pull/798 Tries to appease the CodeQL security warning: https://github.com/apache/logging-log4j2/security/code-scanning/5 -- 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] [Assigned] (LOG4J2-3287) document log4j2.system.properties file
[
https://issues.apache.org/jira/browse/LOG4J2-3287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Karwasz reassigned LOG4J2-3287:
-
Assignee: Piotr Karwasz
> document log4j2.system.properties file
> --
>
> Key: LOG4J2-3287
> URL: https://issues.apache.org/jira/browse/LOG4J2-3287
> Project: Log4j 2
> Issue Type: Improvement
>Reporter: Volkan Yazici
>Assignee: Piotr Karwasz
>Priority: Minor
> Fix For: 2.18.0
>
>
> LOG4J2-913 released in 2.12.0 adds support for {{log4j2.system.properties}}
> file, though this feature is not documented. This story aims to improve the
> manual in this regard.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3366) Fix order of property sources
[ https://issues.apache.org/jira/browse/LOG4J2-3366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Karwasz updated LOG4J2-3366: -- Fix Version/s: 2.18.0 > Fix order of property sources > - > > Key: LOG4J2-3366 > URL: https://issues.apache.org/jira/browse/LOG4J2-3366 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.10.0 >Reporter: Piotr Karwasz >Assignee: Piotr Karwasz >Priority: Minor > Fix For: 2.18.0 > > > The current order of system property sources (cf. > [documentation|https://logging.apache.org/log4j/2.x/manual/configuration.html#SystemProperties]) > is rather unnatural, because: > # It gives a higher priority to environment variables than Java system > properties. Java system properties apply to a single JVM, whereas environment > variables might be shared between processes. > # It mixes up property sources accessible to system administrators and those > accessible only to programmers (`log4j2.component.properties`). > IMHO Log4j should prioritize the sources accessible to system administrators > over `log4j2.component.properties`, hence allowing them to easily override > the defaults established by developers. It should also prioritize Java system > properties over environment variables. This is what, e.g. [Spring Boot > does|https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.external-config]. > I propose the following order: > # System properties, > # Environment variables, > # `log4j2.component.properties` as failover. > While technically this would be a breaking change, the official property > source order never worked and bug LOG4J2-3193 was filed only recently. This > proves that almost no one configures the same property in more than one > source. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [logging-log4j2] garydgregory commented on a change in pull request #794: [LOG4J2-3419] Add a Log4j 1.x level name pattern converter
garydgregory commented on a change in pull request #794:
URL: https://github.com/apache/logging-log4j2/pull/794#discussion_r826989952
##
File path:
log4j-1.2-api/src/main/java/org/apache/log4j/pattern/Log4j1LevelPatternConverter.java
##
@@ -0,0 +1,50 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache license, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the license for the specific language governing permissions and
+ * limitations under the license.
+ */
+package org.apache.log4j.pattern;
+
+import org.apache.log4j.helpers.OptionConverter;
+import org.apache.logging.log4j.core.LogEvent;
+import org.apache.logging.log4j.core.config.plugins.Plugin;
+import org.apache.logging.log4j.core.pattern.ConverterKeys;
+import org.apache.logging.log4j.core.pattern.LogEventPatternConverter;
+import org.apache.logging.log4j.core.pattern.PatternConverter;
+
+/**
+ * Outputs the Log4j 1.x level name.
+ */
+@Plugin(name = "Log4j1LevelPatternConverter", category =
PatternConverter.CATEGORY)
+@ConverterKeys({ "v1Level" })
+public class Log4j1LevelPatternConverter extends LogEventPatternConverter {
+
+private static final Log4j1LevelPatternConverter INSTANCE = new
Log4j1LevelPatternConverter();
+
+public static Log4j1LevelPatternConverter newInstance(final String[]
options) {
+return INSTANCE;
+}
+
+private Log4j1LevelPatternConverter() {
+super("Log4j1Level", "v1Level");
+}
+
+@Override
+public void format(LogEvent event, StringBuilder toAppendTo) {
+toAppendTo.append(
Review comment:
Why the weird formatting? I just use one line but that's just me...
--
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 #794: [LOG4J2-3419] Add a Log4j 1.x level name pattern converter
garydgregory commented on a change in pull request #794:
URL: https://github.com/apache/logging-log4j2/pull/794#discussion_r826947124
##
File path:
log4j-1.2-api/src/test/java/org/apache/log4j/config/AbstractLog4j1ConfigurationTest.java
##
@@ -276,7 +276,7 @@ private void testDailyRollingFileAppender(final String
configResource, final Str
public void testConsoleEnhancedPatternLayout() throws Exception {
final PatternLayout layout = (PatternLayout)
testConsole("config-1.2/log4j-console-EnhancedPatternLayout");
-assertEquals("%d{ISO8601} [%t][%c] %-5p %properties %ndc: %m%n",
layout.getConversionPattern());
+assertEquals("%d{ISO8601} [%t][%c] %-5v1Level %properties %ndc: %m%n",
layout.getConversionPattern());
Review comment:
I think we need a comment before this line and ones like it because I am
guessing that "v1Level" was converted by us when users say "level" in their 1.2
configuration files?
--
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 #794: [LOG4J2-3419] Add a Log4j 1.x level name pattern converter
garydgregory commented on a change in pull request #794:
URL: https://github.com/apache/logging-log4j2/pull/794#discussion_r826947124
##
File path:
log4j-1.2-api/src/test/java/org/apache/log4j/config/AbstractLog4j1ConfigurationTest.java
##
@@ -276,7 +276,7 @@ private void testDailyRollingFileAppender(final String
configResource, final Str
public void testConsoleEnhancedPatternLayout() throws Exception {
final PatternLayout layout = (PatternLayout)
testConsole("config-1.2/log4j-console-EnhancedPatternLayout");
-assertEquals("%d{ISO8601} [%t][%c] %-5p %properties %ndc: %m%n",
layout.getConversionPattern());
+assertEquals("%d{ISO8601} [%t][%c] %-5v1Level %properties %ndc: %m%n",
layout.getConversionPattern());
Review comment:
I think we need a comment before this line and one like it because I am
guessing that "v1Level" was converted by us when users say "level" in their 1.2
configuration files?
--
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 #794: [LOG4J2-3419] Add a Log4j 1.x level name pattern converter
garydgregory commented on a change in pull request #794:
URL: https://github.com/apache/logging-log4j2/pull/794#discussion_r826945080
##
File path:
log4j-1.2-api/src/main/java/org/apache/log4j/pattern/Log4j1LevelPatternConverter.java
##
@@ -0,0 +1,49 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache license, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the license for the specific language governing permissions and
+ * limitations under the license.
+ */
+package org.apache.log4j.pattern;
+
+import org.apache.log4j.helpers.OptionConverter;
+import org.apache.logging.log4j.core.LogEvent;
+import org.apache.logging.log4j.core.config.plugins.Plugin;
+import org.apache.logging.log4j.core.pattern.ConverterKeys;
+import org.apache.logging.log4j.core.pattern.LogEventPatternConverter;
+import org.apache.logging.log4j.core.pattern.PatternConverter;
+
+/**
+ * Outputs the Log4j 1.x level name.
+ */
+@Plugin(name = "Log4j1LevelPatternConverter", category =
PatternConverter.CATEGORY)
+@ConverterKeys({ "v1Level" })
+public class Log4j1LevelPatternConverter extends LogEventPatternConverter {
+
+private static final Log4j1LevelPatternConverter INSTANCE = new
Log4j1LevelPatternConverter();
+
+public static Log4j1LevelPatternConverter newInstance(final String[]
options) {
+return INSTANCE;
+}
+
+private Log4j1LevelPatternConverter() {
+super("Log4j1Level", "v1Level");
+}
+
+@Override
+public void format(LogEvent event, StringBuilder toAppendTo) {
+final String levelName =
OptionConverter.convertLevel(event.getLevel()).toString();
+toAppendTo.append(levelName);
Review comment:
I don't think we need this local variable.
--
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 change in pull request #797: LOG4J2-3393 Improve JsonTemplateLayout performance.
ppkarwasz commented on a change in pull request #797:
URL: https://github.com/apache/logging-log4j2/pull/797#discussion_r826905487
##
File path:
log4j-layout-template-json/src/main/java/org/apache/logging/log4j/layout/template/json/resolver/MessageResolver.java
##
@@ -134,7 +134,10 @@ private static void resolveString(
jsonWriter.writeObjectStart();
jsonWriter.writeObjectKey(fallbackKey);
}
-if (message instanceof StringBuilderFormattable) {
+if (message instanceof CharSequence) {
+final CharSequence sequence = (CharSequence) message;
+jsonWriter.writeString(sequence);
Review comment:
I am looking forward for Java 15's `message instanceof CharSequence
sequence`, although I believe that the JIT compiler eliminates the local
variable anyway.
--
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 #797: LOG4J2-3393 Improve JsonTemplateLayout performance.
garydgregory commented on a change in pull request #797:
URL: https://github.com/apache/logging-log4j2/pull/797#discussion_r826897532
##
File path:
log4j-layout-template-json/src/main/java/org/apache/logging/log4j/layout/template/json/resolver/MessageResolver.java
##
@@ -134,7 +134,10 @@ private static void resolveString(
jsonWriter.writeObjectStart();
jsonWriter.writeObjectKey(fallbackKey);
}
-if (message instanceof StringBuilderFormattable) {
+if (message instanceof CharSequence) {
+final CharSequence sequence = (CharSequence) message;
+jsonWriter.writeString(sequence);
Review comment:
I agree with @ppkarwasz, this just makes the code more verbose than it
has to be IMO.
Type casting is not an "operation", it does not do anything.
--
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-3432) RollingFileAppender fails after 100 backup cycles if filePattern contains "%04i" .
[
https://issues.apache.org/jira/browse/LOG4J2-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17506867#comment-17506867
]
Gary D. Gregory edited comment on LOG4J2-3432 at 3/15/22, 11:48 AM:
My POV is different obviously: if there is anything for us to fix, it would be
for the next release, so we would debug the current code or at worse the
current released code tag. This due to the fact that we would not release a
maintenance version "in between" older versions (Log4Shell was a kind of an
exception), IOW we would not release a 2.17.1.1, instead we would put a fix in
the next release, currently labeled 2.17.3. So to me it makes the most sense to
have a bug or behavior confirmed on the most recent release because it has the
least amount of cumulative difference with the current git code and the least
chance for possible side effects. This goes along with my time management as a
volunteer here, waste little of my time, ask users to share in the work, we all
benefit.
was (Author: garydgregory):
My POV is different obviously: if there is anything for us to fix, it would be
for the next release, so we would debug the current code or at worse the
current released code tag. This due to the fact that we would not release a
maintenance version "in between" older versions (Log4Shell was a kind of an
exception), IOW we would not release a 2.17.1.1, instead we would put a fix in
the next release, currently labeled 2.17.3. So to me it makes the most sense to
have a bug or behavior confirmed on the most recent release because it has the
least amount of cumulative difference with the current git code and the least
chance for possible side effects. This goes along with my time management as a
volunteer here, waste little of my time, ask users to share in the word, we all
benefit.
> RollingFileAppender fails after 100 backup cycles if filePattern contains
> "%04i" .
> --
>
> Key: LOG4J2-3432
> URL: https://issues.apache.org/jira/browse/LOG4J2-3432
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1, 2.17.2
> Environment: * Red Hat Enterprise Linux Server release 6.10 (Santiago)
> * java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
> * 301873 Mar 9 07:53 log4j-api-2.17.1.jar
> 1790452 Mar 9 07:53 log4j-core-2.17.1.jar
>
>Reporter: Carl Smotricz
>Assignee: Ralph Goers
>Priority: Major
> Attachments: Main.java, log4j2.xml, runit.sh
>
>
> If a {{%i}} formatter in a filePattern includes a width specifier, e.g. "%4i"
> or "%04i", file renaming fails after a certain fixed number of cycles. After
> that, successive backups are renamed to the maximum cycle number and
> overwrite previous files of that same cycle number, regardless of min and max
> settings on the appender. Here are some failure modes I've found by testing:
> * if {{filePattern}} contains {{{}%06i{}}}, cycling breaks after 100.
> * if {{filePattern}} contains {{{}%006i{}}}, it breaks after 100 also.
> * if {{filePattern}} contains {{{}%6i{}}}, it breaks after 10.
> * if {{filePattern}} contains {{%06i}} and
> {{{}DefaultRolloverStrategy.min{}}}=1, {{{}max{}}}=9, it breaks after
> just 1.
> Now, the doc doesn't mention the %i spec supporting width and leading zero
> modifiers in the manner of printf() or String.format() . Yet, those
> variations (which I think other users will also be tempted to try) work -
> until they don't. So apparently width and padding on that spec are
> implemented but buggy.
> The doc for RollingRandomAccessFileAppender explicitly recommends these
> format modifiers:
> {quote}... and/or a %i which represents an integer counter. The integer
> counter allows specifying a padding, like %3i for space-padding the counter
> to 3 digits or (usually more useful) %03i for zero-padding the counter to 3
> digits.
> {quote}
> ...but I haven't verified that the problem occurs with that appender as well.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3432) RollingFileAppender fails after 100 backup cycles if filePattern contains "%04i" .
[
https://issues.apache.org/jira/browse/LOG4J2-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17506867#comment-17506867
]
Gary D. Gregory edited comment on LOG4J2-3432 at 3/15/22, 11:48 AM:
My POV is different obviously: if there is anything for us to fix, it would be
for the next release, so we would debug the current code or at worse the
current released code tag. This due to the fact that we would not release a
maintenance version "in between" older versions (Log4Shell was a kind of an
exception), IOW we would not release a 2.17.1.1, instead we would put a fix in
the next release, currently labeled 2.17.3. So to me it makes the most sense to
have a bug or behavior confirmed on the most recent release because it has the
least amount of cumulative difference with the current git code and the least
chance for possible side effects. This goes along with my time management as a
volunteer here, waste little of my time, ask users to share in the word, we all
benefit.
was (Author: garydgregory):
My POV is different obviously: if there is anything for us to fix, it would be
for the next release, so we would debug the current code or at worse the
current released code tag. This due to the fact that we would not release a
maintenance version "in between" older versions (Log4Shell was a kind of an
exception), IOW we would not release a 2.17.0.1, instead we would put a fix in
the next release, currently labeled 2.17.3. So to me it makes the most sense to
have a big or behavior confirmed on the most recent release because it has the
least amount of cumulative difference with the current git code and the least
chance for possible side effects. This goes along with my time management as a
volunteer here, waste little of my time, ask users to share in the word, we all
benefit.
> RollingFileAppender fails after 100 backup cycles if filePattern contains
> "%04i" .
> --
>
> Key: LOG4J2-3432
> URL: https://issues.apache.org/jira/browse/LOG4J2-3432
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1, 2.17.2
> Environment: * Red Hat Enterprise Linux Server release 6.10 (Santiago)
> * java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
> * 301873 Mar 9 07:53 log4j-api-2.17.1.jar
> 1790452 Mar 9 07:53 log4j-core-2.17.1.jar
>
>Reporter: Carl Smotricz
>Assignee: Ralph Goers
>Priority: Major
> Attachments: Main.java, log4j2.xml, runit.sh
>
>
> If a {{%i}} formatter in a filePattern includes a width specifier, e.g. "%4i"
> or "%04i", file renaming fails after a certain fixed number of cycles. After
> that, successive backups are renamed to the maximum cycle number and
> overwrite previous files of that same cycle number, regardless of min and max
> settings on the appender. Here are some failure modes I've found by testing:
> * if {{filePattern}} contains {{{}%06i{}}}, cycling breaks after 100.
> * if {{filePattern}} contains {{{}%006i{}}}, it breaks after 100 also.
> * if {{filePattern}} contains {{{}%6i{}}}, it breaks after 10.
> * if {{filePattern}} contains {{%06i}} and
> {{{}DefaultRolloverStrategy.min{}}}=1, {{{}max{}}}=9, it breaks after
> just 1.
> Now, the doc doesn't mention the %i spec supporting width and leading zero
> modifiers in the manner of printf() or String.format() . Yet, those
> variations (which I think other users will also be tempted to try) work -
> until they don't. So apparently width and padding on that spec are
> implemented but buggy.
> The doc for RollingRandomAccessFileAppender explicitly recommends these
> format modifiers:
> {quote}... and/or a %i which represents an integer counter. The integer
> counter allows specifying a padding, like %3i for space-padding the counter
> to 3 digits or (usually more useful) %03i for zero-padding the counter to 3
> digits.
> {quote}
> ...but I haven't verified that the problem occurs with that appender as well.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3432) RollingFileAppender fails after 100 backup cycles if filePattern contains "%04i" .
[
https://issues.apache.org/jira/browse/LOG4J2-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17506867#comment-17506867
]
Gary D. Gregory commented on LOG4J2-3432:
-
My POV is different obviously: if there is anything for us to fix, it would be
for the next release, so we would debug the current code or at worse the
current released code tag. This due to the fact that we would not release a
maintenance version "in between" older versions (Log4Shell was a kind of an
exception), IOW we would not release a 2.17.0.1, instead we would put a fix in
the next release, currently labeled 2.17.3. So to me it makes the most sense to
have a big or behavior confirmed on the most recent release because it has the
least amount of cumulative difference with the current git code and the least
chance for possible side effects. This goes along with my time management as a
volunteer here, waste little of my time, ask users to share in the word, we all
benefit.
> RollingFileAppender fails after 100 backup cycles if filePattern contains
> "%04i" .
> --
>
> Key: LOG4J2-3432
> URL: https://issues.apache.org/jira/browse/LOG4J2-3432
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.1, 2.17.2
> Environment: * Red Hat Enterprise Linux Server release 6.10 (Santiago)
> * java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
> * 301873 Mar 9 07:53 log4j-api-2.17.1.jar
> 1790452 Mar 9 07:53 log4j-core-2.17.1.jar
>
>Reporter: Carl Smotricz
>Assignee: Ralph Goers
>Priority: Major
> Attachments: Main.java, log4j2.xml, runit.sh
>
>
> If a {{%i}} formatter in a filePattern includes a width specifier, e.g. "%4i"
> or "%04i", file renaming fails after a certain fixed number of cycles. After
> that, successive backups are renamed to the maximum cycle number and
> overwrite previous files of that same cycle number, regardless of min and max
> settings on the appender. Here are some failure modes I've found by testing:
> * if {{filePattern}} contains {{{}%06i{}}}, cycling breaks after 100.
> * if {{filePattern}} contains {{{}%006i{}}}, it breaks after 100 also.
> * if {{filePattern}} contains {{{}%6i{}}}, it breaks after 10.
> * if {{filePattern}} contains {{%06i}} and
> {{{}DefaultRolloverStrategy.min{}}}=1, {{{}max{}}}=9, it breaks after
> just 1.
> Now, the doc doesn't mention the %i spec supporting width and leading zero
> modifiers in the manner of printf() or String.format() . Yet, those
> variations (which I think other users will also be tempted to try) work -
> until they don't. So apparently width and padding on that spec are
> implemented but buggy.
> The doc for RollingRandomAccessFileAppender explicitly recommends these
> format modifiers:
> {quote}... and/or a %i which represents an integer counter. The integer
> counter allows specifying a padding, like %3i for space-padding the counter
> to 3 digits or (usually more useful) %03i for zero-padding the counter to 3
> digits.
> {quote}
> ...but I haven't verified that the problem occurs with that appender as well.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] vy commented on a change in pull request #797: LOG4J2-3393 Improve JsonTemplateLayout performance.
vy commented on a change in pull request #797:
URL: https://github.com/apache/logging-log4j2/pull/797#discussion_r826880486
##
File path:
log4j-layout-template-json/src/main/java/org/apache/logging/log4j/layout/template/json/resolver/MessageResolver.java
##
@@ -134,7 +134,10 @@ private static void resolveString(
jsonWriter.writeObjectStart();
jsonWriter.writeObjectKey(fallbackKey);
}
-if (message instanceof StringBuilderFormattable) {
+if (message instanceof CharSequence) {
+final CharSequence sequence = (CharSequence) message;
+jsonWriter.writeString(sequence);
Review comment:
Nope, I just find it easier to read and wrap my mind around when there
is one operation per line.
--
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 change in pull request #797: LOG4J2-3393 Improve JsonTemplateLayout performance.
ppkarwasz commented on a change in pull request #797:
URL: https://github.com/apache/logging-log4j2/pull/797#discussion_r826876523
##
File path:
log4j-layout-template-json/src/main/java/org/apache/logging/log4j/layout/template/json/resolver/MessageResolver.java
##
@@ -134,7 +134,10 @@ private static void resolveString(
jsonWriter.writeObjectStart();
jsonWriter.writeObjectKey(fallbackKey);
}
-if (message instanceof StringBuilderFormattable) {
+if (message instanceof CharSequence) {
+final CharSequence sequence = (CharSequence) message;
+jsonWriter.writeString(sequence);
Review comment:
Is the local variable necessary?
--
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] [Closed] (LOG4J2-3435) Possibly invalid module-info.class in jog4j-api-2-17.1.jar
[
https://issues.apache.org/jira/browse/LOG4J2-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Voss closed LOG4J2-3435.
Resolution: Not A Bug
Propably a bug in deployment checks in SAP NWDI. The log4j-api-2.17.1.jar is a
correctly formed multi-release-jar.
> Possibly invalid module-info.class in jog4j-api-2-17.1.jar
> ---
>
> Key: LOG4J2-3435
> URL: https://issues.apache.org/jira/browse/LOG4J2-3435
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.17.1
> Environment: SAP WEB AS 7.50.20 (AIX)
> JVM 1.8 (SAP JVM)
>Reporter: Michael Voss
>Priority: Minor
> Attachments: module-info.class
>
>
> When deploying an application containing log4j-api-2.17.1.jar retrieved via
> maven dependency
> {code:xml}
>
> org.apache.logging.log4j
> log4j-api
> 2.17.1
>
> {code}
> onto a SAP WebApplicationServer running Java 8.1, the deployment (using NWDI)
> fails reporting
> {code}
> com.sap.engine.services.dc.api.deploy.DeployException: [ERROR CODE
> DPL.DCAPI.1027] DeploymentException.
> ...
> Caused by: com.sap.engine.library.bytecode.cf.CFException: Invalid constant
> pool tag, 19 at index 5.
> {code}
> This error is thrown due to an alleged java version conflict, although log4j
> 2.17.1 requires Java 8 only and the application server (and it's deployment
> mechanism) is running on Java 8. After evaluating the feedback from SAP
> support, it seems the attached file {{module-info.class}} located in
> {{log4j-api-2.17.1.jar/META-INF/versions/9/}} is the reason for this
> behaviour. If we remove this file from the jar, the deployment is successful.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (LOG4J2-3435) Possibly invalid module-info.class in jog4j-api-2-17.1.jar
Michael Voss created LOG4J2-3435:
Summary: Possibly invalid module-info.class in
jog4j-api-2-17.1.jar
Key: LOG4J2-3435
URL: https://issues.apache.org/jira/browse/LOG4J2-3435
Project: Log4j 2
Issue Type: Bug
Components: API
Affects Versions: 2.17.1
Environment: SAP WEB AS 7.50.20 (AIX)
JVM 1.8 (SAP JVM)
Reporter: Michael Voss
Attachments: module-info.class
When deploying an application containing log4j-api-2.17.1.jar retrieved via
maven dependency
{code:xml}
org.apache.logging.log4j
log4j-api
2.17.1
{code}
onto a SAP WebApplicationServer running Java 8.1, the deployment (using NWDI)
fails reporting
{code}
com.sap.engine.services.dc.api.deploy.DeployException: [ERROR CODE
DPL.DCAPI.1027] DeploymentException.
...
Caused by: com.sap.engine.library.bytecode.cf.CFException: Invalid constant
pool tag, 19 at index 5.
{code}
This error is thrown due to an alleged java version conflict, although log4j
2.17.1 requires Java 8 only and the application server (and it's deployment
mechanism) is running on Java 8. After evaluating the feedback from SAP
support, it seems the attached file {{module-info.class}} located in
{{log4j-api-2.17.1.jar/META-INF/versions/9/}} is the reason for this behaviour.
If we remove this file from the jar, the deployment is successful.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] vy commented on pull request #779: Bump maven-project-info-reports-plugin from 2.9 to 3.2.2
vy commented on pull request #779: URL: https://github.com/apache/logging-log4j2/pull/779#issuecomment-1067790973 @dependabot rebase -- 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 #778: Bump maven-scm-plugin from 1.9.5 to 1.12.2
vy merged pull request #778: URL: https://github.com/apache/logging-log4j2/pull/778 -- 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 #795: Bump maven-pmd-plugin from 3.10.0 to 3.16.0
vy merged pull request #795: URL: https://github.com/apache/logging-log4j2/pull/795 -- 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 #796: Bump maven-pdf-plugin from 1.2 to 1.5.1
vy merged pull request #796: URL: https://github.com/apache/logging-log4j2/pull/796 -- 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] [Updated] (LOG4J2-3434) Property is not populating "value"
[
https://issues.apache.org/jira/browse/LOG4J2-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kai updated LOG4J2-3434:
Component/s: Appenders
(was: Layouts)
> 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.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (LOG4J2-3434) Property is not populating "value"
Kai created LOG4J2-3434:
---
Summary: Property is not populating "value"
Key: LOG4J2-3434
URL: https://issues.apache.org/jira/browse/LOG4J2-3434
Project: Log4j 2
Issue Type: Bug
Components: Layouts
Affects Versions: 2.17.2
Reporter: Kai
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.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-1514) Help Apache Zookeeper project to upgrade from Log4j 1.x to 2.x
[ https://issues.apache.org/jira/browse/LOG4J2-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17506784#comment-17506784 ] Aman Jain commented on LOG4J2-1514: --- log4j-1.2-api-2.17.0.jar, log4j-api-2.17.0.jar, log4j-core-2.17.0.jar still has the CVE vulnerabilities, so can we use the version greater than 2.17.0 like 2.17.1 or 2.17.2. > Help Apache Zookeeper project to upgrade from Log4j 1.x to 2.x > -- > > Key: LOG4J2-1514 > URL: https://issues.apache.org/jira/browse/LOG4J2-1514 > Project: Log4j 2 > Issue Type: Sub-task >Reporter: Mikael Ståldal >Priority: Major > -- 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=17506777#comment-17506777
]
ASF subversion and git services commented on LOG4J2-3393:
-
Commit af910f65ad0c014b354a648ac5c18eef2f368629 in logging-log4j2's branch
refs/heads/LOG4J2-3393 from Volkan Yazici
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=af910f6 ]
LOG4J2-3393 Make benchmark script to only run Jtl4Ecs methods.
> 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] vy opened a new pull request #797: LOG4J2-3393 Improve JsonTemplateLayout performance.
vy opened a new pull request #797: URL: https://github.com/apache/logging-log4j2/pull/797 * Replace `StringBuilderEncoder` (uses an internal thread-local) and `LockingStringBuilderEncoder` (uses locks) with custom `JsonTemplateLayout.StringBuilderEncoder` class implementing `Encoder` interface. This was made possible by making `TextEncoderHelper.encodeText()` public. This makes use of JTL recyclers and provides better allocation performance. For instance, if JTL is configured with thread-local recycler, each encoding request will trigger a single TLA, whereas previously it needed to do two: one for `JsonTemplateLayout.Context` and `StringBuilderEncoder`. * Add `CharSequence` specialization in `MessageResolver`. * Improve troubleshooting experience by replacing lambdas with classes in `TemplateResolvers`. * Improve locality and branching in `TemplateResolvers`. * Improve JMH 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
