[jira] [Commented] (LOG4J2-3459) Reduce use of class static initialization blocks
[ https://issues.apache.org/jira/browse/LOG4J2-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515611#comment-17515611 ] Carter Kozak commented on LOG4J2-3459: -- I’ve used jmh for this sort of thing using oneshot mode with zero warmup, one iteration, 1 thread, and N forks (the number of times to spin up a jvm). The benchmark body just need to trigger log4j init and maybe log a single event depending what we want to measure. The async profiler integration should give helpful data > Reduce use of class static initialization blocks > > > Key: LOG4J2-3459 > URL: https://issues.apache.org/jira/browse/LOG4J2-3459 > Project: Log4j 2 > Issue Type: Improvement > Components: API, Core >Reporter: Matt Sicker >Priority: Major > > There are numerous classes that use static initializer blocks to perform > computation for caching some results. These should all generally be deferred > until some other reference to the class such as instantiation of use of a > singleton getter method. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-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=17515576#comment-17515576 ] Piotr Karwasz commented on LOG4J2-3436: --- [~ragini], The PR has been merged, you can check the latest snapshot now. > 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] [Resolved] (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 resolved LOG4J2-3359.
---
Resolution: Fixed
[~TukeshK],
A fixed version of the syslog appender builder is available in the latest
2.17.3 snapshot: [http://repository.apache.org/snapshots]
Can you check if it solves your problem and close the issue?
> 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
> Fix For: 2.17.3
>
> 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] [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=17515564#comment-17515564
]
ASF subversion and git services commented on LOG4J2-3359:
-
Commit 209dc1362e7232a5a46df813119634453486c001 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=209dc13 ]
Adds changelog entry for LOG4J2-3359
> 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
> Fix For: 2.17.3
>
> 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] [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=17515559#comment-17515559
]
ASF subversion and git services commented on LOG4J2-3359:
-
Commit 693c99b81e4ddf679a78b1f50ad4b78e81d8e2b8 in logging-log4j2's branch
refs/heads/master from ppkarwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=693c99b ]
[LOG4J2-3359] Adds Log4j 1.x specific syslog layout (#807)
Log4j 1.x always used the BSD syslog layout, but allowed for an internal
layout to specify the _MESSAGE_ format.
> 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
> Fix For: 2.17.3
>
> 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] [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=1751#comment-1751
]
ASF subversion and git services commented on LOG4J2-3419:
-
Commit 4c63bbf7299b404a308c61167db83b0c32d9d322 in logging-log4j2's branch
refs/heads/master from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=4c63bbf ]
[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.
Conflicts:
log4j-1.2-api/src/main/java/org/apache/log4j/builders/layout/PatternLayoutBuilder.java
log4j-1.2-api/src/main/java/org/apache/log4j/builders/layout/SimpleLayoutBuilder.java
> 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, Level.java, log4j.properties
>
>
> 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-3447) Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing huge data in multithreading)
[
https://issues.apache.org/jira/browse/LOG4J2-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515557#comment-17515557
]
ASF subversion and git services commented on LOG4J2-3447:
-
Commit 8f89a6f5e68a9a5ae26b91991466b87c9dafe9eb in logging-log4j2's branch
refs/heads/master from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=8f89a6f ]
[LOG4J2-3447] Fixes native Log4j1 appenders concurrency problems
> Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing
> huge data in multithreading)
> --
>
> Key: LOG4J2-3447
> URL: https://issues.apache.org/jira/browse/LOG4J2-3447
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
> Attachments: JavaLoggingMultiThTest.txt
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With Log4j1.x there was no issue with multithreading but with log4j 1.x
> bridge we have noticed that in multithreading environment there is a huge
> data loss while logging, however single thread works fine. I see that in
> Category.java which Logger extends; many methods are not synchronized any
> more in log4j1.x bridge however which were synchronized in case of log4j1.x.
> I suspect this could be root causes of this multithreading problem.
> So as per my understanding synchronized class Category.java in the log4j1.x
> has become unsynchronized in log4j1.x 2.17.2 bridge. I am not sure if I am
> missing something.
> We wanted to know how to achieve successful multithreading logging using
> log4j 1.x 2.17.2 bridge.
> For reference, few methods which were synchronized earlier in log4j1.x but
> not anymore in log4j1.x bridge.
> # public void addAppender(final Appender appender)
> # public Appender getAppender(final String name)
> # public void removeAppender(final Appender appender)
> # public void removeAllAppenders()
> # In log4j 1.x bridge following method is used for logging which doesn't
> look like synchronized. -> void maybeLog(final String fqcn, final
> org.apache.logging.log4j.Level level, final Object message, final Throwable
> throwable); However in log4j1.x following method was used which looks like
> synchronized. -> void forcedLog(String fqcn, Priority level, Object message,
> Throwable t) -> void callAppenders(LoggingEvent event), where method void
> callAppenders(LoggingEvent event) looks snychronized.
>
> I am attaching sample test program as well which I have used to test
> multithreading logging in my application. (Please Note that in this test
> program, class CustomLogger is a dummy class, which you would need to replace
> with your logger). We are using Custom Rolling Appender in our application
> and following is the content of log4j properties file.
> [^JavaLoggingMultiThTest.txt]
> #Custom Rolling Appender
> log4j.appender.R=test.CustomMultiProcessRollingAppender
> log4j.appender.R.File=${user.home}/log4j-multithreading-test.log
> log4j.appender.R.RollOverOnStartup=true
> log4j.appender.R.RollOverOnSize=false
> log4j.appender.R.RollOverMaxFileSize=100MB
> log4j.appender.R.RollOverMaxBackupIndex=10
> log4j.appender.R.RollOverOnPeriodic=false
> log4j.appender.R.RollOverPeriodicStartDate=
> log4j.appender.R.RollOverPeriodicFrequency=1
> log4j.appender.R.layout=org.apache.log4j.PatternLayout
> log4j.appender.R.layout.ConversionPattern=%d %-8M [%t] - %m%n
--
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=17515556#comment-17515556
]
ASF subversion and git services commented on LOG4J2-3419:
-
Commit c44d7e8e3ae4eaf2c941d6cac7502d073e0a1a06 in logging-log4j2's branch
refs/heads/master from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c44d7e8 ]
[LOG4J2-3419] Allows %pid in Log4j 1.x patterns
Although `%pid` was never a valid Log4j 1.x pattern, it was supported in
the previous bridge versions.
This fixes a regression with respect to `log4j-1.2-api` version 2.17.2.
Conflicts:
log4j-1.2-api/src/main/java/org/apache/log4j/builders/layout/PatternLayoutBuilder.java
> 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, Level.java, log4j.properties
>
>
> 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=17515554#comment-17515554
]
ASF subversion and git services commented on LOG4J2-3419:
-
Commit aef43014f7609cb93bc2dc6c0eba58b3aa46eb19 in logging-log4j2's branch
refs/heads/master from ppkarwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=aef4301 ]
[LOG4J2-3419] Adds support for custom Log4j 1.x levels (#789)
* [LOG4J2-3419] Adds support for custom Log4j 1.x levels
Adds support for custom Log4j 1.x level in the form
`level_name#class_name`.
Levels defined directly in Log4j 2.x can be used in the bridge using the
form `level_name#org.apache.logging.log4j.Level`.
Conflicts:
log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1Configuration.java
> 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, Level.java, log4j.properties
>
>
> 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-3423) JAR file containing Log4j configuration isn't closed
[
https://issues.apache.org/jira/browse/LOG4J2-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515553#comment-17515553
]
ASF subversion and git services commented on LOG4J2-3423:
-
Commit 9fcb3c0153b4e4517eb7ee797234d3dfdee04ba1 in logging-log4j2's branch
refs/heads/master from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=9fcb3c0 ]
[LOG4J2-3423] Refactoring of URLConnection code
Refactors the code to minimize the number of calls to `URLConnection`
methods.
Conflicts:
log4j-core/src/main/java/org/apache/logging/log4j/core/config/ConfigurationFactory.java
log4j-core/src/main/java/org/apache/logging/log4j/core/config/ConfigurationSource.java
log4j-core/src/test/java/org/apache/logging/log4j/core/config/ConfigurationSourceTest.java
log4j-core/src/test/java/org/apache/logging/log4j/core/net/UrlConnectionFactoryTest.java
log4j-core/src/test/java/org/apache/logging/log4j/core/util/NetUtilsTest.java
> JAR file containing Log4j configuration isn't closed
>
>
> Key: LOG4J2-3423
> URL: https://issues.apache.org/jira/browse/LOG4J2-3423
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.14.0
> Environment: Windows
>Reporter: Radim Tlusty
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.3
>
>
> If the Log4j configuration file is inside of a JAR file, then the JAR file
> (which is backed by the {{JarURLConnection}} retrieved from
> {{{}URL.openConnection{}}}) isn't closed.
> This causes problems on Tomcat running on Windows during undeploying of an
> application, because the opened JAR file can't be deleted.
> The problem was introduced during implementation of LOG4J2-2901 (version
> 2.14.0), where the {{URL.openStream}} was replaced by {{URL.openConnection}}
> in the class {{{}org.apache.logging.log4j.core.config.ConfigurationSource{}}}.
> The proposed solution (https://github.com/apache/logging-log4j2/pull/780) is
> to use the {{URL.openConnection}} only when needed (~ configuration URL has
> HTTPS protocol), otherwise similar code as in previous versions (<= 2.13.3)
> would be used.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3459) Reduce use of class static initialization blocks
[ https://issues.apache.org/jira/browse/LOG4J2-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515550#comment-17515550 ] Matt Sicker commented on LOG4J2-3459: - I'm literally asking _how do I do that?_ Every guide I've found about profiling Java applications has you attaching to a running application at which point we're _well_ past the point where I'm trying to measure anything. > Reduce use of class static initialization blocks > > > Key: LOG4J2-3459 > URL: https://issues.apache.org/jira/browse/LOG4J2-3459 > Project: Log4j 2 > Issue Type: Improvement > Components: API, Core >Reporter: Matt Sicker >Priority: Major > > There are numerous classes that use static initializer blocks to perform > computation for caching some results. These should all generally be deferred > until some other reference to the class such as instantiation of use of a > singleton getter method. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-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=17515520#comment-17515520
]
ASF subversion and git services commented on LOG4J2-3359:
-
Commit 02128be2330f73a00ecb66bf48bf7740f269a5ce in logging-log4j2's branch
refs/heads/release-2.x from ppkarwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=02128be ]
[LOG4J2-3359] Adds Log4j 1.x specific syslog layout (#807)
* [LOG4J2-3359] Adds Log4j 1.x specific syslog layout
Log4j 1.x always used the BSD syslog layout, but allowed for an internal layout
to specify the _MESSAGE_ format.
> 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
> Fix For: 2.17.3
>
> 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)
[GitHub] [logging-log4j2] ppkarwasz merged pull request #807: [LOG4J2-3359] Adds Log4j 1.x specific syslog layout
ppkarwasz merged pull request #807: URL: https://github.com/apache/logging-log4j2/pull/807 -- 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 #810: Update Spring to 5.3.18 which fixes CVE-2022-22965 aka "Spring4shell".
garydgregory commented on pull request #810: URL: https://github.com/apache/logging-log4j2/pull/810#issuecomment-1084927755 Dependabot takes care of this for us. -- 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] loganaden opened a new pull request #810: Update Spring to 5.3.18 which fixes CVE-2022-22965 aka "Spring4shell".
loganaden opened a new pull request #810: URL: https://github.com/apache/logging-log4j2/pull/810 See details: https://tanzu.vmware.com/security/cve-2022-22965 -- 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-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515450#comment-17515450
]
Matt Sicker commented on LOG4J2-2795:
-
I should note that I've also made several static init blocks lazy, though not
all of them (some looked fairly trivial), and many of those will still end up
being executed once you start logging. Try out master again and let me know
what you think.
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515448#comment-17515448
]
Matt Sicker commented on LOG4J2-2795:
-
Collecting plugins only loads the metadata for each plugin, not the plugin
class itself. The class isn't loaded until we need to first create a plugin of
that type. Basically, the configuration nodes are matched to PluginType
instances which contain the metadata and a way to load the corresponding plugin
class. Only when a plugin is referenced in a configuration do we attempt to
load its corresponding plugin class and then construct it.
As for the cache file decoding, that's for backward compatibility with 2.x. We
don't generate any plugin cache file anymore, so that shouldn't be adding any
time except for looking to see if a resource exists in the ClassLoader.
Basically, it might help to do some profiling here to find what's really taking
so much time.
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3454) how to force rolling file appender to create a new log file every time when we start the application?
[ https://issues.apache.org/jira/browse/LOG4J2-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515444#comment-17515444 ] Ralph Goers edited comment on LOG4J2-3454 at 3/31/22, 5:08 PM: --- # See the OnStartupTriggeringPolicy in the [manual|[https://logging.apache.org/log4j/2.x/manual/appenders.html#TriggeringPolicies].] # If at all possible don't write your own. # See PatternSelectors in the [manual|http://https://logging.apache.org/log4j/2.x/manual/layouts.html#Pattern_Selectors]. You can implement your own PatternSelector if one of the existing ones doesn't meet your needs. was (Author: ralph.go...@dslextreme.com): # See the OnStartupTriggeringPolicy in the [manual|[https://logging.apache.org/log4j/2.x/manual/appenders.html#TriggeringPolicies].] # If at all possible don't write your own. # See PatternSelectors in the [manual|[http://https://logging.apache.org/log4j/2.x/manual/layouts.html#Pattern_Selectors].|http://https//logging.apache.org/log4j/2.x/manual/layouts.html#Pattern_Selectors].] You can implement your own PatternSelector if one of the existing ones doesn't meet your needs. > how to force rolling file appender to create a new log file every time when > we start the application? > - > > Key: LOG4J2-3454 > URL: https://issues.apache.org/jira/browse/LOG4J2-3454 > Project: Log4j 2 > Issue Type: Question >Affects Versions: 2.17.2 >Reporter: Janardhan Naidu >Priority: Major > > HI Team, > > I am in process of migrating the log4j1 to log4j2, where we are rewriting the > appenders with the help of AbstractAppender Plugin or using the property > file. I have multiple questions regarding this, please help me to resolve the > same. > # how to force rolling file appender to create a new log file every time > when we start the application? here, consider appenders are configured in > property file. > # We are rewriting one of the rollingfileappender using the > abstractappender/abstractfileappender plugin way, But i am unable to find a > method which will get executed before starting of the appender!. in log4j1, > we had a method called *checkEntryConditions.* So what is the equalent api in > log4j2.? FYI, we are overriding this method to set all our configurations > like backup the old logfile, createnew logger, rolling etc.., > # Also, we need to set the ConversionPattern based on the loggername, how we > can achieve this.? in log4j1, we were extending patternLayout and overriding > the format method to do the same. So how we can acheive this using log4j2? > > Thanks > Janardhan -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3454) how to force rolling file appender to create a new log file every time when we start the application?
[ https://issues.apache.org/jira/browse/LOG4J2-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515444#comment-17515444 ] Ralph Goers commented on LOG4J2-3454: - # See the OnStartupTriggeringPolicy in the [manual|[https://logging.apache.org/log4j/2.x/manual/appenders.html#TriggeringPolicies].] # If at all possible don't write your own. # See PatternSelectors in the [manual|[http://https://logging.apache.org/log4j/2.x/manual/layouts.html#Pattern_Selectors].|http://https//logging.apache.org/log4j/2.x/manual/layouts.html#Pattern_Selectors].] You can implement your own PatternSelector if one of the existing ones doesn't meet your needs. > how to force rolling file appender to create a new log file every time when > we start the application? > - > > Key: LOG4J2-3454 > URL: https://issues.apache.org/jira/browse/LOG4J2-3454 > Project: Log4j 2 > Issue Type: Question >Affects Versions: 2.17.2 >Reporter: Janardhan Naidu >Priority: Major > > HI Team, > > I am in process of migrating the log4j1 to log4j2, where we are rewriting the > appenders with the help of AbstractAppender Plugin or using the property > file. I have multiple questions regarding this, please help me to resolve the > same. > # how to force rolling file appender to create a new log file every time > when we start the application? here, consider appenders are configured in > property file. > # We are rewriting one of the rollingfileappender using the > abstractappender/abstractfileappender plugin way, But i am unable to find a > method which will get executed before starting of the appender!. in log4j1, > we had a method called *checkEntryConditions.* So what is the equalent api in > log4j2.? FYI, we are overriding this method to set all our configurations > like backup the old logfile, createnew logger, rolling etc.., > # Also, we need to set the ConversionPattern based on the loggername, how we > can achieve this.? in log4j1, we were extending patternLayout and overriding > the format method to do the same. So how we can acheive this using log4j2? > > Thanks > Janardhan -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515433#comment-17515433
]
Ralph Goers commented on LOG4J2-3457:
-
[~pkarwasz] RollingFileAppender does not expose the locking parameter on
purpose. The reason for this is that rolling is not safe as it is likely to
want to be performed by all the servers at the same time. When I read d the
code it looked like the ".roll" file is being used as a sort of lock. It is
created at the beginning of a rollover so other processes can see that it is
already in progress. Those processes would need to change their output streams
to point to the new file once rollover is complete.
That said, I agree with your conclusion.
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Assignee: Piotr Karwasz
>Priority: Major
> Attachments:
> CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG,
> CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> In our application we require a rolling file appender which can be used
> across multiple processes targeting the same file.
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
> !CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG|width=756,height=434!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3460) Structured fields are no longer printed when using log4j 2.17.1
[
https://issues.apache.org/jira/browse/LOG4J2-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
DarkGoofy updated LOG4J2-3460:
--
Description:
When we upgraded our Spring to use log4j 2.17.1 the structured logs no longer
contained any structured fields we added to the log statement.
I am logging several structured arguments as follows
{code:java}
log.info("Get container",
v("TENANT_ID", tenantId),
v("CONTAINER_ID", containerId)){code}
NOTE: That class is instrumented with@Log4j2 (lombok)
but not seeing the arguments in the JSON in the log file
{code:java}
{
"ts":"2022-02-02T18:22:21.312Z",
"level":"INFO",
"msg":"Get container"
} {code}
logback-spring.xml
{code:java}
logback-spring.xml
Signal Service
ts
UTC
level
false
stack
msg
{code}
This issue is linked with the commit :
[https://github.com/apache/logging-log4j2/commit/487588b7c34bc0b540e769d98c42d018fa1bc1b8]
!LOG4J2-3460.png!
Why the parameters (message.getParameters()) is not propaged (the null value is
propaged) ?
was:
When we upgraded our Spring to use log4j 2.17.1 the structured logs no longer
contained any structured fields we added to the log statement.
I am logging several structured arguments as follows
{code:java}
log.info("Get container",
v("TENANT_ID", tenantId),
v("CONTAINER_ID", containerId)){code}
NOTE: That class is instrumented with@Log4j2 (lombok)
but not seeing the arguments in the JSON in the log file
{code:java}
{
"app":"Signal Service",
"ts":"2022-02-02T18:22:21.312Z",
"level":"INFO",
"class":"com.tbd.platform.signal.controller.ContainerController",
"method":"getContainer",
"caller_file_name":"ContainerController.java",
"line":153,"thread":"http-nio-8080-exec-2",
"msg":"Get container"
} {code}
logback-spring.xml
{code:java}
logback-spring.xml
Signal Service
ts
UTC
level
false
stack
msg
{code}
This issue is linked with the commit :
[https://github.com/apache/logging-log4j2/commit/487588b7c34bc0b540e769d98c42d018fa1bc1b8]
!LOG4J2-3460.png!
Why the parameters (message.getParameters()) is not propaged (the null value is
propaged) ?
> Structured fields are no longer printed when using log4j 2.17.1
> ---
>
> Key: LOG4J2-3460
> URL: https://issues.apache.org/jira/browse/LOG4J2-3460
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-SLF4J
>Affects Versions: 2.17.1
>Reporter: DarkGoofy
>Priority: Critical
> Attachments: LOG4J2-3460.png
>
>
> When we upgraded our Spring to use log4j 2.17.1 the structured logs no longer
> contained any structured fields we added to the log statement.
> I am logging several structured arguments as follows
>
> {code:java}
> log.info("Get container",
> v("TENANT_ID", tenantId),
> v("CONTAINER_ID", containerId)){code}
>
> NOTE: That class is instrumented with@Log4j2 (lombok)
> but not seeing the arguments in the JSON in the log file
> {code:java}
> {
> "ts":"2022-02-02T18:22:21.312Z",
> "level":"INFO",
> "msg":"Get container"
> } {code}
>
> logback-spring.xml
>
> {code:java}
> logback-spring.xml
>
> Signal Service
>
> class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
>
>
> ts
> UTC
>
>
> level
>
>
>
>
> false
>
>
> stack
>
>
> msg
>
>
>
>
>
>
>
> {code}
>
>
>
> This issue is linked with the commit :
> [https://github.com/apache/logging-log4j2/commit/487588b7c34bc0b540e769d98c42d018fa1bc1b8]
> !LOG4J2-3460.png!
>
> Why the parameters (message.getParameters()) is not propaged (the null value
> is
[jira] [Updated] (LOG4J2-3460) Structured fields are no longer printed when using log4j 2.17.1
[
https://issues.apache.org/jira/browse/LOG4J2-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
DarkGoofy updated LOG4J2-3460:
--
Description:
When we upgraded our Spring to use log4j 2.17.1 the structured logs no longer
contained any structured fields we added to the log statement.
I am logging several structured arguments as follows
{code:java}
log.info("Get container",
v("TENANT_ID", tenantId),
v("CONTAINER_ID", containerId)){code}
NOTE: That class is instrumented with@Log4j2 (lombok)
but not seeing the arguments in the JSON in the log file
{code:java}
{
"app":"Signal Service",
"ts":"2022-02-02T18:22:21.312Z",
"level":"INFO",
"class":"com.tbd.platform.signal.controller.ContainerController",
"method":"getContainer",
"caller_file_name":"ContainerController.java",
"line":153,"thread":"http-nio-8080-exec-2",
"msg":"Get container"
} {code}
logback-spring.xml
{code:java}
logback-spring.xml
Signal Service
ts
UTC
level
false
stack
msg
{code}
This issue is linked with the commit :
[https://github.com/apache/logging-log4j2/commit/487588b7c34bc0b540e769d98c42d018fa1bc1b8]
!LOG4J2-3460.png!
Why the parameters (message.getParameters()) is not propaged (the null value is
propaged) ?
was:
When we upgraded our Spring to use log4j 2.17.1 the structured logs no longer
contained any structured fields we added to the log statement.
I am logging several structured arguments as follows
{code:java}
log.info("Get container",
v("TENANT_ID", tenantId),
v("CONTAINER_ID", containerId)){code}
NOTE: That class is instrumented with@Log4j2 (lombok)
but not seeing the arguments in the JSON in the log file
{code:java}
{
"app":"Signal Service",
"ts":"2022-02-02T18:22:21.312Z",
"level":"INFO",
"class":"com.tbd.platform.signal.controller.ContainerController",
"method":"getContainer",
"caller_file_name":"ContainerController.java",
"line":153,"thread":"http-nio-8080-exec-2",
"msg":"Get container"
} {code}
This issue is linked with the commit :
[https://github.com/apache/logging-log4j2/commit/487588b7c34bc0b540e769d98c42d018fa1bc1b8]
!LOG4J2-3460.png!
Why the parameters (message.getParameters()) is not propaged (the null value is
propaged) ?
> Structured fields are no longer printed when using log4j 2.17.1
> ---
>
> Key: LOG4J2-3460
> URL: https://issues.apache.org/jira/browse/LOG4J2-3460
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-SLF4J
>Affects Versions: 2.17.1
>Reporter: DarkGoofy
>Priority: Critical
> Attachments: LOG4J2-3460.png
>
>
> When we upgraded our Spring to use log4j 2.17.1 the structured logs no longer
> contained any structured fields we added to the log statement.
> I am logging several structured arguments as follows
>
> {code:java}
> log.info("Get container",
> v("TENANT_ID", tenantId),
> v("CONTAINER_ID", containerId)){code}
>
> NOTE: That class is instrumented with@Log4j2 (lombok)
> but not seeing the arguments in the JSON in the log file
> {code:java}
> {
> "app":"Signal Service",
> "ts":"2022-02-02T18:22:21.312Z",
> "level":"INFO",
> "class":"com.tbd.platform.signal.controller.ContainerController",
> "method":"getContainer",
> "caller_file_name":"ContainerController.java",
> "line":153,"thread":"http-nio-8080-exec-2",
> "msg":"Get container"
> } {code}
>
> logback-spring.xml
>
> {code:java}
> logback-spring.xml
>
> Signal Service
>
> class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
>
>
> ts
> UTC
>
>
> level
>
>
>
>
> false
>
>
> stack
>
>
> msg
>
>
>
>
>
>
>
> {code}
>
>
>
> This issue is linked with the commit :
> [https://github.com/apache/logging-log4j2/commit/487588b7c34bc0b540e769d98c42d018fa1bc1b8]
> !LOG4J2-3460.png!
>
> Why the parameters (message.getParameters()) is not propaged (the null value
> is propaged) ?
>
>
>
--
This message was sent by
[jira] [Updated] (LOG4J2-3460) Structured fields are no longer printed when using log4j 2.17.1
[
https://issues.apache.org/jira/browse/LOG4J2-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
DarkGoofy updated LOG4J2-3460:
--
Priority: Critical (was: Major)
> Structured fields are no longer printed when using log4j 2.17.1
> ---
>
> Key: LOG4J2-3460
> URL: https://issues.apache.org/jira/browse/LOG4J2-3460
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-SLF4J
>Affects Versions: 2.17.1
>Reporter: DarkGoofy
>Priority: Critical
> Attachments: LOG4J2-3460.png
>
>
> When we upgraded our Spring to use log4j 2.17.1 the structured logs no longer
> contained any structured fields we added to the log statement.
> I am logging several structured arguments as follows
>
> {code:java}
> log.info("Get container",
> v("TENANT_ID", tenantId),
> v("CONTAINER_ID", containerId)){code}
>
> NOTE: That class is instrumented with@Log4j2 (lombok)
> but not seeing the arguments in the JSON in the log file
> {code:java}
> {
> "app":"Signal Service",
> "ts":"2022-02-02T18:22:21.312Z",
> "level":"INFO",
> "class":"com.tbd.platform.signal.controller.ContainerController",
> "method":"getContainer",
> "caller_file_name":"ContainerController.java",
> "line":153,"thread":"http-nio-8080-exec-2",
> "msg":"Get container"
> } {code}
> This issue is linked with the commit :
> [https://github.com/apache/logging-log4j2/commit/487588b7c34bc0b540e769d98c42d018fa1bc1b8]
> !LOG4J2-3460.png!
>
> Why the parameters (message.getParameters()) is not propaged (the null value
> is propaged) ?
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3460) Structured fields are no longer printed when using log4j 2.17.1
[
https://issues.apache.org/jira/browse/LOG4J2-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
DarkGoofy updated LOG4J2-3460:
--
Description:
When we upgraded our Spring to use log4j 2.17.1 the structured logs no longer
contained any structured fields we added to the log statement.
I am logging several structured arguments as follows
{code:java}
log.info("Get container",
v("TENANT_ID", tenantId),
v("CONTAINER_ID", containerId)){code}
NOTE: That class is instrumented with@Log4j2 (lombok)
but not seeing the arguments in the JSON in the log file
{code:java}
{
"app":"Signal Service",
"ts":"2022-02-02T18:22:21.312Z",
"level":"INFO",
"class":"com.tbd.platform.signal.controller.ContainerController",
"method":"getContainer",
"caller_file_name":"ContainerController.java",
"line":153,"thread":"http-nio-8080-exec-2",
"msg":"Get container"
} {code}
This issue is linked with the commit :
[https://github.com/apache/logging-log4j2/commit/487588b7c34bc0b540e769d98c42d018fa1bc1b8]
!LOG4J2-3460.png!
Why the parameters (message.getParameters()) is not propaged (the null value is
propaged) ?
was:
When we upgraded our Spring to use log4j 2.17.1 the structured logs no longer
contained any structured fields we added to the log statement.
I am logging several structured arguments as follows
{{log.info("Get container",
v(StructuredLoggingFields.TENANT_ID, tenantId),
v(StructuredLoggingFields.CONTAINER_ID, containerId));}}
NOTE: That class is instrumented with@Log4j2
but not seeing the arguments in the JSON in the log file
{{{
"app":"Signal Service",
"ts":"2022-02-02T18:22:21.312Z",
"level":"INFO",
"class":"com.tbd.platform.signal.controller.ContainerController",
"method":"getContainer",
"caller_file_name":"ContainerController.java",
"line":153,"thread":"http-nio-8080-exec-2",
"msg":"Get container"
}}}
This issue is linked with the commit :
[https://github.com/apache/logging-log4j2/commit/487588b7c34bc0b540e769d98c42d018fa1bc1b8]
!JwcnOoqgAElFTkSuQmCC!
Why the parameters (message.getParameters()) is not propaged (the null value is
propaged) ?
> Structured fields are no longer printed when using log4j 2.17.1
> ---
>
> Key: LOG4J2-3460
> URL: https://issues.apache.org/jira/browse/LOG4J2-3460
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-SLF4J
>Affects Versions: 2.17.1
>Reporter: DarkGoofy
>Priority: Major
> Attachments: LOG4J2-3460.png
>
>
> When we upgraded our Spring to use log4j 2.17.1 the structured logs no longer
> contained any structured fields we added to the log statement.
> I am logging several structured arguments as follows
>
> {code:java}
> log.info("Get container",
> v("TENANT_ID", tenantId),
> v("CONTAINER_ID", containerId)){code}
>
> NOTE: That class is instrumented with@Log4j2 (lombok)
> but not seeing the arguments in the JSON in the log file
> {code:java}
> {
> "app":"Signal Service",
> "ts":"2022-02-02T18:22:21.312Z",
> "level":"INFO",
> "class":"com.tbd.platform.signal.controller.ContainerController",
> "method":"getContainer",
> "caller_file_name":"ContainerController.java",
> "line":153,"thread":"http-nio-8080-exec-2",
> "msg":"Get container"
> } {code}
> This issue is linked with the commit :
> [https://github.com/apache/logging-log4j2/commit/487588b7c34bc0b540e769d98c42d018fa1bc1b8]
> !LOG4J2-3460.png!
>
> Why the parameters (message.getParameters()) is not propaged (the null value
> is propaged) ?
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3460) Structured fields are no longer printed when using log4j 2.17.1
[
https://issues.apache.org/jira/browse/LOG4J2-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
DarkGoofy updated LOG4J2-3460:
--
Attachment: LOG4J2-3460.png
> Structured fields are no longer printed when using log4j 2.17.1
> ---
>
> Key: LOG4J2-3460
> URL: https://issues.apache.org/jira/browse/LOG4J2-3460
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-to-SLF4J
>Affects Versions: 2.17.1
>Reporter: DarkGoofy
>Priority: Major
> Attachments: LOG4J2-3460.png
>
>
> When we upgraded our Spring to use log4j 2.17.1 the structured logs no longer
> contained any structured fields we added to the log statement.
> I am logging several structured arguments as follows
> {{log.info("Get container",
> v(StructuredLoggingFields.TENANT_ID, tenantId),
> v(StructuredLoggingFields.CONTAINER_ID, containerId));}}
> NOTE: That class is instrumented with@Log4j2
> but not seeing the arguments in the JSON in the log file
> {{{
> "app":"Signal Service",
> "ts":"2022-02-02T18:22:21.312Z",
> "level":"INFO",
> "class":"com.tbd.platform.signal.controller.ContainerController",
> "method":"getContainer",
> "caller_file_name":"ContainerController.java",
> "line":153,"thread":"http-nio-8080-exec-2",
> "msg":"Get container"
> }}}
>
> This issue is linked with the commit :
> [https://github.com/apache/logging-log4j2/commit/487588b7c34bc0b540e769d98c42d018fa1bc1b8]
>
> !JwcnOoqgAElFTkSuQmCC!
> Why the parameters (message.getParameters()) is not propaged (the null value
> is propaged) ?
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (LOG4J2-3460) Structured fields are no longer printed when using log4j 2.17.1
DarkGoofy created LOG4J2-3460:
-
Summary: Structured fields are no longer printed when using log4j
2.17.1
Key: LOG4J2-3460
URL: https://issues.apache.org/jira/browse/LOG4J2-3460
Project: Log4j 2
Issue Type: Bug
Components: Log4j-to-SLF4J
Affects Versions: 2.17.1
Reporter: DarkGoofy
When we upgraded our Spring to use log4j 2.17.1 the structured logs no longer
contained any structured fields we added to the log statement.
I am logging several structured arguments as follows
{{log.info("Get container",
v(StructuredLoggingFields.TENANT_ID, tenantId),
v(StructuredLoggingFields.CONTAINER_ID, containerId));}}
NOTE: That class is instrumented with@Log4j2
but not seeing the arguments in the JSON in the log file
{{{
"app":"Signal Service",
"ts":"2022-02-02T18:22:21.312Z",
"level":"INFO",
"class":"com.tbd.platform.signal.controller.ContainerController",
"method":"getContainer",
"caller_file_name":"ContainerController.java",
"line":153,"thread":"http-nio-8080-exec-2",
"msg":"Get container"
}}}
This issue is linked with the commit :
[https://github.com/apache/logging-log4j2/commit/487588b7c34bc0b540e769d98c42d018fa1bc1b8]
!JwcnOoqgAElFTkSuQmCC!
Why the parameters (message.getParameters()) is not propaged (the null value is
propaged) ?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] ppkarwasz edited a comment on pull request #807: [LOG4J2-3359] Adds Log4j 1.x specific syslog layout
ppkarwasz edited a comment on pull request #807: URL: https://github.com/apache/logging-log4j2/pull/807#issuecomment-1084513836 I added a third parameter to `DatePatternConverter`, so that I can use it with a fixed English locale. I am not documenting it in the manual, because for now it does not work with the `FixedDateFormat`. By replacing `FastDateFormat` from the initial commit with `DatePatternConverter` I want to fix two problems: the generation of garbage, even if it is not needed and the possibility to cache the formatted date. IMHO, #683 should also perform this exchange. -- 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 #807: [LOG4J2-3359] Adds Log4j 1.x specific syslog layout
ppkarwasz commented on pull request #807: URL: https://github.com/apache/logging-log4j2/pull/807#issuecomment-1084513836 I added a third parameter to `DatePatternConverter`, so that I can use it with a fixed English locale. I am not documenting it in the manual, because for now it does not work with the `FixedDateFormat`. By replacing `FastDateFormat` from the initial commit with `DatePatternConverter` I want to fix two problems: the generation of garbage, even if it is not needed and the possibility to cache the formatted date. -- 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 #807: [LOG4J2-3359] Adds Log4j 1.x specific syslog layout
garydgregory commented on pull request #807: URL: https://github.com/apache/logging-log4j2/pull/807#issuecomment-1084406409 @rgoers Ping: Does this look good to you? -- 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-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515220#comment-17515220
]
Piotr Karwasz commented on LOG4J2-3457:
---
[~PoojaTheCoder],
Remark, that acquiring a file lock for each log message is already implemented
in Log4j2's {{FileAppender}} (cf. [locking
parameter|https://logging.apache.org/log4j/2.x/manual/appenders.html#FileAppender]).
The lack of the same option in the {{RollingFileAppender}} can be definitely
addressed, since it is just a configuration problem. By a rudimentary
benchmark, with this feature on your throughput is decreased 2x.
I don't understand what's the "*.roll" file purpose in your code, since it does
not appear to be created anywhere. I believe you don't need this feature for
time-based triggering policies (when you use these policies log files are never
renamed). For size-based triggering policies you might reimplement your
appender by creating a custom {{SizeBasedTriggeringPolicy}} that reads the real
size of the file from time to time (Log4j2 never does that, it triggers
rollovers based on the amount of bytes it wrote to the file) and does something
to prevent multiple applications from rolling over at the same time. That will
cost you even more performance.
Personally I wouldn't bother implementing such a complex feature and I would
use a {{SyslogAppender}} (or {{FlumeAppender}}) and delegate the writing of the
log files to those applications.
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Assignee: Piotr Karwasz
>Priority: Major
> Attachments:
> CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG,
> CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> In our application we require a rolling file appender which can be used
> across multiple processes targeting the same file.
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
> !CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG|width=756,height=434!
--
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=17515216#comment-17515216 ] Ragini Gawande commented on LOG4J2-3436: Hi [~pkarwasz], Any update on this issue? When can we expect a snapshot version with the fix to LOG4J-3359 If possible can you share the date by which the snapshot version will be available? > 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-3454) how to force rolling file appender to create a new log file every time when we start the application?
[ https://issues.apache.org/jira/browse/LOG4J2-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515212#comment-17515212 ] Janardhan Naidu commented on LOG4J2-3454: - any suggestion here? > how to force rolling file appender to create a new log file every time when > we start the application? > - > > Key: LOG4J2-3454 > URL: https://issues.apache.org/jira/browse/LOG4J2-3454 > Project: Log4j 2 > Issue Type: Question >Affects Versions: 2.17.2 >Reporter: Janardhan Naidu >Priority: Major > > HI Team, > > I am in process of migrating the log4j1 to log4j2, where we are rewriting the > appenders with the help of AbstractAppender Plugin or using the property > file. I have multiple questions regarding this, please help me to resolve the > same. > # how to force rolling file appender to create a new log file every time > when we start the application? here, consider appenders are configured in > property file. > # We are rewriting one of the rollingfileappender using the > abstractappender/abstractfileappender plugin way, But i am unable to find a > method which will get executed before starting of the appender!. in log4j1, > we had a method called *checkEntryConditions.* So what is the equalent api in > log4j2.? FYI, we are overriding this method to set all our configurations > like backup the old logfile, createnew logger, rolling etc.., > # Also, we need to set the ConversionPattern based on the loggername, how we > can achieve this.? in log4j1, we were extending patternLayout and overriding > the format method to do the same. So how we can acheive this using log4j2? > > Thanks > Janardhan -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Karwasz reassigned LOG4J2-3457:
-
Assignee: Piotr Karwasz
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Assignee: Piotr Karwasz
>Priority: Major
> Attachments:
> CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG,
> CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> In our application we require a rolling file appender which can be used
> across multiple processes targeting the same file.
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
> !CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG|width=756,height=434!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515116#comment-17515116
]
Romain Manni-Bucau commented on LOG4J2-2795:
[~mattsicker] AFAIK it is not the case on master since
org.apache.logging.log4j.plugins.util.PluginManager#collectPlugins(java.util.List)
is still called and
org.apache.logging.log4j.plugins.util.PluginRegistry#decodeCacheFiles is still
there so there is nothing really lazy or matching only the configuration
surface and not the full scope of log4j. Hope I didn't miss something.
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3453) Filters contains invalid attributes "onMatch", "onMismatch"
[
https://issues.apache.org/jira/browse/LOG4J2-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515094#comment-17515094
]
Piotr Karwasz commented on LOG4J2-3453:
---
[~ana4]: yes, it should. The headaches that come with the properties format
will disappear too. :)
> Filters contains invalid attributes "onMatch", "onMismatch"
> ---
>
> Key: LOG4J2-3453
> URL: https://issues.apache.org/jira/browse/LOG4J2-3453
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Luning Wang
>Priority: Major
> Fix For: 2.17.2
>
>
> The following is my log4j2.properties
> {code:java}
> appender.console.filter.1.type = Filters
> appender.console.filter.1.a.type = ThresholdFilter
> appender.console.filter.1.a.level = info
> appender.console.filter.1.b.type = RegexFilter
> appender.console.filter.1.b.regex = .*Thrift error occurred during processing
> of message.*
> appender.console.filter.1.b.onMatch = deny
> appender.console.filter.1.b.onMismatch = neutral
> {code}
> When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
> `Filters contains invalid attributes "onMatch", "onMismatch"` error message.
> What is correctly conf?
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
