[GitHub] [logging-log4j2] vy commented on pull request #662: Bump tomcat-catalina from 8.5.20 to 10.0.14
vy commented on pull request #662: URL: https://github.com/apache/logging-log4j2/pull/662#issuecomment-1018284569 AFAIK, Tomcat is only used by `log4j-appserver`. There I don't see any dependencies on the `javax` namespace, but just an implementation of `org.apache.juli.logging.Log` packaged by Tomcat. All CI checks also look green – note that there are no tests associated with `log4j-appserver`, though compilation succeeds. I don't see a reason not to upgrade. If the user wants to stick to a Tomcat version <10, they can still do so. `org.apache.juli.logging.Log` looks to be intact, hence I don't foresee any compatibility issues. -- 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-3358) 2.17.1: JsonLayout Context no longer working.
Markus Duft created LOG4J2-3358:
---
Summary: 2.17.1: JsonLayout Context no longer working.
Key: LOG4J2-3358
URL: https://issues.apache.org/jira/browse/LOG4J2-3358
Project: Log4j 2
Issue Type: Bug
Components: Layouts
Affects Versions: 2.17.1
Reporter: Markus Duft
We're creating a RollingFileAppender programmatically using a JsonLayout. This
uses fields using ${ctx:...} expansion. This stopped working when upgrading
from 2.17.0 to 2.17.1.
The code is as follows:
{code:java}
/**
* Creates a rolling file appender that write audit entries to a
programmatically readable JSON file.
*/
private RollingFileAppender createJsonAppender(Path logDir) {
List fields = new ArrayList<>();
fields.add(KeyValuePair.newBuilder().setKey("who").setValue("${ctx:WHO}").build());
fields.add(KeyValuePair.newBuilder().setKey("what").setValue("${ctx:WHAT}").build());
fields.add(KeyValuePair.newBuilder().setKey("method").setValue("${ctx:METHOD}").build());
fields.add(KeyValuePair.newBuilder().setKey("parameters").setValue("${ctx:PARAMETERS}").build());
RollingFileAppender.Builder builder =
RollingFileAppender.newBuilder();
builder.setName("auditJsonLogger");
builder.withFileName(logDir.resolve(LOG_JSON_FILENAME).toString());
builder.withFilePattern(logDir.resolve(LOG_JSON_FILEPATTERN).toString());
builder.withPolicy(SizeBasedTriggeringPolicy.createPolicy("10M"));
builder.setLayout(JsonLayout.newBuilder().setCompact(true).setEventEol(true).setConfiguration(new
DefaultConfiguration())
.setAdditionalFields(fields.toArray(new
KeyValuePair[0])).build());
builder.withStrategy(
DefaultRolloverStrategy.newBuilder().withCompressionLevelStr(String.valueOf(Deflater.DEFAULT_COMPRESSION))
.withMax(Integer.toString(LOG_MAX_INDEX)).withFileIndex("min").build());
return builder.build();
} {code}
We also tried to use %X\{...} expansion instead to no avail. The log file
always contains the *literal* string we use in .setValue(), i.e. lines like
this:
{noformat}
{"instant":{"epochSecond":1642756242,"nanoOfSecond":271091900},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":65,"threadPriority":5,"who":"${ctx:WHO}","what":"${ctx:WHAT}","method":"${ctx:METHOD}","parameters":"${ctx:PARAMETERS}"}{noformat}
Reverting to 2.17.0 will correctly give lines like this in the JSON file:
{noformat}
{"instant":{"epochSecond":1642756430,"nanoOfSecond":923210700},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":62,"threadPriority":5,"who":"marku","what":"ObjectConsistencyCheckOperation","method":"-","parameters":"{dryRun=false,
roots=[io.bdeploy/demo/client-app/linux:1.0.0,
io.bdeploy/demo/client-app/linux:2.0.0,
io.bdeploy/demo/client-app/windows:1.0.0, ...]}"}{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3358) 2.17.1: JsonLayout Context no longer working.
[
https://issues.apache.org/jira/browse/LOG4J2-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Duft updated LOG4J2-3358:
Description:
We're creating a RollingFileAppender programmatically using a JsonLayout. This
uses fields using ${ctx:...} expansion. This stopped working when upgrading
from 2.17.0 to 2.17.1.
The code is as follows:
{code:java}
/**
* Creates a rolling file appender that write audit entries to a
programmatically readable JSON file.
*/
private RollingFileAppender createJsonAppender(Path logDir) {
List fields = new ArrayList<>();
fields.add(KeyValuePair.newBuilder().setKey("who").setValue("${ctx:WHO}").build());
fields.add(KeyValuePair.newBuilder().setKey("what").setValue("${ctx:WHAT}").build());
fields.add(KeyValuePair.newBuilder().setKey("method").setValue("${ctx:METHOD}").build());
fields.add(KeyValuePair.newBuilder().setKey("parameters").setValue("${ctx:PARAMETERS}").build());
RollingFileAppender.Builder builder =
RollingFileAppender.newBuilder();
builder.setName("auditJsonLogger");
builder.withFileName(logDir.resolve(LOG_JSON_FILENAME).toString());
builder.withFilePattern(logDir.resolve(LOG_JSON_FILEPATTERN).toString());
builder.withPolicy(SizeBasedTriggeringPolicy.createPolicy("10M"));
builder.setLayout(JsonLayout.newBuilder().setCompact(true).setEventEol(true).setConfiguration(new
DefaultConfiguration())
.setAdditionalFields(fields.toArray(new
KeyValuePair[0])).build());
builder.withStrategy(
DefaultRolloverStrategy.newBuilder().withCompressionLevelStr(String.valueOf(Deflater.DEFAULT_COMPRESSION))
.withMax(Integer.toString(LOG_MAX_INDEX)).withFileIndex("min").build());
return builder.build();
} {code}
We also tried to use %X\{...} as well as $${ctx:...} expansions instead to no
avail. The log file always contains the *literal* string we use in .setValue(),
i.e. lines like this:
{noformat}
{"instant":{"epochSecond":1642756242,"nanoOfSecond":271091900},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":65,"threadPriority":5,"who":"${ctx:WHO}","what":"${ctx:WHAT}","method":"${ctx:METHOD}","parameters":"${ctx:PARAMETERS}"}{noformat}
Reverting to 2.17.0 will correctly give lines like this in the JSON file:
{noformat}
{"instant":{"epochSecond":1642756430,"nanoOfSecond":923210700},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":62,"threadPriority":5,"who":"marku","what":"ObjectConsistencyCheckOperation","method":"-","parameters":"{dryRun=false,
roots=[io.bdeploy/demo/client-app/linux:1.0.0,
io.bdeploy/demo/client-app/linux:2.0.0,
io.bdeploy/demo/client-app/windows:1.0.0, ...]}"}{noformat}
was:
We're creating a RollingFileAppender programmatically using a JsonLayout. This
uses fields using ${ctx:...} expansion. This stopped working when upgrading
from 2.17.0 to 2.17.1.
The code is as follows:
{code:java}
/**
* Creates a rolling file appender that write audit entries to a
programmatically readable JSON file.
*/
private RollingFileAppender createJsonAppender(Path logDir) {
List fields = new ArrayList<>();
fields.add(KeyValuePair.newBuilder().setKey("who").setValue("${ctx:WHO}").build());
fields.add(KeyValuePair.newBuilder().setKey("what").setValue("${ctx:WHAT}").build());
fields.add(KeyValuePair.newBuilder().setKey("method").setValue("${ctx:METHOD}").build());
fields.add(KeyValuePair.newBuilder().setKey("parameters").setValue("${ctx:PARAMETERS}").build());
RollingFileAppender.Builder builder =
RollingFileAppender.newBuilder();
builder.setName("auditJsonLogger");
builder.withFileName(logDir.resolve(LOG_JSON_FILENAME).toString());
builder.withFilePattern(logDir.resolve(LOG_JSON_FILEPATTERN).toString());
builder.withPolicy(SizeBasedTriggeringPolicy.createPolicy("10M"));
builder.setLayout(JsonLayout.newBuilder().setCompact(true).setEventEol(true).setConfiguration(new
DefaultConfiguration())
.setAdditionalFields(fields.toArray(new
KeyValuePair[0])).build());
builder.withStrategy(
DefaultRolloverStrategy.newBuilder().withCompressionLevelStr(String.valueOf(Deflater.DEFAULT_COMPRESSION))
.withMax(Integer.toString(LOG_MAX_INDEX)).withFileIndex("min").build());
return builder.build();
} {code}
We also tried to use %X\{...} expansion instead to no avail. The log file
always contains the *literal* string we use in .setValue(), i.e. lines like
this:
{noformat}
{"instant":{"epochSecond":1642756242,"nanoOfSecond":271091900},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":65,"threadPriority":5,"who":"${ctx:WHO}","what":"${ctx
[GitHub] [logging-log4j2] vy merged pull request #725: Bump java-allocation-instrumenter from 3.0.1 to 3.3.0
vy merged pull request #725: URL: https://github.com/apache/logging-log4j2/pull/725 -- 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 #708: Log4j 1.2 bridge throws `ClassCastException` when using `SimpleLayout` and others
ppkarwasz commented on pull request #708: URL: https://github.com/apache/logging-log4j2/pull/708#issuecomment-1018420349 @garydgregory, I rebased the PR and added a failsafe to `BuilderManager#createBuilder`: if a builder does not implement any of the `*Builder` interfaces a warning is logged instead of a `ClassCastException`. -- 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
[CI][UNSTABLE] Logging/log4j/release-2.x#785 has test failures
BUILD UNSTABLE Build URL https://ci-builds.apache.org/job/Logging/job/log4j/job/release-2.x/785/ Project: release-2.x Date of build: Fri, 21 Jan 2022 10:41:59 + Build duration: 1 hr 29 min and counting JUnit Tests Name: (root) Failed: 0 test(s), Passed: 1420 test(s), Skipped: 0 test(s), Total: 1420 test(s)Name: liquibase.ext.logging.log4j2 Failed: 0 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 10 test(s)Name: org.apache.log4j Failed: 0 test(s), Passed: 188 test(s), Skipped: 0 test(s), Total: 188 test(s)Name: org.apache.log4j.bridge Failed: 0 test(s), Passed: 4 test(s), Skipped: 0 test(s), Total: 4 test(s)Name: org.apache.log4j.config Failed: 0 test(s), Passed: 106 test(s), Skipped: 0 test(s), Total: 106 test(s)Name: org.apache.log4j.layout Failed: 0 test(s), Passed: 4 test(s), Skipped: 0 test(s), Total: 4 test(s)Name: org.apache.log4j.pattern Failed: 0 test(s), Passed: 16 test(s), Skipped: 0 test(s), Total: 16 test(s)Name: org.apache.logging.log4j Failed: 0 test(s), Passed: 488 test(s), Skipped: 2 test(s), Total: 490 test(s)Name: org.apache.logging.log4j.cassandra Failed: 0 test(s), Passed: 2 test(s), Skipped: 0 test(s), Total: 2 test(s)Name: org.apache.logging.log4j.configuration Failed: 0 test(s), Passed: 2 test(s), Skipped: 0 test(s), Total: 2 test(s)Name: org.apache.logging.log4j.core Failed: 0 test(s), Passed: 196 test(s), Skipped: 2 test(s), Total: 198 test(s)Name: org.apache.logging.log4j.core.appender Failed: 0 test(s), Passed: 238 test(s), Skipped: 12 test(s), Total: 250 test(s)Name: org.apache.logging.log4j.core.appender.db Failed: 0 test(s), Passed: 26 test(s), Skipped: 0 test(s), Total: 26 test(s)Name: org.apache.logging.log4j.core.appender.db.jdbc Failed: 0 test(s), Passed: 80 test(s), Skipped: 0 test(s), Total: 80 test(s)Name: org.apache.logging.log4j.core.appender.db.jpa Failed: 0 test(s), Passed: 24 test(s), Skipped: 0 test(s), Total: 24 test(s)Name: org.apache.logging.log4j.core.appender.db.jpa.converter Failed: 0 test(s), Passed: 88 test(s), Skipped: 0 test(s), Total: 88 test(s)Name: org.apache.logging.log4j.core.appender.mom Failed: 0 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 8 test(s)Name: org.apache.logging.log4j.core.appender.mom.jeromq Failed: 0 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 8 test(s)Name: org.apache.logging.log4j.core.appender.mom.kafka Failed: 0 test(s), Passed: 16 test(s), Skipped: 0 test(s), Total: 16 test(s)Name: org.apache.logging.log4j.core.appender.nosql Failed: 0 test(s), Passed: 18 test(s), Skipped: 0 test(s), Total: 18 test(s)Name: org.apache.logging.log4j.core.appender.rewrite Failed: 0 test(s), Passed: 14 test(s), Skipped: 0 test(s), Total: 14 test(s)Name: org.apache.logging.log4j.core.appender.rolling Failed: 0 test(s), Passed: 205 test(s), Skipped: 2 test(s), Total: 207 test(s)Name: org.apache.logging.log4j.core.appender.rolling.action Failed: 0 test(s), Passed: 184 test(s), Skipped: 0 test(s), Total: 184 test(s)Name: org.apache.logging.log4j.core.appender.routing Failed: 0 test(s), Passed: 26 test(s), Skipped: 0 test(s), Total: 26 test(s)Name: org.apache.logging.log4j.core.async Failed: 0 test(s), Passed: 160 test(s), Skipped: 0 test(s), Total: 160 test(s)Name: org.apache.logging.log4j.core.config Failed: 0 test(s), Passed: 344 test(s), Skipped: 2 test(s), Total: 346 test(s)Name: org.apache.logging.log4j.core.config.arbiters Failed: 0 test(s), Passed: 12 test(s), Skipped: 0 test(s), Total: 12 test(s)Name: org.apache.logging.log4j.core.config.builder Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: org.apache.logging.log4j.core.config.plugins.convert Failed: 0 test(s), Passed: 12 test(s), Skipped: 0 test(s), Total: 12 test(s)Name: org.apache.logging.log4j.core.config.plugins.processor Failed: 0 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 10 test(s)Name: org.apache.logging.log4j.core.config.plugins.util Failed: 0 test(s), Passed: 52 test(s), Skipped: 0 test(s), Total: 52 test(s)Name: org.apache.logging.log4j.core.config.plugins.validation.validators Failed: 0 test(s), Passed: 30 test(s), Skipped: 0 test(s), Total: 30 test(s)Name: org.apache.logging.log4j.core.config.properties Failed: 0 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 8 test(s)Name: org.apache.logging.log4j.core.config.xml Failed: 0 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 10 test(s)Name: org.apache.logging.log4j.core.filter Failed: 0 test(s), Passed: 100 test(s), Skipped: 0 test(s), Total: 100 test(s)Name: org.apache.logging.log4j.core.impl Failed: 0 test(s), Passed: 302 test(s), Skipped: 0 test(s), Total: 302 test(s)Name: org.apache.logging.log4j.core.jackson Failed: 0 test(s), Passed: 22 test(s), Skipped: 0 test(s), Total: 22 test(s)Name: org.apache.logging.log4j.core.jmx Failed: 0 test(s), Passed: 20 test(s), Skipped: 0 test(s), Total: 20 test(s)Name: org.apache.logging.log4j.core.layout Failed: 0 test(s), Passed: 300 test(s), Skipped:
[jira] [Created] (LOG4J2-3359) Facility and priority add appended in Syslog message when Syslog log appender and pattern layout is used with log4j1-2 bridge API
Tukesh created LOG4J2-3359:
--
Summary: Facility and priority add appended 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: -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
Facility and priority add appended in Syslog message when Syslog log appender
and pattern layout is used with log4j1-2 bridge API
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (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
]
Tukesh updated LOG4J2-3359:
---
Summary: Facility and priority missing in Syslog message when Syslog log
appender and pattern layout is used with log4j1-2 bridge API (was: Facility
and priority add appended in Syslog message when Syslog log appender and
pattern layout is used with log4j1-2 bridge API)
> 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: -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
>Priority: Blocker
>
> Facility and priority add appended in Syslog message when Syslog log appender
> and pattern layout is used with log4j1-2 bridge API
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (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
]
Tukesh updated LOG4J2-3359:
---
Environment:
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
was:
-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
> 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: 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
>Priority: Blocker
> Attachments: bug_fac_pri.pcapng
>
>
> Facility and priority add appended in Syslog message when Syslog log appender
> and pattern layout is used with log4j1-2 bridge API
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (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
]
Tukesh updated LOG4J2-3359:
---
Attachment: bug_fac_pri.pcapng
> 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: 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
>Priority: Blocker
> Attachments: bug_fac_pri.pcapng
>
>
> Facility and priority add appended in Syslog message when Syslog log appender
> and pattern layout is used with log4j1-2 bridge API
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (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
]
Tukesh updated LOG4J2-3359:
---
Description: FACILITY and PRIORITY is not included when log4j bridge API
sends SysLog message. Please find the attached pcap files. (was: Facility and
priority add appended in Syslog message when Syslog log appender and pattern
layout is used with log4j1-2 bridge API)
> 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: 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
>Priority: Blocker
> Attachments: bug_fac_pri.pcapng
>
>
> 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&focusedCommentId=17480064#comment-17480064
]
Gary D. Gregory commented on LOG4J2-3359:
-
Hi [~TukeshK]
I recently fixed some issues in this area, please try a 2.17.2-SNAPSHOT build.
See
[https://repository.apache.org/content/groups/snapshots/org/apache/logging/log4j/]
Please report which version of Log4j you are using.
> 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: 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
>Priority: Blocker
> Attachments: bug_fac_pri.pcapng
>
>
> 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-3358) 2.17.1: JsonLayout Context no longer working.
[
https://issues.apache.org/jira/browse/LOG4J2-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480069#comment-17480069
]
Volkan Yazici commented on LOG4J2-3358:
---
For one, I strongly recommend you to use [JSON Template
Layout|https://logging.apache.org/log4j/2.x/manual/json-template-layout.html]
instead, which is the successor to JSON Layout. I would personally refrain from
lookups depending on the user-provided (i.e., {{LogEvent}}) data. Using {{mdc}}
resolver of JSON Template Layout, you can have your configuration as follows:
{code:java}
JsonTemplateLayout layout = JsonTemplateLayout
.newBuilder()
.setConfiguration(new DefaultConfiguration())
.setEventTemplateUri("classpath:JsonLayout.json")
.setStackTraceEnabled(true)
.setLocationInfoEnabled(true)
.setEventTemplateAdditionalFields(new EventTemplateAdditionalField[] {
EventTemplateAdditionalField
.newBuilder()
.setFormat(EventTemplateAdditionalField.Format.JSON)
.setKey("who")
.setValue("{'$resolver': 'mdc', 'key': 'WHO',
'stringified': true}".replaceAll("'", "\""))
.build(),
EventTemplateAdditionalField
.newBuilder()
.setFormat(EventTemplateAdditionalField.Format.JSON)
.setKey("what")
.setValue("{'$resolver': 'mdc', 'key': 'WHAT',
'stringified': true}".replaceAll("'", "\""))
.build(),
EventTemplateAdditionalField
.newBuilder()
.setFormat(EventTemplateAdditionalField.Format.JSON)
.setKey("method")
.setValue("{'$resolver': 'mdc', 'key': 'METHOD',
'stringified': true}".replaceAll("'", "\""))
.build(),
EventTemplateAdditionalField
.newBuilder()
.setFormat(EventTemplateAdditionalField.Format.JSON)
.setKey("parameters")
.setValue("{'$resolver': 'mdc', 'key': 'PARAMETERS',
'stringified': true}".replaceAll("'", "\""))
.build(),
})
.build();
{code}
That said, I can indeed reproduce the issue. The following test passes on
2.17.0 and fails on 2.17.1:
{code:java}
@Test
public void jsonLayout_should_substitute_lookups() {
// Create the layout.
KeyValuePair[] additionalFields = {
KeyValuePair
.newBuilder()
.setKey("who")
.setValue("${ctx:WHO}")
.build()
};
JsonLayout layout = JsonLayout
.newBuilder()
.setConfiguration(new DefaultConfiguration())
.setAdditionalFields(additionalFields)
.build();
// Create a log event containing `WHO` key in MDC.
StringMap contextData = ContextDataFactory.createContextData();
contextData.putValue("WHO", "mduft");
LogEvent logEvent = Log4jLogEvent
.newBuilder()
.setContextData(contextData)
.build();
// Verify the `WHO` key.
String serializedLogEvent = layout.toSerializable(logEvent);
assertThat(serializedLogEvent).contains("\"who\": \"mduft\"");
}
{code}
I will try to figure out what is going on.
> 2.17.1: JsonLayout Context no longer working.
> -
>
> Key: LOG4J2-3358
> URL: https://issues.apache.org/jira/browse/LOG4J2-3358
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.17.1
>Reporter: Markus Duft
>Priority: Major
>
> We're creating a RollingFileAppender programmatically using a JsonLayout.
> This uses fields using ${ctx:...} expansion. This stopped working when
> upgrading from 2.17.0 to 2.17.1.
> The code is as follows:
> {code:java}
> /**
> * Creates a rolling file appender that write audit entries to a
> programmatically readable JSON file.
> */
> private RollingFileAppender createJsonAppender(Path logDir) {
> List fields = new ArrayList<>();
>
> fields.add(KeyValuePair.newBuilder().setKey("who").setValue("${ctx:WHO}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("what").setValue("${ctx:WHAT}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("method").setValue("${ctx:METHOD}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("parameters").setValue("${ctx:PARAMETERS}").build());
>
> RollingFileAppender.Builder builder =
> RollingFileAppender.newBuilder();
> builder.setName("auditJsonLogger");
> builder.withFileName(logDir.
[GitHub] [logging-log4j2] garydgregory merged pull request #708: Log4j 1.2 bridge throws `ClassCastException` when using `SimpleLayout` and others
garydgregory merged pull request #708: URL: https://github.com/apache/logging-log4j2/pull/708 -- 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 #661: Bump spring-ws-core from 2.1.4.RELEASE to 3.1.2
garydgregory commented on pull request #661: URL: https://github.com/apache/logging-log4j2/pull/661#issuecomment-1018518371 Hi @rgoers, Merge or Close? -- 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-3358) 2.17.1: JsonLayout Context no longer working.
[
https://issues.apache.org/jira/browse/LOG4J2-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak reassigned LOG4J2-3358:
Assignee: Carter Kozak
> 2.17.1: JsonLayout Context no longer working.
> -
>
> Key: LOG4J2-3358
> URL: https://issues.apache.org/jira/browse/LOG4J2-3358
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.17.1
>Reporter: Markus Duft
>Assignee: Carter Kozak
>Priority: Major
>
> We're creating a RollingFileAppender programmatically using a JsonLayout.
> This uses fields using ${ctx:...} expansion. This stopped working when
> upgrading from 2.17.0 to 2.17.1.
> The code is as follows:
> {code:java}
> /**
> * Creates a rolling file appender that write audit entries to a
> programmatically readable JSON file.
> */
> private RollingFileAppender createJsonAppender(Path logDir) {
> List fields = new ArrayList<>();
>
> fields.add(KeyValuePair.newBuilder().setKey("who").setValue("${ctx:WHO}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("what").setValue("${ctx:WHAT}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("method").setValue("${ctx:METHOD}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("parameters").setValue("${ctx:PARAMETERS}").build());
>
> RollingFileAppender.Builder builder =
> RollingFileAppender.newBuilder();
> builder.setName("auditJsonLogger");
> builder.withFileName(logDir.resolve(LOG_JSON_FILENAME).toString());
>
> builder.withFilePattern(logDir.resolve(LOG_JSON_FILEPATTERN).toString());
> builder.withPolicy(SizeBasedTriggeringPolicy.createPolicy("10M"));
>
> builder.setLayout(JsonLayout.newBuilder().setCompact(true).setEventEol(true).setConfiguration(new
> DefaultConfiguration())
> .setAdditionalFields(fields.toArray(new
> KeyValuePair[0])).build());
> builder.withStrategy(
>
> DefaultRolloverStrategy.newBuilder().withCompressionLevelStr(String.valueOf(Deflater.DEFAULT_COMPRESSION))
>
> .withMax(Integer.toString(LOG_MAX_INDEX)).withFileIndex("min").build());
> return builder.build();
> } {code}
> We also tried to use %X\{...} as well as $${ctx:...} expansions instead to no
> avail. The log file always contains the *literal* string we use in
> .setValue(), i.e. lines like this:
> {noformat}
> {"instant":{"epochSecond":1642756242,"nanoOfSecond":271091900},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":65,"threadPriority":5,"who":"${ctx:WHO}","what":"${ctx:WHAT}","method":"${ctx:METHOD}","parameters":"${ctx:PARAMETERS}"}{noformat}
> Reverting to 2.17.0 will correctly give lines like this in the JSON file:
> {noformat}
> {"instant":{"epochSecond":1642756430,"nanoOfSecond":923210700},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":62,"threadPriority":5,"who":"marku","what":"ObjectConsistencyCheckOperation","method":"-","parameters":"{dryRun=false,
> roots=[io.bdeploy/demo/client-app/linux:1.0.0,
> io.bdeploy/demo/client-app/linux:2.0.0,
> io.bdeploy/demo/client-app/windows:1.0.0, ...]}"}{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] carterkozak opened a new pull request #726: LOG4J2-3358: Fix substitutions when the DefaultConfiguraiton is used
carterkozak opened a new pull request #726: URL: https://github.com/apache/logging-log4j2/pull/726 The problem is that some configuration creation paths fail to use the Interpolator constructor which loads all plugins. This produces inconsistent behavior based on the configuration construction path. -- 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
[CI][UNSTABLE] Logging/log4j/release-2.x#787 has test failures
BUILD UNSTABLE Build URL https://ci-builds.apache.org/job/Logging/job/log4j/job/release-2.x/787/ Project: release-2.x Date of build: Fri, 21 Jan 2022 13:28:36 + Build duration: 1 hr 10 min and counting JUnit Tests Name: (root) Failed: 0 test(s), Passed: 1420 test(s), Skipped: 0 test(s), Total: 1420 test(s)Name: liquibase.ext.logging.log4j2 Failed: 0 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 10 test(s)Name: org.apache.log4j Failed: 0 test(s), Passed: 188 test(s), Skipped: 0 test(s), Total: 188 test(s)Name: org.apache.log4j.bridge Failed: 0 test(s), Passed: 4 test(s), Skipped: 0 test(s), Total: 4 test(s)Name: org.apache.log4j.config Failed: 0 test(s), Passed: 130 test(s), Skipped: 0 test(s), Total: 130 test(s)Name: org.apache.log4j.layout Failed: 0 test(s), Passed: 4 test(s), Skipped: 0 test(s), Total: 4 test(s)Name: org.apache.log4j.pattern Failed: 0 test(s), Passed: 16 test(s), Skipped: 0 test(s), Total: 16 test(s)Name: org.apache.logging.log4j Failed: 0 test(s), Passed: 488 test(s), Skipped: 2 test(s), Total: 490 test(s)Name: org.apache.logging.log4j.cassandra Failed: 0 test(s), Passed: 2 test(s), Skipped: 0 test(s), Total: 2 test(s)Name: org.apache.logging.log4j.configuration Failed: 0 test(s), Passed: 2 test(s), Skipped: 0 test(s), Total: 2 test(s)Name: org.apache.logging.log4j.core Failed: 0 test(s), Passed: 196 test(s), Skipped: 2 test(s), Total: 198 test(s)Name: org.apache.logging.log4j.core.appender Failed: 0 test(s), Passed: 238 test(s), Skipped: 12 test(s), Total: 250 test(s)Name: org.apache.logging.log4j.core.appender.db Failed: 0 test(s), Passed: 26 test(s), Skipped: 0 test(s), Total: 26 test(s)Name: org.apache.logging.log4j.core.appender.db.jdbc Failed: 0 test(s), Passed: 80 test(s), Skipped: 0 test(s), Total: 80 test(s)Name: org.apache.logging.log4j.core.appender.db.jpa Failed: 0 test(s), Passed: 24 test(s), Skipped: 0 test(s), Total: 24 test(s)Name: org.apache.logging.log4j.core.appender.db.jpa.converter Failed: 0 test(s), Passed: 88 test(s), Skipped: 0 test(s), Total: 88 test(s)Name: org.apache.logging.log4j.core.appender.mom Failed: 0 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 8 test(s)Name: org.apache.logging.log4j.core.appender.mom.jeromq Failed: 0 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 8 test(s)Name: org.apache.logging.log4j.core.appender.mom.kafka Failed: 0 test(s), Passed: 16 test(s), Skipped: 0 test(s), Total: 16 test(s)Name: org.apache.logging.log4j.core.appender.nosql Failed: 0 test(s), Passed: 18 test(s), Skipped: 0 test(s), Total: 18 test(s)Name: org.apache.logging.log4j.core.appender.rewrite Failed: 0 test(s), Passed: 14 test(s), Skipped: 0 test(s), Total: 14 test(s)Name: org.apache.logging.log4j.core.appender.rolling Failed: 0 test(s), Passed: 205 test(s), Skipped: 2 test(s), Total: 207 test(s)Name: org.apache.logging.log4j.core.appender.rolling.action Failed: 0 test(s), Passed: 184 test(s), Skipped: 0 test(s), Total: 184 test(s)Name: org.apache.logging.log4j.core.appender.routing Failed: 0 test(s), Passed: 26 test(s), Skipped: 0 test(s), Total: 26 test(s)Name: org.apache.logging.log4j.core.async Failed: 0 test(s), Passed: 160 test(s), Skipped: 0 test(s), Total: 160 test(s)Name: org.apache.logging.log4j.core.config Failed: 0 test(s), Passed: 344 test(s), Skipped: 2 test(s), Total: 346 test(s)Name: org.apache.logging.log4j.core.config.arbiters Failed: 0 test(s), Passed: 12 test(s), Skipped: 0 test(s), Total: 12 test(s)Name: org.apache.logging.log4j.core.config.builder Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: org.apache.logging.log4j.core.config.plugins.convert Failed: 0 test(s), Passed: 12 test(s), Skipped: 0 test(s), Total: 12 test(s)Name: org.apache.logging.log4j.core.config.plugins.processor Failed: 0 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 10 test(s)Name: org.apache.logging.log4j.core.config.plugins.util Failed: 0 test(s), Passed: 52 test(s), Skipped: 0 test(s), Total: 52 test(s)Name: org.apache.logging.log4j.core.config.plugins.validation.validators Failed: 0 test(s), Passed: 30 test(s), Skipped: 0 test(s), Total: 30 test(s)Name: org.apache.logging.log4j.core.config.properties Failed: 0 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 8 test(s)Name: org.apache.logging.log4j.core.config.xml Failed: 0 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 10 test(s)Name: org.apache.logging.log4j.core.filter Failed: 0 test(s), Passed: 100 test(s), Skipped: 0 test(s), Total: 100 test(s)Name: org.apache.logging.log4j.core.impl Failed: 0 test(s), Passed: 302 test(s), Skipped: 0 test(s), Total: 302 test(s)Name: org.apache.logging.log4j.core.jackson Failed: 0 test(s), Passed: 22 test(s), Skipped: 0 test(s), Total: 22 test(s)Name: org.apache.logging.log4j.core.jmx Failed: 0 test(s), Passed: 20 test(s), Skipped: 0 test(s), Total: 20 test(s)Name: org.apache.logging.log4j.core.layout Failed: 0 test(s), Passed: 300 test(s), Skipped:
[GitHub] [logging-log4j2] vy commented on a change in pull request #726: LOG4J2-3358: Fix substitutions when the DefaultConfiguraiton is used
vy commented on a change in pull request #726:
URL: https://github.com/apache/logging-log4j2/pull/726#discussion_r789717797
##
File path:
log4j-core/src/test/java/org/apache/logging/log4j/core/layout/JsonLayoutTest.java
##
@@ -604,6 +608,37 @@ public void testEmptyValuesAreIgnored() {
assertFalse(str, str.contains("\"empty\""));
}
+@Test // LOG4J2-3358
+public void jsonLayout_should_substitute_lookups() {
Review comment:
```suggestion
/**
* @see https://issues.apache.org/jira/browse/LOG4J2-3358";>LOG4J2-3358
*/
@Test
public void ctx_lookup_should_work() {
```
--
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] avandeursen commented on pull request #721: Expand test suite for DateLookup
avandeursen commented on pull request #721: URL: https://github.com/apache/logging-log4j2/pull/721#issuecomment-1018587402 Thanks! Based on the feedback I made a few changes. For the test with the known format, I indeed added the test whether the returned date is today (and even added a test for tomorrow, in case the test is executed at midnight). For the test cases falling back on the default format, most likely the time is included in that format, making this route a bit too flaky to my taste. So I decided to better document the rationale of the test instead. While engaging with the DateLookup class, I also made some of the javadocs more accurate. Let me know what you think! -- 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 pull request #726: LOG4J2-3358: Fix substitutions when the DefaultConfiguraiton is used
carterkozak commented on pull request #726: URL: https://github.com/apache/logging-log4j2/pull/726#issuecomment-1018588038 TODO: More description and context, I'll try to write something up by the end of the day -- 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] avandeursen commented on a change in pull request #721: Expand test suite for DateLookup
avandeursen commented on a change in pull request #721:
URL: https://github.com/apache/logging-log4j2/pull/721#discussion_r789731643
##
File path:
log4j-core/src/test/java/org/apache/logging/log4j/core/lookup/DateLookupTest.java
##
@@ -23,31 +23,42 @@
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.when;
public class DateLookupTest {
-
@Test
-public void testLookup() {
-final StrLookup lookup = new DateLookup();
-final LogEvent event = new MyLogEvent();
-final String value = lookup.lookup(event, "MM/dd/");
-assertNotNull(value);
-assertEquals("12/30/2011", value);
+public void testDateLookupInEvent() {
+final LogEvent mockedEvent = mock(LogEvent.class);
+final Calendar cal = Calendar.getInstance();
+cal.set(2011, Calendar.DECEMBER, 30, 10, 56, 35);
+when(mockedEvent.getTimeMillis()).thenReturn(cal.getTimeInMillis());
+
+final String actualDate = new DateLookup().lookup(mockedEvent,
"MM/dd/");
+assertEquals("12/30/2011", actualDate);
}
-private static class MyLogEvent extends AbstractLogEvent {
-/**
- * Generated serial version ID.
- */
-private static final long serialVersionUID = -2663819677970643109L;
+@Test
+public void testDateLookUpNoEvent() {
+final String dateFormat = "MM/dd/";
+final String actualDate = new DateLookup().lookup(null, dateFormat);
+// we don't know current time, so check length of format instead.
+assertEquals(actualDate.length(), dateFormat.length());
+}
-@Override
-public long getTimeMillis() {
-final Calendar cal = Calendar.getInstance();
-cal.set(2011, Calendar.DECEMBER, 30, 10, 56, 35);
-return cal.getTimeInMillis();
-}
+@Test
+public void testNullDateLookupYieldsCurrentTime() {
+final String currentTime = new DateLookup().lookup(null, null);
+assertNotNull(currentTime);
+// we don't know current time nor format, so just check length of date
string.
Review comment:
This would typically be at the time level of minutes -- with quite a
chance of becoming flaky. So instead I better documented the rationale.
##
File path:
log4j-core/src/test/java/org/apache/logging/log4j/core/lookup/DateLookupTest.java
##
@@ -23,31 +23,42 @@
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.when;
public class DateLookupTest {
-
@Test
-public void testLookup() {
-final StrLookup lookup = new DateLookup();
-final LogEvent event = new MyLogEvent();
-final String value = lookup.lookup(event, "MM/dd/");
-assertNotNull(value);
-assertEquals("12/30/2011", value);
+public void testDateLookupInEvent() {
+final LogEvent mockedEvent = mock(LogEvent.class);
+final Calendar cal = Calendar.getInstance();
+cal.set(2011, Calendar.DECEMBER, 30, 10, 56, 35);
+when(mockedEvent.getTimeMillis()).thenReturn(cal.getTimeInMillis());
+
+final String actualDate = new DateLookup().lookup(mockedEvent,
"MM/dd/");
+assertEquals("12/30/2011", actualDate);
}
-private static class MyLogEvent extends AbstractLogEvent {
-/**
- * Generated serial version ID.
- */
-private static final long serialVersionUID = -2663819677970643109L;
+@Test
+public void testDateLookUpNoEvent() {
+final String dateFormat = "MM/dd/";
+final String actualDate = new DateLookup().lookup(null, dateFormat);
+// we don't know current time, so check length of format instead.
+assertEquals(actualDate.length(), dateFormat.length());
+}
-@Override
-public long getTimeMillis() {
-final Calendar cal = Calendar.getInstance();
-cal.set(2011, Calendar.DECEMBER, 30, 10, 56, 35);
-return cal.getTimeInMillis();
-}
+@Test
+public void testNullDateLookupYieldsCurrentTime() {
+final String currentTime = new DateLookup().lookup(null, null);
+assertNotNull(currentTime);
+// we don't know current time nor format, so just check length of date
string.
+assertTrue(currentTime.length() > 0);
+}
+@Test
+public void testInvalidFormatYieldsDefaultFormat() {
+final String currentTime = new DateLookup().lookup(null, "bananas");
+// we don't know current time nor format, so just check length of date
string.
Review comment:
See above.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to
[jira] [Commented] (LOG4J2-3356) The sub module log4j-layout-template-json seems not properly configured to be deployed as a fragment host in OSGI
[
https://issues.apache.org/jira/browse/LOG4J2-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480123#comment-17480123
]
Volkan Yazici commented on LOG4J2-3356:
---
[~ruffp], I have passed your question to other maintainers and got the
impression that we currently don't posses the sufficient experience, knowledge,
and/or spare-time-to-work on OSGi. I suggest you to look for an answer in
Felix, Karaf, Pax Logging, etc. support channels. If you happen to find one and
it points out that something needs to be fixed in Log4j, you are more than
welcome to submit a PR.
> The sub module log4j-layout-template-json seems not properly configured to be
> deployed as a fragment host in OSGI
> -
>
> Key: LOG4J2-3356
> URL: https://issues.apache.org/jira/browse/LOG4J2-3356
> Project: Log4j 2
> Issue Type: Bug
> Components: JsonTemplateLayout
>Affects Versions: 2.17.1
> Environment: Tested on ServiceMix (under Docker) 7.0.1, but it should
> be the same in Karaf 4.x
> I also tried to add the original log4j2-api and log4j-core in the same config
> but the fragment never gets resolved.
>Reporter: ruffp
>Priority: Major
>
> In the
> [pom|https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-layout-template-json/pom.xml]
> of the module we have:
> {code:xml}
>
> org.apache.felix
> maven-bundle-plugin
>
>
>
> org.apache.logging.log4j.layout.template.json
> *
>
>
>
> {code}
> The Fragment host seems to refer to itself.
> When I tried to deploy this jar as a bundle with this in my
> startup.properties file:
> {noformat}
> mvn\:org.apache.logging.log4j/log4j-layout-template-json/2.17.1 = 5
> mvn\:org.ops4j.pax.logging/pax-logging-log4j2-extra/1.11.13 = 6
> mvn\:org.ops4j.pax.logging/pax-logging-api/1.11.13 = 8
> mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.11.13 = 8
> {noformat}
> And copying the lib in the "system" folder of karaf (I tried with ServiceMix
> 7.0.1).
> The bundle stays in status "Installed" and never resolves as the
> Fragment-Host refers to itself.
> I am not sure what values should be set in this as I am using Pax Logging,
> but for sure the Host does not seems correct to me (otherwise I would have
> created a PR).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] carterkozak commented on a change in pull request #726: LOG4J2-3358: Fix substitutions when the DefaultConfiguraiton is used
carterkozak commented on a change in pull request #726:
URL: https://github.com/apache/logging-log4j2/pull/726#discussion_r789743264
##
File path:
log4j-core/src/test/java/org/apache/logging/log4j/core/layout/JsonLayoutTest.java
##
@@ -604,6 +608,37 @@ public void testEmptyValuesAreIgnored() {
assertFalse(str, str.contains("\"empty\""));
}
+@Test // LOG4J2-3358
+public void jsonLayout_should_substitute_lookups() {
Review comment:
Structure borrowed from the test above:
https://github.com/apache/logging-log4j2/blob/e7af4e0a1ead739598a5ca96d09bc214b68cf0ec/log4j-core/src/test/java/org/apache/logging/log4j/core/layout/JsonLayoutTest.java#L598-L599
Happy to change both
--
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-3360) Document unsafe lookup usage patterns
Volkan Yazici created LOG4J2-3360:
-
Summary: Document unsafe lookup usage patterns
Key: LOG4J2-3360
URL: https://issues.apache.org/jira/browse/LOG4J2-3360
Project: Log4j 2
Issue Type: Improvement
Reporter: Volkan Yazici
Fix For: 2.17.2
The recent CVE storm has proven that lookups are employed by users in many
places where they shouldn't. In particular, lookups depending on {{LogEvent}}'s
(e.g., {{ctx}}) are honey pots for attackers and there are safer ways to expose
the very same information via more native constructs, e.g., MDC accessors in
{{PatternLayout}} and {{JsonTemplateLayout}}. This story aims to enrich the
lookup and certain layout documentations with such best practices.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3298) Update JSONTemplateFormat to support not escaping certain payloads
[
https://issues.apache.org/jira/browse/LOG4J2-3298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480133#comment-17480133
]
Volkan Yazici commented on LOG4J2-3298:
---
[~mattrpav], any updates?
> Update JSONTemplateFormat to support not escaping certain payloads
> --
>
> Key: LOG4J2-3298
> URL: https://issues.apache.org/jira/browse/LOG4J2-3298
> Project: Log4j 2
> Issue Type: Improvement
> Components: JsonTemplateLayout
>Reporter: Matt Pavlovich
>Assignee: Volkan Yazici
>Priority: Minor
>
> Currently, if a user's object is able to generate well-formed JSON string, it
> will be escaped. It would be great if there was a way to config the
> JsonTemplateLayout to _not escape_ certain payloads. This allows the json to
> be fully formed and contain model object data that can be parsed out later
> without any un-formatting.
> Example log entry:
> {noformat}
> {"@timestamp":"2022-01-07T19:14:01.060Z","log.level":"INFO","message":"{
> \"Order\" { \"id\": \"3977\", \"customerName\": \"Customer-8625\",
> \"createdDate\": \"2022-01-07T09:51:01.056580-06:00\"}
> }","process.thread.name":"main","log.logger":"io.foo.log.ProcessService"}
> {noformat}
> Desired output:
> {noformat}
> {"@timestamp":"2022-01-07T19:14:01.060Z","log.level":"INFO","message":{
> "Order" { "id": "3977", "customerName": "Customer-8625", "createdDate":
> "2022-01-07T09:51:01.056580-06:00"}
> },"process.thread.name":"main","log.logger":"io.foo.log.ProcessService"}
> {noformat}
> Proposed requirements:
> 1. Users would have to pre-escape their JSON string in order to not break
> overall log json format
> Implementation approach options:
> 1. Update JSONTemplate configuration to allow a rawJSON, similar to
> 'stringified'
> 2. Data is written down as a JSON object "message": { }
> 3. User should invoke using an ObjectMessage (or perhaps a
> JSONFormatMessage?): logger.info(new ObjectMessage(objectInstance))
> {noformat}
> "message": {
> "$resolver": "message",
> "rawJSON": true
> },
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] vy commented on pull request #661: Bump spring-ws-core from 2.1.4.RELEASE to 3.1.2
vy commented on pull request #661: URL: https://github.com/apache/logging-log4j2/pull/661#issuecomment-1018607212 I am in favor of merging this, checks are green. -- 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 #721: Expand test suite for DateLookup
vy merged pull request #721: URL: https://github.com/apache/logging-log4j2/pull/721 -- 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-3357) CronExpression.getTimeBefore() calculates incorrect result
[
https://issues.apache.org/jira/browse/LOG4J2-3357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers reassigned LOG4J2-3357:
---
Assignee: Ralph Goers
> CronExpression.getTimeBefore() calculates incorrect result
> --
>
> Key: LOG4J2-3357
> URL: https://issues.apache.org/jira/browse/LOG4J2-3357
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.1
>Reporter: Petr Valenta
>Assignee: Ralph Goers
>Priority: Critical
>
> The method getTimeBefore(targetDate) of
> org.apache.logging.log4j.core.util.CronExpression incorrectly returns the
> prevFireTime value sometimes or is called with bad inputs.
> When CronTiggeringPolicy calls this method the targetDate object contains a
> current time.
> For example, if we have a situation where we want to perform a midnight
> rollup, the method works differently if the entry time is ... 00:00:00 or ...
> 00:00:01. This can happen if we have many different logs, all of which we
> want to roll at the same time (typically midnight). But all "getTimeBefore"
> won't make it within 1 second. If the targetDate differs at least one second
> it causes the different comparison result at line:
> {code:java}
> ... while (prevFireTime.compareTo(targetDateNoMs) >= 0);{code}
>
> Configuration example:
> {code:java}
> ...
>
> logs/l4j2_
> logs/bck/l4j2_
> log.bz2
> MMdd
> %d %-5p [%t] - %m%n
> HOSTNAME
> ENVIRONMENT
>
> ...
> fileName="${filePath}uni-javascript.log"
> filePattern="${fileBackupPath}uni-javascript-%d{${fileDatePattern}}_%i.${fileSuffix}">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
>
> Adding some extra debugging, we can see the behaviour:
> 1. targetDate in first second (1/20/22 0:00:00):
> {code:java}
> [1/20/22 0:00:00:018 CET] 0186 SystemOut O 2022-01-20 00:00:00,018
> Log4j2-TF-3-Scheduled-2 DEBUG PV: CronExpression | getTimeBefore - entering
> 2022-01-20T00:00:00.018+0100
> [1/20/22 0:00:00:469 CET] 0186 SystemOut O 2022-01-20 00:00:00,469
> Log4j2-TF-3-Scheduled-2 DEBUG PV: CronExpression | getTimeBefore - result
> 2022-01-19T00:00:05.000+0100
> [1/20/22 0:00:00:469 CET] 0186 SystemOut O 2022-01-20 00:00:00,469
> Log4j2-TF-3-Scheduled-2 DEBUG PV: RollingFileManager | rollover entered
> [1/20/22 0:00:00:469 CET] 0186 SystemOut O 2022-01-20 00:00:00,469
> Log4j2-TF-3-Scheduled-2 DEBUG Setting prev file time to
> 2022-01-19T00:00:05.000+0100
> [1/20/22 0:00:00:470 CET] 0186 SystemOut O 2022-01-20 00:00:00,470
> Log4j2-TF-3-Scheduled-2 DEBUG Formatting file name. useCurrentTime=false.
> currentFileTime=1642546805000, prevFileTime=1642546805000
> [1/20/22 0:00:00:470 CET] 0186 SystemOut O 2022-01-20 00:00:00,470
> Log4j2-TF-3-Scheduled-2 DEBUG Current file: logs/l4j2_ccm-javascript.log
> ...{code}
> 2. same cron with targetDate in second second (1/20/22 0:00:01):
> {code:java}
> [1/20/22 0:00:01:365 CET] 018d SystemOut O 2022-01-20 00:00:01,365
> Log4j2-TF-3-Scheduled-9 DEBUG PV: CronExpression | getTimeBefore - entering
> 2022-01-20T00:00:01.365+0100
> [1/20/22 0:00:01:365 CET] 018d SystemOut O 2022-01-20 00:00:01,365
> Log4j2-TF-3-Scheduled-9 DEBUG PV: CronExpression | getTimeBefore - result
> 2022-01-20T00:00:00.000+0100
> [1/20/22 0:00:01:365 CET] 018d SystemOut O 2022-01-20 00:00:01,365
> Log4j2-TF-3-Scheduled-9 DEBUG PV: RollingFileManager | rollover entered
> [1/20/22 0:00:01:366 CET] 018d SystemOut O 2022-01-20 00:00:01,366
> Log4j2-TF-3-Scheduled-9 DEBUG Setting prev file time to
> 2022-01-20T00:00:00.000+0100
> [1/20/22 0:00:01:366 CET] 018d SystemOut O 2022-01-20 00:00:01,366
> Log4j2-TF-3-Scheduled-9 DEBUG Formatting file name. useCurrentTime=false.
> currentFileTime=1642546805000, prevFileTime=164263320
> [1/20/22 0:00:01:366 CET] 018d SystemOut O 2022-01-20 00:00:01,366
> Log4j2-TF-3-Scheduled-9 DEBUG Current file: logs/l4j2_uni-perf.log
> ...{code}
>
> You can see the difference in value prevFireTime. This issue may be related
> to LOG4J2-2575.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] vy commented on pull request #721: Expand test suite for DateLookup
vy commented on pull request #721: URL: https://github.com/apache/logging-log4j2/pull/721#issuecomment-1018630640 @avandeursen, I think the tests could be improved in many angles, but yours is certainly an improvement anyway and I have neither time, nor interest to invest on this further. As a tip for your next PR, I'd appreciate `@link` and `@code` expressions in javadocs rather than literals. All in all, good job, thanks so much! :+1: Keep it up! :100: -- 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-3356) The sub module log4j-layout-template-json seems not properly configured to be deployed as a fragment host in OSGI
[
https://issues.apache.org/jira/browse/LOG4J2-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480149#comment-17480149
]
Ralph Goers commented on LOG4J2-3356:
-
[~vy] What he posts above does indeed look wrong. I took a look at the Flume
module and it has
{code:java}
org.apache.logging.log4j.core
org.apache.logging.log4j.flume
org.apache.logging.log4j.flume.appender
{code}
I suspect that Json Template Layout should be using that same Fragment-Host,
the bundle name should match the actual component, and export package should
specify what you actually want public instead of everything.
> The sub module log4j-layout-template-json seems not properly configured to be
> deployed as a fragment host in OSGI
> -
>
> Key: LOG4J2-3356
> URL: https://issues.apache.org/jira/browse/LOG4J2-3356
> Project: Log4j 2
> Issue Type: Bug
> Components: JsonTemplateLayout
>Affects Versions: 2.17.1
> Environment: Tested on ServiceMix (under Docker) 7.0.1, but it should
> be the same in Karaf 4.x
> I also tried to add the original log4j2-api and log4j-core in the same config
> but the fragment never gets resolved.
>Reporter: ruffp
>Priority: Major
>
> In the
> [pom|https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-layout-template-json/pom.xml]
> of the module we have:
> {code:xml}
>
> org.apache.felix
> maven-bundle-plugin
>
>
>
> org.apache.logging.log4j.layout.template.json
> *
>
>
>
> {code}
> The Fragment host seems to refer to itself.
> When I tried to deploy this jar as a bundle with this in my
> startup.properties file:
> {noformat}
> mvn\:org.apache.logging.log4j/log4j-layout-template-json/2.17.1 = 5
> mvn\:org.ops4j.pax.logging/pax-logging-log4j2-extra/1.11.13 = 6
> mvn\:org.ops4j.pax.logging/pax-logging-api/1.11.13 = 8
> mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.11.13 = 8
> {noformat}
> And copying the lib in the "system" folder of karaf (I tried with ServiceMix
> 7.0.1).
> The bundle stays in status "Installed" and never resolves as the
> Fragment-Host refers to itself.
> I am not sure what values should be set in this as I am using Pax Logging,
> but for sure the Host does not seems correct to me (otherwise I would have
> created a PR).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3356) The sub module log4j-layout-template-json seems not properly configured to be deployed as a fragment host in OSGI
[
https://issues.apache.org/jira/browse/LOG4J2-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480153#comment-17480153
]
ASF subversion and git services commented on LOG4J2-3356:
-
Commit 1ad6dac24b697574831090423d8a0fdc95a8d95f in logging-log4j2's branch
refs/heads/release-2.x from Volkan Yazici
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=1ad6dac ]
LOG4J2-3356 Fix maven-bundle-plugin configuration of JSON Template Layout.
> The sub module log4j-layout-template-json seems not properly configured to be
> deployed as a fragment host in OSGI
> -
>
> Key: LOG4J2-3356
> URL: https://issues.apache.org/jira/browse/LOG4J2-3356
> Project: Log4j 2
> Issue Type: Bug
> Components: JsonTemplateLayout
>Affects Versions: 2.17.1
> Environment: Tested on ServiceMix (under Docker) 7.0.1, but it should
> be the same in Karaf 4.x
> I also tried to add the original log4j2-api and log4j-core in the same config
> but the fragment never gets resolved.
>Reporter: ruffp
>Priority: Major
>
> In the
> [pom|https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-layout-template-json/pom.xml]
> of the module we have:
> {code:xml}
>
> org.apache.felix
> maven-bundle-plugin
>
>
>
> org.apache.logging.log4j.layout.template.json
> *
>
>
>
> {code}
> The Fragment host seems to refer to itself.
> When I tried to deploy this jar as a bundle with this in my
> startup.properties file:
> {noformat}
> mvn\:org.apache.logging.log4j/log4j-layout-template-json/2.17.1 = 5
> mvn\:org.ops4j.pax.logging/pax-logging-log4j2-extra/1.11.13 = 6
> mvn\:org.ops4j.pax.logging/pax-logging-api/1.11.13 = 8
> mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.11.13 = 8
> {noformat}
> And copying the lib in the "system" folder of karaf (I tried with ServiceMix
> 7.0.1).
> The bundle stays in status "Installed" and never resolves as the
> Fragment-Host refers to itself.
> I am not sure what values should be set in this as I am using Pax Logging,
> but for sure the Host does not seems correct to me (otherwise I would have
> created a PR).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3356) The sub module log4j-layout-template-json seems not properly configured to be deployed as a fragment host in OSGI
[
https://issues.apache.org/jira/browse/LOG4J2-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480156#comment-17480156
]
Volkan Yazici commented on LOG4J2-3356:
---
[~ruffp], committed a change to the {{release-2.x}} branch as [~rgoers] hinted.
Mind testing the most recent 2.17.2-SNAPSHOT and check if it works for you?
(Apache Maven repository for SNAPSHOT versions is accessible at
[https://repository.apache.org/snapshots/].)
> The sub module log4j-layout-template-json seems not properly configured to be
> deployed as a fragment host in OSGI
> -
>
> Key: LOG4J2-3356
> URL: https://issues.apache.org/jira/browse/LOG4J2-3356
> Project: Log4j 2
> Issue Type: Bug
> Components: JsonTemplateLayout
>Affects Versions: 2.17.1
> Environment: Tested on ServiceMix (under Docker) 7.0.1, but it should
> be the same in Karaf 4.x
> I also tried to add the original log4j2-api and log4j-core in the same config
> but the fragment never gets resolved.
>Reporter: ruffp
>Priority: Major
>
> In the
> [pom|https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-layout-template-json/pom.xml]
> of the module we have:
> {code:xml}
>
> org.apache.felix
> maven-bundle-plugin
>
>
>
> org.apache.logging.log4j.layout.template.json
> *
>
>
>
> {code}
> The Fragment host seems to refer to itself.
> When I tried to deploy this jar as a bundle with this in my
> startup.properties file:
> {noformat}
> mvn\:org.apache.logging.log4j/log4j-layout-template-json/2.17.1 = 5
> mvn\:org.ops4j.pax.logging/pax-logging-log4j2-extra/1.11.13 = 6
> mvn\:org.ops4j.pax.logging/pax-logging-api/1.11.13 = 8
> mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.11.13 = 8
> {noformat}
> And copying the lib in the "system" folder of karaf (I tried with ServiceMix
> 7.0.1).
> The bundle stays in status "Installed" and never resolves as the
> Fragment-Host refers to itself.
> I am not sure what values should be set in this as I am using Pax Logging,
> but for sure the Host does not seems correct to me (otherwise I would have
> created a PR).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work started] (LOG4J2-3356) The sub module log4j-layout-template-json seems not properly configured to be deployed as a fragment host in OSGI
[
https://issues.apache.org/jira/browse/LOG4J2-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on LOG4J2-3356 started by Volkan Yazici.
-
> The sub module log4j-layout-template-json seems not properly configured to be
> deployed as a fragment host in OSGI
> -
>
> Key: LOG4J2-3356
> URL: https://issues.apache.org/jira/browse/LOG4J2-3356
> Project: Log4j 2
> Issue Type: Bug
> Components: JsonTemplateLayout
>Affects Versions: 2.17.1
> Environment: Tested on ServiceMix (under Docker) 7.0.1, but it should
> be the same in Karaf 4.x
> I also tried to add the original log4j2-api and log4j-core in the same config
> but the fragment never gets resolved.
>Reporter: ruffp
>Assignee: Volkan Yazici
>Priority: Major
>
> In the
> [pom|https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-layout-template-json/pom.xml]
> of the module we have:
> {code:xml}
>
> org.apache.felix
> maven-bundle-plugin
>
>
>
> org.apache.logging.log4j.layout.template.json
> *
>
>
>
> {code}
> The Fragment host seems to refer to itself.
> When I tried to deploy this jar as a bundle with this in my
> startup.properties file:
> {noformat}
> mvn\:org.apache.logging.log4j/log4j-layout-template-json/2.17.1 = 5
> mvn\:org.ops4j.pax.logging/pax-logging-log4j2-extra/1.11.13 = 6
> mvn\:org.ops4j.pax.logging/pax-logging-api/1.11.13 = 8
> mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.11.13 = 8
> {noformat}
> And copying the lib in the "system" folder of karaf (I tried with ServiceMix
> 7.0.1).
> The bundle stays in status "Installed" and never resolves as the
> Fragment-Host refers to itself.
> I am not sure what values should be set in this as I am using Pax Logging,
> but for sure the Host does not seems correct to me (otherwise I would have
> created a PR).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3356) The sub module log4j-layout-template-json seems not properly configured to be deployed as a fragment host in OSGI
[
https://issues.apache.org/jira/browse/LOG4J2-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volkan Yazici reassigned LOG4J2-3356:
-
Assignee: Volkan Yazici
> The sub module log4j-layout-template-json seems not properly configured to be
> deployed as a fragment host in OSGI
> -
>
> Key: LOG4J2-3356
> URL: https://issues.apache.org/jira/browse/LOG4J2-3356
> Project: Log4j 2
> Issue Type: Bug
> Components: JsonTemplateLayout
>Affects Versions: 2.17.1
> Environment: Tested on ServiceMix (under Docker) 7.0.1, but it should
> be the same in Karaf 4.x
> I also tried to add the original log4j2-api and log4j-core in the same config
> but the fragment never gets resolved.
>Reporter: ruffp
>Assignee: Volkan Yazici
>Priority: Major
>
> In the
> [pom|https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-layout-template-json/pom.xml]
> of the module we have:
> {code:xml}
>
> org.apache.felix
> maven-bundle-plugin
>
>
>
> org.apache.logging.log4j.layout.template.json
> *
>
>
>
> {code}
> The Fragment host seems to refer to itself.
> When I tried to deploy this jar as a bundle with this in my
> startup.properties file:
> {noformat}
> mvn\:org.apache.logging.log4j/log4j-layout-template-json/2.17.1 = 5
> mvn\:org.ops4j.pax.logging/pax-logging-log4j2-extra/1.11.13 = 6
> mvn\:org.ops4j.pax.logging/pax-logging-api/1.11.13 = 8
> mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.11.13 = 8
> {noformat}
> And copying the lib in the "system" folder of karaf (I tried with ServiceMix
> 7.0.1).
> The bundle stays in status "Installed" and never resolves as the
> Fragment-Host refers to itself.
> I am not sure what values should be set in this as I am using Pax Logging,
> but for sure the Host does not seems correct to me (otherwise I would have
> created a PR).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4NET-683) UdpAppender is no longer supported for .Net Framework!?
[
https://issues.apache.org/jira/browse/LOG4NET-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480184#comment-17480184
]
Manuel Spezzani commented on LOG4NET-683:
-
I'm experiencing exactly the same issue. By looking at log4net internal logs I
see this:
{code:java}
log4net:ERROR [UdpAppender] ErrorCode: WriteFailure. Unable to send logging
event to remote host on port .
log4net:ERROR [UdpAppender] ErrorCode: WriteFailure. Unable to send logging
event to remote host on port .
System.ArgumentException: Cannot set the namespace if Namespaces is 'false'.
at System.Xml.XmlTextWriter.WriteStartElement(String prefix, String
localName, String ns)
at log4net.Layout.XmlLayoutSchemaLog4j.FormatXml(XmlWriter writer,
LoggingEvent loggingEvent)
at log4net.Layout.XmlLayoutBase.Format(TextWriter writer, LoggingEvent
loggingEvent)
at log4net.Appender.AppenderSkeleton.RenderLoggingEvent(LoggingEvent
loggingEvent)
at log4net.Appender.UdpAppender.Append(LoggingEvent loggingEvent)
System.ArgumentException: Cannot set the namespace if Namespaces is 'false'.
at System.Xml.XmlTextWriter.WriteStartElement(String prefix, String
localName, String ns)
at log4net.Layout.XmlLayoutSchemaLog4j.FormatXml(XmlWriter writer,
LoggingEvent loggingEvent)
at log4net.Layout.XmlLayoutBase.Format(TextWriter writer, LoggingEvent
loggingEvent)
at log4net.Appender.AppenderSkeleton.RenderLoggingEvent(LoggingEvent
loggingEvent)
at log4net.Appender.UdpAppender.Append(LoggingEvent loggingEvent) {code}
Hope it helps.
M
> UdpAppender is no longer supported for .Net Framework!?
> ---
>
> Key: LOG4NET-683
> URL: https://issues.apache.org/jira/browse/LOG4NET-683
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.0.14
> Environment: Windows10, .NET Framework 4.72,
>Reporter: Stojan Andjelkovic
>Priority: Major
>
> Follow configuration works (log messages are sent) only for .NET Core but
> not for .NET Framework anymore:
>
> {{{}<{}}}{{{}appender{}}} {{{}name{}}}{{{}={}}}{{{}"UdpAppender"{}}}
> {{{}type{}}}{{{}={}}}{{{}"log4net.Appender.UdpAppender"{}}}{{{}>{}}}
> {{{} <{}}}{{{}param{}}} {{{}name{}}}{{{}={}}}{{{}"RemoteAddress"{}}}
> {{{}value{}}}{{{}={}}}{{{}"127.0.0.1"{}}} {{/>}}
> {{{} <{}}}{{{}param{}}} {{{}name{}}}{{{}={}}}{{{}"RemotePort"{}}}
> {{{}value{}}}{{{}={}}}{{{}"4445"{}}} {{/>}}
> {{{} <{}}}{{{}layout{}}}
> {{{}type{}}}{{{}={}}}{{{}"log4net.Layout.XmlLayoutSchemaLog4j,
> log4net"{}}}{{{}>{}}}
> {{{} <{}}}{{{}param{}}} {{{}name{}}}{{{}={}}}{{{}"LocationInfo"{}}}
> {{{}value{}}}{{{}={}}}{{{}"true"{}}} {{/>}}
> {{{} {}}}
> {{{} <{}}}{{{}param{}}} {{{}name{}}}{{{}={}}}{{{}"Encoding"{}}}
> {{{}value{}}}{{{}={}}}{{{}"utf-8"{}}} {{/>}}
> {{{}{}}}
> The problem exists since version 2.0.13
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] atulpendse commented on pull request #683: LOG4J2-3280 - Add support for microsecond precision in RFC5424Layout
atulpendse commented on pull request #683: URL: https://github.com/apache/logging-log4j2/pull/683#issuecomment-1018735056 Looks like a test is failing on MacOS. Failure doesn't look related to my changes though. I don't have access to Mac to find out why exactly it's failing. -- 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 #711: Use Log4j1XmlLayout instead of XmlLayout
ppkarwasz commented on pull request #711: URL: https://github.com/apache/logging-log4j2/pull/711#issuecomment-1018782447 @garydgregory, everything should be Ok now. -- 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 closed pull request #697: [idea & example, request for input] Thoughts on using a code formatter?
carterkozak closed pull request #697: URL: https://github.com/apache/logging-log4j2/pull/697 -- 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 #711: Use Log4j1XmlLayout instead of XmlLayout
garydgregory commented on pull request #711: URL: https://github.com/apache/logging-log4j2/pull/711#issuecomment-101578 @ppkarwasz CC: @rgoers Something is not quite right IMO: All the layout builders in this package build core layouts and wrap them. Why should this one be different from all the others? What am I missing? -- 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 edited a comment on pull request #726: LOG4J2-3358: Fix substitutions when programmatic configuration is used
carterkozak edited a comment on pull request #726: URL: https://github.com/apache/logging-log4j2/pull/726#issuecomment-1018588038 in 2.17.1 we paired down the list of allowed lookups based on javadoc, however that wasn't correct because the objects aren't always used precisely how the AbstractConfiguration expects, leading to vastly different behavior based on how the configuration (thus StrSubstitutor) is created. -- 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-3288) Interpolator non-plugin codepath doesn't include all log4j-core lookups
[
https://issues.apache.org/jira/browse/LOG4J2-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480303#comment-17480303
]
Carter Kozak commented on LOG4J2-3288:
--
[~rgoers] I'd like to reintroduce the reverted behavior based on
https://issues.apache.org/jira/browse/LOG4J2-3358 where the initial non-plugin
interpolator is still used throughout the configuration since it isn't created
based on nodes. There are several other places where new instances are created,
in which we'd expect them to support the full breadth of features.
PR is https://github.com/apache/logging-log4j2/pull/726
> Interpolator non-plugin codepath doesn't include all log4j-core lookups
> ---
>
> Key: LOG4J2-3288
> URL: https://issues.apache.org/jira/browse/LOG4J2-3288
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration, Core
>Affects Versions: 2.17.0
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
>
> It appears that {{bundle}} {{{}event{}}}, and {{sd}} lookups are not
> registered.
> There's a comment suggesting that the PluginManager could be used, however
> that will require additional validation before I'm comfortable enabling it:
> Logging initialization is very static and tricky, and it's easy to produce
> deadlocks when referencing logging code within initialization.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3328) Log4j 1.2 bridge does not support system properties in log4j.xml
[
https://issues.apache.org/jira/browse/LOG4J2-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480304#comment-17480304
]
Paul Cooper commented on LOG4J2-3328:
-
Gary,
I pulled the latest snapshot build from the link above, and it appears your fix
is working correctly.
Thank you for your quick response.
Do you have any idea when 2.17.2 will get rolled out?
Paul
> Log4j 1.2 bridge does not support system properties in log4j.xml
>
>
> Key: LOG4J2-3328
> URL: https://issues.apache.org/jira/browse/LOG4J2-3328
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: {{Windows 10}}
> {{Amazon Linux}}
>Reporter: Paul Cooper
>Assignee: Gary D. Gregory
>Priority: Blocker
> Fix For: 2.17.2
>
>
> I am attempting to use the log4j bridge with log4j2, and cannot use system
> properties to set a location for my log files.
> Reported here:
> [stackoverflow|https://stackoverflow.com/questions/70628593/system-property-not-being-read-by-log4j2-lo4j1-bridge]
> My log4j.xml file:
> {{log4j-dev.xml}}
> {{...}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{...}}
> The setenv.bat entry where I define which log4j.xml to use:
> {{-Dlog4j2.debug=true -Dlog4j.configuration=log4j-dev.xml}}
> The properties shown in the tomcat log illustrating that the system property
> in question is being supplied to the log4j1 bridge
> {{...}}
> {{Command line argument: -Dlog4j2.debug=true}}
> {{Command line argument: -Dlog4j.logDir=C:\dev\apache-tomcat-8.5.50\logs}}
> {{Command line argument: -Dlog4j.configuration=log4j-dev.xml}}
> {{Command line argument: -Dcatalina.base=C:\dev\apache-tomcat-8.5.50}}
> {{Command line argument: -Dcatalina.home=C:\dev\apache-tomcat-8.5.50}}
> {{Command line argument: -Djava.io.tmpdir=C:\dev\apache-tomcat-8.5.50\temp}}
> {{...}}
> And the part of the log that shows where the log file is successfully created
> and what path it is using:
> {{...}}
> {{DEBUG StatusLogger Class name: [org.apache.log4j.RollingFileAppender]}}
> {{DEBUG StatusLogger Parsing layout of class:
> "org.apache.log4j.PatternLayout"}}
> {{DEBUG StatusLogger PluginManager 'Converter' found 47 plugins}}
> {{TRACE StatusLogger New file '${catalina.base}/etl.log' created = true}}
> {{DEBUG StatusLogger Returning file creation time for
> C:\dev\apache-tomcat-8.5.50\bin\${catalina.base}\etl.log}}
> {{DEBUG StatusLogger Starting RollingFileManager ${catalina.base}/etl.log}}
> {{...}}
> The log file is being created in a folder named "${catalina.base}", in
> whatever directory I'm in when I start tomcat. The issue is similar to this
> Jira issue, LOG4J2-2951, and that issue was just resolved in early December.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3328) Log4j 1.2 bridge does not support system properties in log4j.xml
[
https://issues.apache.org/jira/browse/LOG4J2-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480305#comment-17480305
]
Gary D. Gregory commented on LOG4J2-3328:
-
Probably maybe possibly in 2 weeks or thereabouts, no guarantees.
> Log4j 1.2 bridge does not support system properties in log4j.xml
>
>
> Key: LOG4J2-3328
> URL: https://issues.apache.org/jira/browse/LOG4J2-3328
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: {{Windows 10}}
> {{Amazon Linux}}
>Reporter: Paul Cooper
>Assignee: Gary D. Gregory
>Priority: Blocker
> Fix For: 2.17.2
>
>
> I am attempting to use the log4j bridge with log4j2, and cannot use system
> properties to set a location for my log files.
> Reported here:
> [stackoverflow|https://stackoverflow.com/questions/70628593/system-property-not-being-read-by-log4j2-lo4j1-bridge]
> My log4j.xml file:
> {{log4j-dev.xml}}
> {{...}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{...}}
> The setenv.bat entry where I define which log4j.xml to use:
> {{-Dlog4j2.debug=true -Dlog4j.configuration=log4j-dev.xml}}
> The properties shown in the tomcat log illustrating that the system property
> in question is being supplied to the log4j1 bridge
> {{...}}
> {{Command line argument: -Dlog4j2.debug=true}}
> {{Command line argument: -Dlog4j.logDir=C:\dev\apache-tomcat-8.5.50\logs}}
> {{Command line argument: -Dlog4j.configuration=log4j-dev.xml}}
> {{Command line argument: -Dcatalina.base=C:\dev\apache-tomcat-8.5.50}}
> {{Command line argument: -Dcatalina.home=C:\dev\apache-tomcat-8.5.50}}
> {{Command line argument: -Djava.io.tmpdir=C:\dev\apache-tomcat-8.5.50\temp}}
> {{...}}
> And the part of the log that shows where the log file is successfully created
> and what path it is using:
> {{...}}
> {{DEBUG StatusLogger Class name: [org.apache.log4j.RollingFileAppender]}}
> {{DEBUG StatusLogger Parsing layout of class:
> "org.apache.log4j.PatternLayout"}}
> {{DEBUG StatusLogger PluginManager 'Converter' found 47 plugins}}
> {{TRACE StatusLogger New file '${catalina.base}/etl.log' created = true}}
> {{DEBUG StatusLogger Returning file creation time for
> C:\dev\apache-tomcat-8.5.50\bin\${catalina.base}\etl.log}}
> {{DEBUG StatusLogger Starting RollingFileManager ${catalina.base}/etl.log}}
> {{...}}
> The log file is being created in a folder named "${catalina.base}", in
> whatever directory I'm in when I start tomcat. The issue is similar to this
> Jira issue, LOG4J2-2951, and that issue was just resolved in early December.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] carterkozak closed pull request #656: [WIP] Interpolator always loads StrLookup plugins
carterkozak closed pull request #656: URL: https://github.com/apache/logging-log4j2/pull/656 -- 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 merged pull request #726: LOG4J2-3358: Fix substitutions when programmatic configuration is used
carterkozak merged pull request #726: URL: https://github.com/apache/logging-log4j2/pull/726 -- 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-3358) 2.17.1: JsonLayout Context no longer working.
[
https://issues.apache.org/jira/browse/LOG4J2-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480307#comment-17480307
]
ASF subversion and git services commented on LOG4J2-3358:
-
Commit 7ca3c4f5f206ca81dfdda2699703c9abc4d22624 in logging-log4j2's branch
refs/heads/release-2.x from Carter Kozak
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=7ca3c4f ]
LOG4J2-3358: Fix substitutions when programmatic configuration is used (#726)
The problem is that some configuration creation paths fail to
use the Interpolator constructor which loads all plugins. This
produces inconsistent behavior based on the configuration construction
path.
By merging code-paths, we can provide consistent behavior.
> 2.17.1: JsonLayout Context no longer working.
> -
>
> Key: LOG4J2-3358
> URL: https://issues.apache.org/jira/browse/LOG4J2-3358
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.17.1
>Reporter: Markus Duft
>Assignee: Carter Kozak
>Priority: Major
>
> We're creating a RollingFileAppender programmatically using a JsonLayout.
> This uses fields using ${ctx:...} expansion. This stopped working when
> upgrading from 2.17.0 to 2.17.1.
> The code is as follows:
> {code:java}
> /**
> * Creates a rolling file appender that write audit entries to a
> programmatically readable JSON file.
> */
> private RollingFileAppender createJsonAppender(Path logDir) {
> List fields = new ArrayList<>();
>
> fields.add(KeyValuePair.newBuilder().setKey("who").setValue("${ctx:WHO}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("what").setValue("${ctx:WHAT}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("method").setValue("${ctx:METHOD}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("parameters").setValue("${ctx:PARAMETERS}").build());
>
> RollingFileAppender.Builder builder =
> RollingFileAppender.newBuilder();
> builder.setName("auditJsonLogger");
> builder.withFileName(logDir.resolve(LOG_JSON_FILENAME).toString());
>
> builder.withFilePattern(logDir.resolve(LOG_JSON_FILEPATTERN).toString());
> builder.withPolicy(SizeBasedTriggeringPolicy.createPolicy("10M"));
>
> builder.setLayout(JsonLayout.newBuilder().setCompact(true).setEventEol(true).setConfiguration(new
> DefaultConfiguration())
> .setAdditionalFields(fields.toArray(new
> KeyValuePair[0])).build());
> builder.withStrategy(
>
> DefaultRolloverStrategy.newBuilder().withCompressionLevelStr(String.valueOf(Deflater.DEFAULT_COMPRESSION))
>
> .withMax(Integer.toString(LOG_MAX_INDEX)).withFileIndex("min").build());
> return builder.build();
> } {code}
> We also tried to use %X\{...} as well as $${ctx:...} expansions instead to no
> avail. The log file always contains the *literal* string we use in
> .setValue(), i.e. lines like this:
> {noformat}
> {"instant":{"epochSecond":1642756242,"nanoOfSecond":271091900},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":65,"threadPriority":5,"who":"${ctx:WHO}","what":"${ctx:WHAT}","method":"${ctx:METHOD}","parameters":"${ctx:PARAMETERS}"}{noformat}
> Reverting to 2.17.0 will correctly give lines like this in the JSON file:
> {noformat}
> {"instant":{"epochSecond":1642756430,"nanoOfSecond":923210700},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":62,"threadPriority":5,"who":"marku","what":"ObjectConsistencyCheckOperation","method":"-","parameters":"{dryRun=false,
> roots=[io.bdeploy/demo/client-app/linux:1.0.0,
> io.bdeploy/demo/client-app/linux:2.0.0,
> io.bdeploy/demo/client-app/windows:1.0.0, ...]}"}{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3358) 2.17.1: JsonLayout Context no longer working.
[
https://issues.apache.org/jira/browse/LOG4J2-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480312#comment-17480312
]
ASF subversion and git services commented on LOG4J2-3358:
-
Commit c062f55318cac4205c7f7606b8e3091f67999516 in logging-log4j2's branch
refs/heads/master from Carter Kozak
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c062f55 ]
LOG4J2-3358: Fix substitutions when programmatic configuration is used (#726)
The problem is that some configuration creation paths fail to
use the Interpolator constructor which loads all plugins. This
produces inconsistent behavior based on the configuration construction
path.
By merging code-paths, we can provide consistent behavior.
> 2.17.1: JsonLayout Context no longer working.
> -
>
> Key: LOG4J2-3358
> URL: https://issues.apache.org/jira/browse/LOG4J2-3358
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.17.1
>Reporter: Markus Duft
>Assignee: Carter Kozak
>Priority: Major
>
> We're creating a RollingFileAppender programmatically using a JsonLayout.
> This uses fields using ${ctx:...} expansion. This stopped working when
> upgrading from 2.17.0 to 2.17.1.
> The code is as follows:
> {code:java}
> /**
> * Creates a rolling file appender that write audit entries to a
> programmatically readable JSON file.
> */
> private RollingFileAppender createJsonAppender(Path logDir) {
> List fields = new ArrayList<>();
>
> fields.add(KeyValuePair.newBuilder().setKey("who").setValue("${ctx:WHO}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("what").setValue("${ctx:WHAT}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("method").setValue("${ctx:METHOD}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("parameters").setValue("${ctx:PARAMETERS}").build());
>
> RollingFileAppender.Builder builder =
> RollingFileAppender.newBuilder();
> builder.setName("auditJsonLogger");
> builder.withFileName(logDir.resolve(LOG_JSON_FILENAME).toString());
>
> builder.withFilePattern(logDir.resolve(LOG_JSON_FILEPATTERN).toString());
> builder.withPolicy(SizeBasedTriggeringPolicy.createPolicy("10M"));
>
> builder.setLayout(JsonLayout.newBuilder().setCompact(true).setEventEol(true).setConfiguration(new
> DefaultConfiguration())
> .setAdditionalFields(fields.toArray(new
> KeyValuePair[0])).build());
> builder.withStrategy(
>
> DefaultRolloverStrategy.newBuilder().withCompressionLevelStr(String.valueOf(Deflater.DEFAULT_COMPRESSION))
>
> .withMax(Integer.toString(LOG_MAX_INDEX)).withFileIndex("min").build());
> return builder.build();
> } {code}
> We also tried to use %X\{...} as well as $${ctx:...} expansions instead to no
> avail. The log file always contains the *literal* string we use in
> .setValue(), i.e. lines like this:
> {noformat}
> {"instant":{"epochSecond":1642756242,"nanoOfSecond":271091900},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":65,"threadPriority":5,"who":"${ctx:WHO}","what":"${ctx:WHAT}","method":"${ctx:METHOD}","parameters":"${ctx:PARAMETERS}"}{noformat}
> Reverting to 2.17.0 will correctly give lines like this in the JSON file:
> {noformat}
> {"instant":{"epochSecond":1642756430,"nanoOfSecond":923210700},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":62,"threadPriority":5,"who":"marku","what":"ObjectConsistencyCheckOperation","method":"-","parameters":"{dryRun=false,
> roots=[io.bdeploy/demo/client-app/linux:1.0.0,
> io.bdeploy/demo/client-app/linux:2.0.0,
> io.bdeploy/demo/client-app/windows:1.0.0, ...]}"}{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3358) 2.17.1: JsonLayout Context no longer working.
[
https://issues.apache.org/jira/browse/LOG4J2-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak resolved LOG4J2-3358.
--
Resolution: Fixed
> 2.17.1: JsonLayout Context no longer working.
> -
>
> Key: LOG4J2-3358
> URL: https://issues.apache.org/jira/browse/LOG4J2-3358
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.17.1
>Reporter: Markus Duft
>Assignee: Carter Kozak
>Priority: Major
>
> We're creating a RollingFileAppender programmatically using a JsonLayout.
> This uses fields using ${ctx:...} expansion. This stopped working when
> upgrading from 2.17.0 to 2.17.1.
> The code is as follows:
> {code:java}
> /**
> * Creates a rolling file appender that write audit entries to a
> programmatically readable JSON file.
> */
> private RollingFileAppender createJsonAppender(Path logDir) {
> List fields = new ArrayList<>();
>
> fields.add(KeyValuePair.newBuilder().setKey("who").setValue("${ctx:WHO}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("what").setValue("${ctx:WHAT}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("method").setValue("${ctx:METHOD}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("parameters").setValue("${ctx:PARAMETERS}").build());
>
> RollingFileAppender.Builder builder =
> RollingFileAppender.newBuilder();
> builder.setName("auditJsonLogger");
> builder.withFileName(logDir.resolve(LOG_JSON_FILENAME).toString());
>
> builder.withFilePattern(logDir.resolve(LOG_JSON_FILEPATTERN).toString());
> builder.withPolicy(SizeBasedTriggeringPolicy.createPolicy("10M"));
>
> builder.setLayout(JsonLayout.newBuilder().setCompact(true).setEventEol(true).setConfiguration(new
> DefaultConfiguration())
> .setAdditionalFields(fields.toArray(new
> KeyValuePair[0])).build());
> builder.withStrategy(
>
> DefaultRolloverStrategy.newBuilder().withCompressionLevelStr(String.valueOf(Deflater.DEFAULT_COMPRESSION))
>
> .withMax(Integer.toString(LOG_MAX_INDEX)).withFileIndex("min").build());
> return builder.build();
> } {code}
> We also tried to use %X\{...} as well as $${ctx:...} expansions instead to no
> avail. The log file always contains the *literal* string we use in
> .setValue(), i.e. lines like this:
> {noformat}
> {"instant":{"epochSecond":1642756242,"nanoOfSecond":271091900},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":65,"threadPriority":5,"who":"${ctx:WHO}","what":"${ctx:WHAT}","method":"${ctx:METHOD}","parameters":"${ctx:PARAMETERS}"}{noformat}
> Reverting to 2.17.0 will correctly give lines like this in the JSON file:
> {noformat}
> {"instant":{"epochSecond":1642756430,"nanoOfSecond":923210700},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":62,"threadPriority":5,"who":"marku","what":"ObjectConsistencyCheckOperation","method":"-","parameters":"{dryRun=false,
> roots=[io.bdeploy/demo/client-app/linux:1.0.0,
> io.bdeploy/demo/client-app/linux:2.0.0,
> io.bdeploy/demo/client-app/windows:1.0.0, ...]}"}{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3358) 2.17.1: JsonLayout Context no longer working.
[
https://issues.apache.org/jira/browse/LOG4J2-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480313#comment-17480313
]
Carter Kozak commented on LOG4J2-3358:
--
[~mduft] Please verify with a snapshot and close this ticket once you're happy
with it – thank you for the report!
> 2.17.1: JsonLayout Context no longer working.
> -
>
> Key: LOG4J2-3358
> URL: https://issues.apache.org/jira/browse/LOG4J2-3358
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.17.1
>Reporter: Markus Duft
>Assignee: Carter Kozak
>Priority: Major
>
> We're creating a RollingFileAppender programmatically using a JsonLayout.
> This uses fields using ${ctx:...} expansion. This stopped working when
> upgrading from 2.17.0 to 2.17.1.
> The code is as follows:
> {code:java}
> /**
> * Creates a rolling file appender that write audit entries to a
> programmatically readable JSON file.
> */
> private RollingFileAppender createJsonAppender(Path logDir) {
> List fields = new ArrayList<>();
>
> fields.add(KeyValuePair.newBuilder().setKey("who").setValue("${ctx:WHO}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("what").setValue("${ctx:WHAT}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("method").setValue("${ctx:METHOD}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("parameters").setValue("${ctx:PARAMETERS}").build());
>
> RollingFileAppender.Builder builder =
> RollingFileAppender.newBuilder();
> builder.setName("auditJsonLogger");
> builder.withFileName(logDir.resolve(LOG_JSON_FILENAME).toString());
>
> builder.withFilePattern(logDir.resolve(LOG_JSON_FILEPATTERN).toString());
> builder.withPolicy(SizeBasedTriggeringPolicy.createPolicy("10M"));
>
> builder.setLayout(JsonLayout.newBuilder().setCompact(true).setEventEol(true).setConfiguration(new
> DefaultConfiguration())
> .setAdditionalFields(fields.toArray(new
> KeyValuePair[0])).build());
> builder.withStrategy(
>
> DefaultRolloverStrategy.newBuilder().withCompressionLevelStr(String.valueOf(Deflater.DEFAULT_COMPRESSION))
>
> .withMax(Integer.toString(LOG_MAX_INDEX)).withFileIndex("min").build());
> return builder.build();
> } {code}
> We also tried to use %X\{...} as well as $${ctx:...} expansions instead to no
> avail. The log file always contains the *literal* string we use in
> .setValue(), i.e. lines like this:
> {noformat}
> {"instant":{"epochSecond":1642756242,"nanoOfSecond":271091900},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":65,"threadPriority":5,"who":"${ctx:WHO}","what":"${ctx:WHAT}","method":"${ctx:METHOD}","parameters":"${ctx:PARAMETERS}"}{noformat}
> Reverting to 2.17.0 will correctly give lines like this in the JSON file:
> {noformat}
> {"instant":{"epochSecond":1642756430,"nanoOfSecond":923210700},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":62,"threadPriority":5,"who":"marku","what":"ObjectConsistencyCheckOperation","method":"-","parameters":"{dryRun=false,
> roots=[io.bdeploy/demo/client-app/linux:1.0.0,
> io.bdeploy/demo/client-app/linux:2.0.0,
> io.bdeploy/demo/client-app/windows:1.0.0, ...]}"}{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3288) Interpolator non-plugin codepath doesn't include all log4j-core lookups
[
https://issues.apache.org/jira/browse/LOG4J2-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak updated LOG4J2-3288:
-
Fix Version/s: 2.17.2
> Interpolator non-plugin codepath doesn't include all log4j-core lookups
> ---
>
> Key: LOG4J2-3288
> URL: https://issues.apache.org/jira/browse/LOG4J2-3288
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration, Core
>Affects Versions: 2.17.0
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> It appears that {{bundle}} {{{}event{}}}, and {{sd}} lookups are not
> registered.
> There's a comment suggesting that the PluginManager could be used, however
> that will require additional validation before I'm comfortable enabling it:
> Logging initialization is very static and tricky, and it's easy to produce
> deadlocks when referencing logging code within initialization.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3358) 2.17.1: JsonLayout Context no longer working.
[
https://issues.apache.org/jira/browse/LOG4J2-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak updated LOG4J2-3358:
-
Fix Version/s: 2.17.2
> 2.17.1: JsonLayout Context no longer working.
> -
>
> Key: LOG4J2-3358
> URL: https://issues.apache.org/jira/browse/LOG4J2-3358
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.17.1
>Reporter: Markus Duft
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> We're creating a RollingFileAppender programmatically using a JsonLayout.
> This uses fields using ${ctx:...} expansion. This stopped working when
> upgrading from 2.17.0 to 2.17.1.
> The code is as follows:
> {code:java}
> /**
> * Creates a rolling file appender that write audit entries to a
> programmatically readable JSON file.
> */
> private RollingFileAppender createJsonAppender(Path logDir) {
> List fields = new ArrayList<>();
>
> fields.add(KeyValuePair.newBuilder().setKey("who").setValue("${ctx:WHO}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("what").setValue("${ctx:WHAT}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("method").setValue("${ctx:METHOD}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("parameters").setValue("${ctx:PARAMETERS}").build());
>
> RollingFileAppender.Builder builder =
> RollingFileAppender.newBuilder();
> builder.setName("auditJsonLogger");
> builder.withFileName(logDir.resolve(LOG_JSON_FILENAME).toString());
>
> builder.withFilePattern(logDir.resolve(LOG_JSON_FILEPATTERN).toString());
> builder.withPolicy(SizeBasedTriggeringPolicy.createPolicy("10M"));
>
> builder.setLayout(JsonLayout.newBuilder().setCompact(true).setEventEol(true).setConfiguration(new
> DefaultConfiguration())
> .setAdditionalFields(fields.toArray(new
> KeyValuePair[0])).build());
> builder.withStrategy(
>
> DefaultRolloverStrategy.newBuilder().withCompressionLevelStr(String.valueOf(Deflater.DEFAULT_COMPRESSION))
>
> .withMax(Integer.toString(LOG_MAX_INDEX)).withFileIndex("min").build());
> return builder.build();
> } {code}
> We also tried to use %X\{...} as well as $${ctx:...} expansions instead to no
> avail. The log file always contains the *literal* string we use in
> .setValue(), i.e. lines like this:
> {noformat}
> {"instant":{"epochSecond":1642756242,"nanoOfSecond":271091900},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":65,"threadPriority":5,"who":"${ctx:WHO}","what":"${ctx:WHAT}","method":"${ctx:METHOD}","parameters":"${ctx:PARAMETERS}"}{noformat}
> Reverting to 2.17.0 will correctly give lines like this in the JSON file:
> {noformat}
> {"instant":{"epochSecond":1642756430,"nanoOfSecond":923210700},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":62,"threadPriority":5,"who":"marku","what":"ObjectConsistencyCheckOperation","method":"-","parameters":"{dryRun=false,
> roots=[io.bdeploy/demo/client-app/linux:1.0.0,
> io.bdeploy/demo/client-app/linux:2.0.0,
> io.bdeploy/demo/client-app/windows:1.0.0, ...]}"}{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3288) Interpolator non-plugin codepath doesn't include all log4j-core lookups
[
https://issues.apache.org/jira/browse/LOG4J2-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak resolved LOG4J2-3288.
--
Resolution: Fixed
Closing via
Commit 7ca3c4f5f206ca81dfdda2699703c9abc4d22624 in logging-log4j2's branch
refs/heads/release-2.x from Carter Kozak
Commit c062f55318cac4205c7f7606b8e3091f67999516 in logging-log4j2's branch
refs/heads/master from Carter Kozak
> Interpolator non-plugin codepath doesn't include all log4j-core lookups
> ---
>
> Key: LOG4J2-3288
> URL: https://issues.apache.org/jira/browse/LOG4J2-3288
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration, Core
>Affects Versions: 2.17.0
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> It appears that {{bundle}} {{{}event{}}}, and {{sd}} lookups are not
> registered.
> There's a comment suggesting that the PluginManager could be used, however
> that will require additional validation before I'm comfortable enabling it:
> Logging initialization is very static and tricky, and it's easy to produce
> deadlocks when referencing logging code within initialization.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (LOG4J2-3288) Interpolator non-plugin codepath doesn't include all log4j-core lookups
[
https://issues.apache.org/jira/browse/LOG4J2-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak closed LOG4J2-3288.
> Interpolator non-plugin codepath doesn't include all log4j-core lookups
> ---
>
> Key: LOG4J2-3288
> URL: https://issues.apache.org/jira/browse/LOG4J2-3288
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration, Core
>Affects Versions: 2.17.0
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> It appears that {{bundle}} {{{}event{}}}, and {{sd}} lookups are not
> registered.
> There's a comment suggesting that the PluginManager could be used, however
> that will require additional validation before I'm comfortable enabling it:
> Logging initialization is very static and tricky, and it's easy to produce
> deadlocks when referencing logging code within initialization.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3358) 2.17.1: JsonLayout Context no longer working.
[
https://issues.apache.org/jira/browse/LOG4J2-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480315#comment-17480315
]
ASF subversion and git services commented on LOG4J2-3358:
-
Commit f151e0cd9b4c684cc2e76e20b02ed4d94d2a4ec1 in logging-log4j2's branch
refs/heads/release-2.x from Carter Kozak
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=f151e0c ]
Fix LOG4J2-3358 changelog
> 2.17.1: JsonLayout Context no longer working.
> -
>
> Key: LOG4J2-3358
> URL: https://issues.apache.org/jira/browse/LOG4J2-3358
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.17.1
>Reporter: Markus Duft
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> We're creating a RollingFileAppender programmatically using a JsonLayout.
> This uses fields using ${ctx:...} expansion. This stopped working when
> upgrading from 2.17.0 to 2.17.1.
> The code is as follows:
> {code:java}
> /**
> * Creates a rolling file appender that write audit entries to a
> programmatically readable JSON file.
> */
> private RollingFileAppender createJsonAppender(Path logDir) {
> List fields = new ArrayList<>();
>
> fields.add(KeyValuePair.newBuilder().setKey("who").setValue("${ctx:WHO}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("what").setValue("${ctx:WHAT}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("method").setValue("${ctx:METHOD}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("parameters").setValue("${ctx:PARAMETERS}").build());
>
> RollingFileAppender.Builder builder =
> RollingFileAppender.newBuilder();
> builder.setName("auditJsonLogger");
> builder.withFileName(logDir.resolve(LOG_JSON_FILENAME).toString());
>
> builder.withFilePattern(logDir.resolve(LOG_JSON_FILEPATTERN).toString());
> builder.withPolicy(SizeBasedTriggeringPolicy.createPolicy("10M"));
>
> builder.setLayout(JsonLayout.newBuilder().setCompact(true).setEventEol(true).setConfiguration(new
> DefaultConfiguration())
> .setAdditionalFields(fields.toArray(new
> KeyValuePair[0])).build());
> builder.withStrategy(
>
> DefaultRolloverStrategy.newBuilder().withCompressionLevelStr(String.valueOf(Deflater.DEFAULT_COMPRESSION))
>
> .withMax(Integer.toString(LOG_MAX_INDEX)).withFileIndex("min").build());
> return builder.build();
> } {code}
> We also tried to use %X\{...} as well as $${ctx:...} expansions instead to no
> avail. The log file always contains the *literal* string we use in
> .setValue(), i.e. lines like this:
> {noformat}
> {"instant":{"epochSecond":1642756242,"nanoOfSecond":271091900},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":65,"threadPriority":5,"who":"${ctx:WHO}","what":"${ctx:WHAT}","method":"${ctx:METHOD}","parameters":"${ctx:PARAMETERS}"}{noformat}
> Reverting to 2.17.0 will correctly give lines like this in the JSON file:
> {noformat}
> {"instant":{"epochSecond":1642756430,"nanoOfSecond":923210700},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":62,"threadPriority":5,"who":"marku","what":"ObjectConsistencyCheckOperation","method":"-","parameters":"{dryRun=false,
> roots=[io.bdeploy/demo/client-app/linux:1.0.0,
> io.bdeploy/demo/client-app/linux:2.0.0,
> io.bdeploy/demo/client-app/windows:1.0.0, ...]}"}{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3358) 2.17.1: JsonLayout Context no longer working.
[
https://issues.apache.org/jira/browse/LOG4J2-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480316#comment-17480316
]
ASF subversion and git services commented on LOG4J2-3358:
-
Commit 9f35a37da915de0fcf4d6c7c6cae2908d6c46677 in logging-log4j2's branch
refs/heads/master from Carter Kozak
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=9f35a37 ]
Fix LOG4J2-3358 changelog
> 2.17.1: JsonLayout Context no longer working.
> -
>
> Key: LOG4J2-3358
> URL: https://issues.apache.org/jira/browse/LOG4J2-3358
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.17.1
>Reporter: Markus Duft
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> We're creating a RollingFileAppender programmatically using a JsonLayout.
> This uses fields using ${ctx:...} expansion. This stopped working when
> upgrading from 2.17.0 to 2.17.1.
> The code is as follows:
> {code:java}
> /**
> * Creates a rolling file appender that write audit entries to a
> programmatically readable JSON file.
> */
> private RollingFileAppender createJsonAppender(Path logDir) {
> List fields = new ArrayList<>();
>
> fields.add(KeyValuePair.newBuilder().setKey("who").setValue("${ctx:WHO}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("what").setValue("${ctx:WHAT}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("method").setValue("${ctx:METHOD}").build());
>
> fields.add(KeyValuePair.newBuilder().setKey("parameters").setValue("${ctx:PARAMETERS}").build());
>
> RollingFileAppender.Builder builder =
> RollingFileAppender.newBuilder();
> builder.setName("auditJsonLogger");
> builder.withFileName(logDir.resolve(LOG_JSON_FILENAME).toString());
>
> builder.withFilePattern(logDir.resolve(LOG_JSON_FILEPATTERN).toString());
> builder.withPolicy(SizeBasedTriggeringPolicy.createPolicy("10M"));
>
> builder.setLayout(JsonLayout.newBuilder().setCompact(true).setEventEol(true).setConfiguration(new
> DefaultConfiguration())
> .setAdditionalFields(fields.toArray(new
> KeyValuePair[0])).build());
> builder.withStrategy(
>
> DefaultRolloverStrategy.newBuilder().withCompressionLevelStr(String.valueOf(Deflater.DEFAULT_COMPRESSION))
>
> .withMax(Integer.toString(LOG_MAX_INDEX)).withFileIndex("min").build());
> return builder.build();
> } {code}
> We also tried to use %X\{...} as well as $${ctx:...} expansions instead to no
> avail. The log file always contains the *literal* string we use in
> .setValue(), i.e. lines like this:
> {noformat}
> {"instant":{"epochSecond":1642756242,"nanoOfSecond":271091900},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":65,"threadPriority":5,"who":"${ctx:WHO}","what":"${ctx:WHAT}","method":"${ctx:METHOD}","parameters":"${ctx:PARAMETERS}"}{noformat}
> Reverting to 2.17.0 will correctly give lines like this in the JSON file:
> {noformat}
> {"instant":{"epochSecond":1642756430,"nanoOfSecond":923210700},"thread":"hive/fsck","level":"INFO","message":"Execute","endOfBatch":false,"threadId":62,"threadPriority":5,"who":"marku","what":"ObjectConsistencyCheckOperation","method":"-","parameters":"{dryRun=false,
> roots=[io.bdeploy/demo/client-app/linux:1.0.0,
> io.bdeploy/demo/client-app/linux:2.0.0,
> io.bdeploy/demo/client-app/windows:1.0.0, ...]}"}{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3333) Classloader deadlock in ThreadContextDataInjector
[
https://issues.apache.org/jira/browse/LOG4J2-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak updated LOG4J2-:
-
Fix Version/s: 2.17.2
> Classloader deadlock in ThreadContextDataInjector
> -
>
> Key: LOG4J2-
> URL: https://issues.apache.org/jira/browse/LOG4J2-
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.1
>Reporter: Ryan Schmitt
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> I ran into a deadlock involving {{ThreadContextDataInjector}} and the "Thread
> Context Data Task" background thread. The basic idea is that the "main"
> thread holds the classloader lock (since log4j2 is initialized during class
> loading, as a rule) and tries to acquire the provider lock, while the "Thread
> Context Data Task" thread holds the provider lock and tries to load classes:
> {code}
> Found one Java-level deadlock:
> =
> "Thread Context Data Task":
> waiting to lock monitor 0x7fde50835958 (object 0x00077bbf51c8, a
> org.powermock.core.classloader.MockClassLoader),
> which is held by "main"
> "main":
> waiting for ownable synchronizer 0x000773e77ae8, (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "Thread Context Data Task"
> Java stack information for the threads listed above:
> ===
> "Thread Context Data Task":
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.getServiceProviders(ThreadContextDataInjector.java:85)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.initServiceProviders(ThreadContextDataInjector.java:73)
> at
> org.apache.logging.log4j.core.LoggerContext$ThreadContextDataTask.run(LoggerContext.java:785)
> at java.lang.Thread.run(Thread.java:748)
> "main":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000773e77ae8> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.initServiceProviders(ThreadContextDataInjector.java:70)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.getProviders(ThreadContextDataInjector.java:285)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.access$000(ThreadContextDataInjector.java:55)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector$ForDefaultThreadContextMap.(ThreadContextDataInjector.java:108)
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createDefaultInjector(ContextDataInjectorFactory.java:91)
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createInjector(ContextDataInjectorFactory.java:71)
> at
> org.apache.logging.log4j.core.impl.Log4jLogEvent.(Log4jLogEvent.java:58)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:643)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:196)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:137)
> at
> org.apache.logging.log4j.jcl.LogAdapter.getContext(LogAdapter.java:40)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(A
[jira] [Commented] (LOG4J2-3333) Classloader deadlock in ThreadContextDataInjector
[
https://issues.apache.org/jira/browse/LOG4J2-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480317#comment-17480317
]
ASF subversion and git services commented on LOG4J2-:
-
Commit fc31b44b629d9fe46bd96bfd02382519dfdb5f40 in logging-log4j2's branch
refs/heads/release-2.x from Carter Kozak
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=fc31b44 ]
LOG4J2-: Fix ThreadContextDataInjector classloader deadlock
> Classloader deadlock in ThreadContextDataInjector
> -
>
> Key: LOG4J2-
> URL: https://issues.apache.org/jira/browse/LOG4J2-
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.1
>Reporter: Ryan Schmitt
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> I ran into a deadlock involving {{ThreadContextDataInjector}} and the "Thread
> Context Data Task" background thread. The basic idea is that the "main"
> thread holds the classloader lock (since log4j2 is initialized during class
> loading, as a rule) and tries to acquire the provider lock, while the "Thread
> Context Data Task" thread holds the provider lock and tries to load classes:
> {code}
> Found one Java-level deadlock:
> =
> "Thread Context Data Task":
> waiting to lock monitor 0x7fde50835958 (object 0x00077bbf51c8, a
> org.powermock.core.classloader.MockClassLoader),
> which is held by "main"
> "main":
> waiting for ownable synchronizer 0x000773e77ae8, (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "Thread Context Data Task"
> Java stack information for the threads listed above:
> ===
> "Thread Context Data Task":
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.getServiceProviders(ThreadContextDataInjector.java:85)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.initServiceProviders(ThreadContextDataInjector.java:73)
> at
> org.apache.logging.log4j.core.LoggerContext$ThreadContextDataTask.run(LoggerContext.java:785)
> at java.lang.Thread.run(Thread.java:748)
> "main":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000773e77ae8> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.initServiceProviders(ThreadContextDataInjector.java:70)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.getProviders(ThreadContextDataInjector.java:285)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.access$000(ThreadContextDataInjector.java:55)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector$ForDefaultThreadContextMap.(ThreadContextDataInjector.java:108)
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createDefaultInjector(ContextDataInjectorFactory.java:91)
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createInjector(ContextDataInjectorFactory.java:71)
> at
> org.apache.logging.log4j.core.impl.Log4jLogEvent.(Log4jLogEvent.java:58)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:643)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
> at org.apache.lo
[jira] [Commented] (LOG4J2-3333) Classloader deadlock in ThreadContextDataInjector
[
https://issues.apache.org/jira/browse/LOG4J2-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480318#comment-17480318
]
ASF subversion and git services commented on LOG4J2-:
-
Commit 46faed471a2c360e59972377a698bf052ef4c004 in logging-log4j2's branch
refs/heads/master from Carter Kozak
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=46faed4 ]
LOG4J2-: Fix ThreadContextDataInjector classloader deadlock
> Classloader deadlock in ThreadContextDataInjector
> -
>
> Key: LOG4J2-
> URL: https://issues.apache.org/jira/browse/LOG4J2-
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.1
>Reporter: Ryan Schmitt
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> I ran into a deadlock involving {{ThreadContextDataInjector}} and the "Thread
> Context Data Task" background thread. The basic idea is that the "main"
> thread holds the classloader lock (since log4j2 is initialized during class
> loading, as a rule) and tries to acquire the provider lock, while the "Thread
> Context Data Task" thread holds the provider lock and tries to load classes:
> {code}
> Found one Java-level deadlock:
> =
> "Thread Context Data Task":
> waiting to lock monitor 0x7fde50835958 (object 0x00077bbf51c8, a
> org.powermock.core.classloader.MockClassLoader),
> which is held by "main"
> "main":
> waiting for ownable synchronizer 0x000773e77ae8, (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "Thread Context Data Task"
> Java stack information for the threads listed above:
> ===
> "Thread Context Data Task":
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.getServiceProviders(ThreadContextDataInjector.java:85)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.initServiceProviders(ThreadContextDataInjector.java:73)
> at
> org.apache.logging.log4j.core.LoggerContext$ThreadContextDataTask.run(LoggerContext.java:785)
> at java.lang.Thread.run(Thread.java:748)
> "main":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000773e77ae8> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.initServiceProviders(ThreadContextDataInjector.java:70)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.getProviders(ThreadContextDataInjector.java:285)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.access$000(ThreadContextDataInjector.java:55)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector$ForDefaultThreadContextMap.(ThreadContextDataInjector.java:108)
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createDefaultInjector(ContextDataInjectorFactory.java:91)
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createInjector(ContextDataInjectorFactory.java:71)
> at
> org.apache.logging.log4j.core.impl.Log4jLogEvent.(Log4jLogEvent.java:58)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:643)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
> at org.apache.logging
[jira] [Resolved] (LOG4J2-3333) Classloader deadlock in ThreadContextDataInjector
[
https://issues.apache.org/jira/browse/LOG4J2-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak resolved LOG4J2-.
--
Resolution: Fixed
I've resolved the issue on release-2.x for 2.17.2 – please verify from a
snapshot and close the issue when you're satisfied.
> Classloader deadlock in ThreadContextDataInjector
> -
>
> Key: LOG4J2-
> URL: https://issues.apache.org/jira/browse/LOG4J2-
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.17.1
>Reporter: Ryan Schmitt
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.2
>
>
> I ran into a deadlock involving {{ThreadContextDataInjector}} and the "Thread
> Context Data Task" background thread. The basic idea is that the "main"
> thread holds the classloader lock (since log4j2 is initialized during class
> loading, as a rule) and tries to acquire the provider lock, while the "Thread
> Context Data Task" thread holds the provider lock and tries to load classes:
> {code}
> Found one Java-level deadlock:
> =
> "Thread Context Data Task":
> waiting to lock monitor 0x7fde50835958 (object 0x00077bbf51c8, a
> org.powermock.core.classloader.MockClassLoader),
> which is held by "main"
> "main":
> waiting for ownable synchronizer 0x000773e77ae8, (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "Thread Context Data Task"
> Java stack information for the threads listed above:
> ===
> "Thread Context Data Task":
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.getServiceProviders(ThreadContextDataInjector.java:85)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.initServiceProviders(ThreadContextDataInjector.java:73)
> at
> org.apache.logging.log4j.core.LoggerContext$ThreadContextDataTask.run(LoggerContext.java:785)
> at java.lang.Thread.run(Thread.java:748)
> "main":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000773e77ae8> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.initServiceProviders(ThreadContextDataInjector.java:70)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.getProviders(ThreadContextDataInjector.java:285)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector.access$000(ThreadContextDataInjector.java:55)
> at
> org.apache.logging.log4j.core.impl.ThreadContextDataInjector$ForDefaultThreadContextMap.(ThreadContextDataInjector.java:108)
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createDefaultInjector(ContextDataInjectorFactory.java:91)
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createInjector(ContextDataInjectorFactory.java:71)
> at
> org.apache.logging.log4j.core.impl.Log4jLogEvent.(Log4jLogEvent.java:58)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:643)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:196)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:137)
> at
> org.apache.logging.log
[jira] [Closed] (LOG4J2-3346) After 2.17.0 upgarde Route appenders with dynamic file writing are not working
[
https://issues.apache.org/jira/browse/LOG4J2-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak closed LOG4J2-3346.
Resolution: Duplicate
> After 2.17.0 upgarde Route appenders with dynamic file writing are not
> working
> ---
>
> Key: LOG4J2-3346
> URL: https://issues.apache.org/jira/browse/LOG4J2-3346
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.0
>Reporter: Nick Kom
>Assignee: Carter Kozak
>Priority: Major
>
> We switched from the version 2.11.1 to 2.17.0 and writing to separate files
> stopped working. Configuration log4j:
> {code:xml}
>
> ...
>
>
>
> fileName="${logPath}/task-${ctx:V_PID}.log"
>
> filePattern="${logArchPath}/task-${ctx:V_PID}-${archFile}"
> ignoreExceptions="false">
>
>
>
>
>
>
>
> ...
>
>
>
>
>
> {code}
> In code we use Slf4J logger (org.slf4j.Logger) and
> org.apache.logging.log4j.ThreadContext :
> {code:java}
> ThreadContext.put("V_PID", pid);
> org.slf4j.Logger logger
> =org.slf4j.LoggerFactory.getLogger(MessageFormat.format(...));
> {code}
> maven dependencies in pom.xml:
> {code:xml}
>
> 1.7.7
> 2.17.0
> ...
>
> org.slf4j
> slf4j-api
> ${slf4j.version}
>
>
> org.apache.logging.log4j
> log4j-slf4j-impl
> ${log4j2.version}
>
>
> org.apache.logging.log4j
> log4j-api
> ${log4j2.version}
>
>
> org.apache.logging.log4j
> log4j-core
> ${log4j2.version}
>
> ...
> {code}
> We use this in our web application which is deployed on Weblogic 12.2.1.0.0
> What can be wrong? Why aren't separate files (task-${ctx:V_PID}.log) created
> in the folder \{logPath}?
> Before library version 2.12.2 (inclusive),it's worked!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] carterkozak commented on a change in pull request #722: LOG4J2-3350: Evaluate configuration property substitutions eagerly
carterkozak commented on a change in pull request #722:
URL: https://github.com/apache/logging-log4j2/pull/722#discussion_r790087262
##
File path:
log4j-core/src/main/java/org/apache/logging/log4j/core/config/Property.java
##
@@ -57,6 +63,14 @@ public String getName() {
return name;
}
+/**
+ * Returns the original raw property value without substitution.
+ * @return the raw value of the property, or null if it is not set.
+ */
+public String getRawValue() {
Review comment:
I'm not thrilled about adding these new methods because they muddy the
waters between the object model and configuration node->plugin api.
Ideally we could add a parameter to the `@PluginElement("Properties") final
Property[] properties` parameter in `PropertiesPlugin` to opt out of all
substitutions when that data is read, allowing us to produce the same behavior.
When I looked into that, it didn't seem like something the plugin system is
built to handle (contextual configuration).
--
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-3343) Add ability to use exclusion pattern filter on Map Resolver keys
[
https://issues.apache.org/jira/browse/LOG4J2-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480325#comment-17480325
]
ASF subversion and git services commented on LOG4J2-3343:
-
Commit 84c04fe7089040e513211fcb1a414c2e6c68fe11 in logging-log4j2's branch
refs/heads/release-2.x from Matt Sicker
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=84c04fe ]
Revert "[LOG4J2-3343] Add excludePattern to JTL maps"
This reverts commit c7906fb9b4ac3f518d2b4256bff3e11422b21fc6.
> Add ability to use exclusion pattern filter on Map Resolver keys
>
>
> Key: LOG4J2-3343
> URL: https://issues.apache.org/jira/browse/LOG4J2-3343
> Project: Log4j 2
> Issue Type: New Feature
> Components: JsonTemplateLayout
>Reporter: Matt Sicker
>Assignee: Matt Sicker
>Priority: Major
> Fix For: 2.17.2
>
>
> Map Resolver currently supports specifying a pattern to filter for allowed
> keys in the map being resolved. I'd like a complementary feature to specify a
> pattern to filter for excluded keys from the map being resolved. It may also
> be beneficial to provide a similar option for excluded keys as full string
> matches rather than always using a pattern.
> For an example use case, suppose I copy request HTTP header names and values
> into the ThreadContext for every request. In Spinnaker microservices, this
> includes custom headers like {{X-Spinnaker-Groups}} which contains a list of
> groups the authenticated user belongs to which are filled in by the Fiat
> microservice (used for integrating authentication and authorization with
> various providers and providing a facade over Spring Security). If I want to
> exclude this header from being logged, I can currently set a negative
> lookahead pattern like {{(?i(?!x-spinnaker-groups))}} which works effectively
> the same, but how many developers like reading regex incantations like these?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3343) Add ability to use exclusion pattern filter on Map Resolver keys
[
https://issues.apache.org/jira/browse/LOG4J2-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480326#comment-17480326
]
ASF subversion and git services commented on LOG4J2-3343:
-
Commit fa56acebdb9f7b09e742502317e62f5adcd18c0a in logging-log4j2's branch
refs/heads/master from Matt Sicker
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=fa56ace ]
Revert "[LOG4J2-3343] Add excludePattern to JTL maps"
This reverts commit 27cac86f7057dd0825803b4643d9111dd7561b2b.
> Add ability to use exclusion pattern filter on Map Resolver keys
>
>
> Key: LOG4J2-3343
> URL: https://issues.apache.org/jira/browse/LOG4J2-3343
> Project: Log4j 2
> Issue Type: New Feature
> Components: JsonTemplateLayout
>Reporter: Matt Sicker
>Assignee: Matt Sicker
>Priority: Major
> Fix For: 2.17.2
>
>
> Map Resolver currently supports specifying a pattern to filter for allowed
> keys in the map being resolved. I'd like a complementary feature to specify a
> pattern to filter for excluded keys from the map being resolved. It may also
> be beneficial to provide a similar option for excluded keys as full string
> matches rather than always using a pattern.
> For an example use case, suppose I copy request HTTP header names and values
> into the ThreadContext for every request. In Spinnaker microservices, this
> includes custom headers like {{X-Spinnaker-Groups}} which contains a list of
> groups the authenticated user belongs to which are filled in by the Fiat
> microservice (used for integrating authentication and authorization with
> various providers and providing a facade over Spring Security). If I want to
> exclude this header from being logged, I can currently set a negative
> lookahead pattern like {{(?i(?!x-spinnaker-groups))}} which works effectively
> the same, but how many developers like reading regex incantations like these?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3343) Add ability to use exclusion pattern filter on Map Resolver keys
[
https://issues.apache.org/jira/browse/LOG4J2-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker resolved LOG4J2-3343.
-
Fix Version/s: (was: 2.17.2)
Resolution: Won't Fix
Closing this as the feature can be done more easily through existing
functionality.
> Add ability to use exclusion pattern filter on Map Resolver keys
>
>
> Key: LOG4J2-3343
> URL: https://issues.apache.org/jira/browse/LOG4J2-3343
> Project: Log4j 2
> Issue Type: New Feature
> Components: JsonTemplateLayout
>Reporter: Matt Sicker
>Assignee: Matt Sicker
>Priority: Major
>
> Map Resolver currently supports specifying a pattern to filter for allowed
> keys in the map being resolved. I'd like a complementary feature to specify a
> pattern to filter for excluded keys from the map being resolved. It may also
> be beneficial to provide a similar option for excluded keys as full string
> matches rather than always using a pattern.
> For an example use case, suppose I copy request HTTP header names and values
> into the ThreadContext for every request. In Spinnaker microservices, this
> includes custom headers like {{X-Spinnaker-Groups}} which contains a list of
> groups the authenticated user belongs to which are filled in by the Fiat
> microservice (used for integrating authentication and authorization with
> various providers and providing a facade over Spring Security). If I want to
> exclude this header from being logged, I can currently set a negative
> lookahead pattern like {{(?i(?!x-spinnaker-groups))}} which works effectively
> the same, but how many developers like reading regex incantations like these?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3354) Publish an SBOM with Log4j
[
https://issues.apache.org/jira/browse/LOG4J2-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480336#comment-17480336
]
Matt Sicker commented on LOG4J2-3354:
-
Something like this in the parent pom might work, though I get an error when
trying to run "mvn clean install", but not when I run "mvn install".
{code}
org.cyclonedx
cyclonedx-maven-plugin
2.5.3
false
false
false
log4j-api-java9
log4j-core-its
log4j-core-java9
log4j-distribution
log4j-osgi
log4j-samples
log4j-samples-flume-common
log4j-samples-flume-remote
log4j-samples-flume-embedded
log4j-samples-configuration
log4j-samples-loggerProperties
log4j-spring-cloud-config-samples
log4j-spring-cloud-config-sample-server
package
makeAggregateBom
{code}
> Publish an SBOM with Log4j
> --
>
> Key: LOG4J2-3354
> URL: https://issues.apache.org/jira/browse/LOG4J2-3354
> Project: Log4j 2
> Issue Type: New Feature
> Components: Build
>Reporter: Matt Sicker
>Priority: Major
>
> Log4j should publish a software bill of materials (SBOM) on each release to
> enable end users to more easily discover the versions of both Log4j and
> related dependencies are in use in their software. [Sonatype has a blog post
> explaining what SBOM
> is|https://blog.sonatype.com/what-is-a-software-bill-of-materials], and OWASP
> has a tool called [CycloneDX|https://cyclonedx.org/] which has a [Maven
> plugin|https://github.com/CycloneDX/cyclonedx-maven-plugin] which we could
> potentially use for this.
> Open questions:
> * Do SBOM files get published to Maven Central as additional artifacts?
> * Do we add SBOM files to the source and binary archives?
> * Should the generated SBOM only include required dependencies? This last
> bit is less obvious since we're a library, so the end user can always
> override their full dependency tree when building their app.
> More options for generating an SBOM:
> * [https://github.com/opensbom-generator/spdx-sbom-generator]
> * [https://dependencytrack.org|https://dependencytrack.org/] - integrates
> with CycloneDX (all OWASP tools)
> *
> [https://github.com/AevaOnline/supply-chain-synthesis/blob/main/documents/list-projects.md]
> - larger list of relevant supply chain security tooling
> More information about what an SBOM is, related standards, etc.:
> [https://www.ntia.gov/SBOM]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3037) Add methods for logging untrusted arguments
[
https://issues.apache.org/jira/browse/LOG4J2-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480342#comment-17480342
]
Matt Sicker commented on LOG4J2-3037:
-
This still seems relevant, though with the message lookup thing already being
fixed, I'm not sure if there's much that can be done with user input for things
like PatternLayout (maybe removing newlines?).
> Add methods for logging untrusted arguments
> ---
>
> Key: LOG4J2-3037
> URL: https://issues.apache.org/jira/browse/LOG4J2-3037
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Reporter: Marcono1234
>Priority: Major
>
> While LOG4J2-2511 would prevent log injection, it appears Log4j 2 does not
> provide any safe means for logging untrusted (potentially malicious) data
> without it messing with the output. Simply not logging such data is often not
> an option, because it is important to understand which steps an adversary
> took.
> It would therefore be good if Log4j 2 provided logging methods for untrusted
> data, which escape any potentially malicious input.
> Adding such methods to {{Logger}} is probably not an option because it would
> further bloat the API, making it less usable. However, maybe such methods
> could be added to {{LogBuilder}}.
> The following API would allow this (and could unrelated to this request also
> support logging primitive arguments without boxing):
> {code}
> interface LogBuilder {
> interface MessageWithArgsBuilder {
> MessageWithArgsBuilder withArg(Object arg);
> MessageWithArgsBuilder withUntrustedArg(Object arg);
> void log();
> }
> MessageWithArgsBuilder withMessage(String messageTemplate);
> }
> {code}
> The usage would then look like this:
> {code}
> logger.atWarn()
> .withMessage("User provided invalid argument {} to service {}")
> .withUntrustedArg(arg)
> .withArg(service)
> .log();
> {code}
> The implementation of {{withUntrustedArg}} would then only allow a subset of
> the ASCII chars, encasing the argument with double quotes {{"}}, and
> replacing any non allowed characters with their Unicode escape sequence
> {{\u}}, adding to any existing escape sequences an additional {{u}}, e.g.
> {noformat}
> test" \u1234
> {noformat}
> would become
> {noformat}"test\u0022 \uu1234"
> {noformat}
> in the output.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[CI][UNSTABLE] Logging/log4j/release-2.x#796 has test failures
BUILD UNSTABLE Build URL https://ci-builds.apache.org/job/Logging/job/log4j/job/release-2.x/796/ Project: release-2.x Date of build: Sat, 22 Jan 2022 03:41:52 + Build duration: 1 hr 9 min and counting JUnit Tests Name: (root) Failed: 0 test(s), Passed: 1420 test(s), Skipped: 0 test(s), Total: 1420 test(s)Name: liquibase.ext.logging.log4j2 Failed: 0 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 10 test(s)Name: org.apache.log4j Failed: 0 test(s), Passed: 188 test(s), Skipped: 0 test(s), Total: 188 test(s)Name: org.apache.log4j.bridge Failed: 0 test(s), Passed: 4 test(s), Skipped: 0 test(s), Total: 4 test(s)Name: org.apache.log4j.config Failed: 0 test(s), Passed: 130 test(s), Skipped: 0 test(s), Total: 130 test(s)Name: org.apache.log4j.layout Failed: 0 test(s), Passed: 4 test(s), Skipped: 0 test(s), Total: 4 test(s)Name: org.apache.log4j.pattern Failed: 0 test(s), Passed: 16 test(s), Skipped: 0 test(s), Total: 16 test(s)Name: org.apache.logging.log4j Failed: 0 test(s), Passed: 488 test(s), Skipped: 2 test(s), Total: 490 test(s)Name: org.apache.logging.log4j.cassandra Failed: 0 test(s), Passed: 2 test(s), Skipped: 0 test(s), Total: 2 test(s)Name: org.apache.logging.log4j.configuration Failed: 0 test(s), Passed: 2 test(s), Skipped: 0 test(s), Total: 2 test(s)Name: org.apache.logging.log4j.core Failed: 0 test(s), Passed: 196 test(s), Skipped: 2 test(s), Total: 198 test(s)Name: org.apache.logging.log4j.core.appender Failed: 0 test(s), Passed: 238 test(s), Skipped: 12 test(s), Total: 250 test(s)Name: org.apache.logging.log4j.core.appender.db Failed: 0 test(s), Passed: 26 test(s), Skipped: 0 test(s), Total: 26 test(s)Name: org.apache.logging.log4j.core.appender.db.jdbc Failed: 0 test(s), Passed: 80 test(s), Skipped: 0 test(s), Total: 80 test(s)Name: org.apache.logging.log4j.core.appender.db.jpa Failed: 0 test(s), Passed: 24 test(s), Skipped: 0 test(s), Total: 24 test(s)Name: org.apache.logging.log4j.core.appender.db.jpa.converter Failed: 0 test(s), Passed: 88 test(s), Skipped: 0 test(s), Total: 88 test(s)Name: org.apache.logging.log4j.core.appender.mom Failed: 0 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 8 test(s)Name: org.apache.logging.log4j.core.appender.mom.jeromq Failed: 1 test(s), Passed: 7 test(s), Skipped: 0 test(s), Total: 8 test(s)Failed: org.apache.logging.log4j.core.appender.mom.jeromq.JeroMqAppenderTest.testClientServerName: org.apache.logging.log4j.core.appender.mom.kafka Failed: 0 test(s), Passed: 16 test(s), Skipped: 0 test(s), Total: 16 test(s)Name: org.apache.logging.log4j.core.appender.nosql Failed: 0 test(s), Passed: 18 test(s), Skipped: 0 test(s), Total: 18 test(s)Name: org.apache.logging.log4j.core.appender.rewrite Failed: 0 test(s), Passed: 14 test(s), Skipped: 0 test(s), Total: 14 test(s)Name: org.apache.logging.log4j.core.appender.rolling Failed: 0 test(s), Passed: 205 test(s), Skipped: 2 test(s), Total: 207 test(s)Name: org.apache.logging.log4j.core.appender.rolling.action Failed: 0 test(s), Passed: 184 test(s), Skipped: 0 test(s), Total: 184 test(s)Name: org.apache.logging.log4j.core.appender.routing Failed: 0 test(s), Passed: 26 test(s), Skipped: 0 test(s), Total: 26 test(s)Name: org.apache.logging.log4j.core.async Failed: 0 test(s), Passed: 160 test(s), Skipped: 0 test(s), Total: 160 test(s)Name: org.apache.logging.log4j.core.config Failed: 0 test(s), Passed: 344 test(s), Skipped: 2 test(s), Total: 346 test(s)Name: org.apache.logging.log4j.core.config.arbiters Failed: 0 test(s), Passed: 12 test(s), Skipped: 0 test(s), Total: 12 test(s)Name: org.apache.logging.log4j.core.config.builder Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: org.apache.logging.log4j.core.config.plugins.convert Failed: 0 test(s), Passed: 12 test(s), Skipped: 0 test(s), Total: 12 test(s)Name: org.apache.logging.log4j.core.config.plugins.processor Failed: 0 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 10 test(s)Name: org.apache.logging.log4j.core.config.plugins.util Failed: 0 test(s), Passed: 52 test(s), Skipped: 0 test(s), Total: 52 test(s)Name: org.apache.logging.log4j.core.config.plugins.validation.validators Failed: 0 test(s), Passed: 30 test(s), Skipped: 0 test(s), Total: 30 test(s)Name: org.apache.logging.log4j.core.config.properties Failed: 0 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 8 test(s)Name: org.apache.logging.log4j.core.config.xml Failed: 0 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 10 test(s)Name: org.apache.logging.log4j.core.filter Failed: 0 test(s), Passed: 100 test(s), Skipped: 0 test(s), Total: 100 test(s)Name: org.apache.logging.log4j.core.impl Failed: 0 test(s), Passed: 302 test(s), Skipped: 0 test(s), Total: 302 test(s)Name: org.apache.logging.log4j.core.jackson Failed: 0 test(s), Passed: 22 test(s), Skipped: 0 test(s), Total: 22 test(s)Name: org.apache.logging.log4j.core.jmx Failed: 0 test(s), Passed: 20 test(s), Skipped: 0 test(s), Total: 20 test(s)
[jira] [Updated] (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
]
Tukesh updated LOG4J2-3359:
---
Attachment: bug_fac_pri2.pcapng.pcap
> 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: 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
>Priority: Blocker
> Attachments: bug_fac_pri.pcapng, bug_fac_pri2.pcapng.pcap
>
>
> 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-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
]
Tukesh updated LOG4J2-3359:
---
Attachment: LoggerExample.java
> 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: 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
>Priority: Blocker
> Attachments: LoggerExample.java, bug_fac_pri.pcapng,
> bug_fac_pri2.pcapng.pcap
>
>
> 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-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
]
Tukesh updated LOG4J2-3359:
---
Attachment: log4j.properties
> 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: 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
>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-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
]
Tukesh updated LOG4J2-3359:
---
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
was:
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
> 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
>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] [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=17480368#comment-17480368
]
Tukesh commented on LOG4J2-3359:
[~ggregory] - I tried using 2.17.2-SNAPSHOT build still issue is reproducible.
log4j-1.2-api-2.17.2-20220122.044156-95.jar
log4j-api-2.17.2-20220122.044156-91.jar
log4j-core-2.17.2-20220122.044156-88.jar
> 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
>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)
