[jira] [Commented] (LOG4J2-3312) Bridge does not convert properties
[
https://issues.apache.org/jira/browse/LOG4J2-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472119#comment-17472119
]
Gary D. Gregory commented on LOG4J2-3312:
-
We are all volunteers with different availability and priorities, so it's hard
to tell exactly when the next release will be available. In the meantime, you
should test the latest snapshot build to make sure all of your use cases work.
> Bridge does not convert properties
> --
>
> Key: LOG4J2-3312
> URL: https://issues.apache.org/jira/browse/LOG4J2-3312
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
>Reporter: Enrico Scantamburlo
>Priority: Major
> Fix For: 2.17.2
>
>
> I have tried to migrate my application from Log4j 1.2.17 to the latest.
> The first problem was that the class FileAppender was not inside the bridge
> jar.
> I resolved the issue copying the java file from the old version.
> Now I found out the that the properties that are in the log4j.properties are
> not converted when passed to my custom appeder.
> Like
> {{log4j.appender.FULL.file = ${user.home}/${user.name}}}
> is not expanded to {{/home/escantam/escantam}}
> The properties file is found and loaded but the properties no expanded when
> the setFile method is called.
> Is this a bug?
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3326) Log4j 1.2 bridge not parsing filters from Properties configuration properly
[
https://issues.apache.org/jira/browse/LOG4J2-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LOG4J2-3326.
-
Fix Version/s: 2.17.2
Resolution: Fixed
> Log4j 1.2 bridge not parsing filters from Properties configuration properly
> ---
>
> Key: LOG4J2-3326
> URL: https://issues.apache.org/jira/browse/LOG4J2-3326
> Project: Log4j 2
> Issue Type: Improvement
> Components: log4j 1.2 emulation
>Affects Versions: 2.17.1
>Reporter: Benjamin Röhl
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> h2. Status Quo
> The log4j 1.2 bridge gives backward-compatiblilty for the following filters,
> based on [migration
> documentation|https://logging.apache.org/log4j/2.x/manual/migration.html]:
> {code:java}
> Supported Filters include: DenyAllFilter, LevelMatchFilter, LevelRangeFilter,
> StringMatchFilter.{code}
> h2. Problem
> The filters' parameters are not parsed properly, and instead fallback to
> default configuration for filter.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3326) Log4j 1.2 bridge not parsing filters from Properies configuration properly
[
https://issues.apache.org/jira/browse/LOG4J2-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory reassigned LOG4J2-3326:
---
Assignee: Gary D. Gregory
> Log4j 1.2 bridge not parsing filters from Properies configuration properly
> --
>
> Key: LOG4J2-3326
> URL: https://issues.apache.org/jira/browse/LOG4J2-3326
> Project: Log4j 2
> Issue Type: Improvement
> Components: log4j 1.2 emulation
>Affects Versions: 2.17.1
>Reporter: Benjamin Röhl
>Assignee: Gary D. Gregory
>Priority: Major
>
> h2. Status Quo
> The log4j 1.2 bridge gives backward-compatiblilty for the following filters,
> based on [migration
> documentation|https://logging.apache.org/log4j/2.x/manual/migration.html]:
> {code:java}
> Supported Filters include: DenyAllFilter, LevelMatchFilter, LevelRangeFilter,
> StringMatchFilter.{code}
> h2. Problem
> The filters' parameters are not parsed properly, and instead fallback to
> default configuration for filter.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3326) Log4j 1.2 bridge not parsing filters from Properties configuration properly
[
https://issues.apache.org/jira/browse/LOG4J2-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LOG4J2-3326:
Summary: Log4j 1.2 bridge not parsing filters from Properties configuration
properly (was: Log4j 1.2 bridge not parsing filters from Properies
configuration properly)
> Log4j 1.2 bridge not parsing filters from Properties configuration properly
> ---
>
> Key: LOG4J2-3326
> URL: https://issues.apache.org/jira/browse/LOG4J2-3326
> Project: Log4j 2
> Issue Type: Improvement
> Components: log4j 1.2 emulation
>Affects Versions: 2.17.1
>Reporter: Benjamin Röhl
>Assignee: Gary D. Gregory
>Priority: Major
>
> h2. Status Quo
> The log4j 1.2 bridge gives backward-compatiblilty for the following filters,
> based on [migration
> documentation|https://logging.apache.org/log4j/2.x/manual/migration.html]:
> {code:java}
> Supported Filters include: DenyAllFilter, LevelMatchFilter, LevelRangeFilter,
> StringMatchFilter.{code}
> h2. Problem
> The filters' parameters are not parsed properly, and instead fallback to
> default configuration for filter.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3323) Breaking change in AbstractManager
[
https://issues.apache.org/jira/browse/LOG4J2-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471545#comment-17471545
]
Gary D. Gregory commented on LOG4J2-3323:
-
IMO, this is too deep in the log4j core to be considered part of the public
API. Call sites should adapt to the current API.
> Breaking change in AbstractManager
> --
>
> Key: LOG4J2-3323
> URL: https://issues.apache.org/jira/browse/LOG4J2-3323
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Ryan Schmitt
>Priority: Major
>
> Due to LOG4J2-1540, a breaking change was made to a protected constructor in
> a public class. The fix is to add a new constructor that has the old
> signature: {{protected AbstractManager(final String name)}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3321) Log4j complains invalid element or attribute "JsonTemplateLayout"
[
https://issues.apache.org/jira/browse/LOG4J2-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470979#comment-17470979
]
Gary D. Gregory commented on LOG4J2-3321:
-
There are only downsides to shading IMO, don't do it.
> Log4j complains invalid element or attribute "JsonTemplateLayout"
> -
>
> Key: LOG4J2-3321
> URL: https://issues.apache.org/jira/browse/LOG4J2-3321
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Vibin Ramakrishnan
>Priority: Critical
> Attachments: log4j2.xml
>
>
> A configuration in jetty app using log4j2.xml (use slf4j as logger)as below -
> {{}}
> Throws following error during initialization -
> main ERROR RollingRandomAccessFile contains an invalid element or attribute
> "JsonTemplateLayout"
> dependencies added are:
> slf4j-api - 1.7.32
> jcl-over-slf4j - 1.7.32
> log4j-api - 2.17.1
> log4j-core - 2.17.1
> log4j-layout-template-json - 2.17.1
> log4j-slf4j-impl - 2.17.1
>
> *Any help/advise on this really appreciated, Thanks.*
> Find the entire log4j DEBUG log:
> {code:java}
> 2022-01-06 14:35:44,536 main DEBUG null null initializing configuration
> XmlConfiguration[location=jar:file:/usr/local/xxx/appxx.jar!/log4j2.xml]
> 2022-01-06 14:35:44,545 main DEBUG Installed 1 script engine
> 2022-01-06 14:35:45,016 main DEBUG Oracle Nashorn version: 1.8.0_292,
> language: ECMAScript, threading: Not Thread Safe, compile: true, names:
> [nashorn, Nashorn, js, JS, JavaScript, javascript, ECMAScript, ecmascript],
> factory class: jdk.nashorn.api.scripting.NashornScriptEngineFactory
> 2022-01-06 14:35:45,017 main DEBUG PluginManager 'Core' found 127 plugins
> 2022-01-06 14:35:45,020 main DEBUG PluginManager 'Level' found 0 plugins
> 2022-01-06 14:35:45,036 main DEBUG Building Plugin[name=property,
> class=org.apache.logging.log4j.core.config.Property].
> 2022-01-06 14:35:45,063 main DEBUG PluginManager 'TypeConverter' found 26
> plugins
> 2022-01-06 14:35:45,086 main DEBUG createProperty(name="PULSAR_APP_NAME",
> value="ace")
> 2022-01-06 14:35:45,086 main DEBUG Building Plugin[name=property,
> class=org.apache.logging.log4j.core.config.Property].
> 2022-01-06 14:35:45,088 main DEBUG createProperty(name="PULSAR_LOG_DIR",
> value="/pulsar-logs-root/ace")
> 2022-01-06 14:35:45,089 main DEBUG Building Plugin[name=property,
> class=org.apache.logging.log4j.core.config.Property].
> 2022-01-06 14:35:45,090 main DEBUG createProperty(name="MESOS_TASK_ID",
> value="unknown-task.${env:PULSAR_APP_NAME}.20220106143545090")
> 2022-01-06 14:35:45,090 main DEBUG Building Plugin[name=properties,
> class=org.apache.logging.log4j.core.config.PropertiesPlugin].
> 2022-01-06 14:35:45,098 main DEBUG
> configureSubstitutor(={PULSAR_APP_NAME=ace,
> PULSAR_LOG_DIR=/pulsar-logs-root/ace,
> MESOS_TASK_ID=unknown-task.${env:PULSAR_APP_NAME}.20220106143545090},
> Configuration(jar:file:/usr/local/xxx/app.jar!/log4j2.xml))
> 2022-01-06 14:35:45,100 main DEBUG PluginManager 'Lookup' found 16 plugins
> 2022-01-06 14:35:45,128 main DEBUG Building Plugin[name=layout,
> class=org.apache.logging.log4j.core.layout.PatternLayout].
> 2022-01-06 14:35:45,135 main DEBUG
> PatternLayout$Builder(pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} -
> %msg%n", PatternSelector=null,
> Configuration(jar:file:/usr/local/xxx/ace.jar!/log4j2.xml), Replace=null,
> charset="null", alwaysWriteExceptions="null", disableAnsi="null",
> noConsoleNoAnsi="null", header="null", footer="null")
> 2022-01-06 14:35:45,136 main DEBUG PluginManager 'Converter' found 45 plugins
> 2022-01-06 14:35:45,137 main DEBUG Building Plugin[name=appender,
> class=org.apache.logging.log4j.core.appender.ConsoleAppender].
> 2022-01-06 14:35:45,149 main DEBUG
> ConsoleAppender$Builder(target="SYSTEM_OUT", follow="null", direct="null",
> bufferedIo="null", bufferSize="null", immediateFlush="null",
> ignoreExceptions="null", PatternLayout(%d{HH:mm:ss.SSS} [%t] %-5level
> %logger{36} - %msg%n), name="Console",
> Configuration(jar:file:/usr/local/xxx/ace.jar!/log4j2.xml), Filter=null, ={})
> 2022-01-06 14:35:45,152 main DEBUG Starting OutputStreamManager
> SYSTEM_OUT.false.false
> 2022-01-06 14:35:45,152 main DEBUG Building
> Plugin[name=OnStartupTriggeringPolicy,
> class=org.apache.logging.log4j.core.appender.rolling.OnStartupTriggeringPolicy].
> 2022-01-06 14:35:45,157 main DEBUG createPolicy(minSize="1")
> 2022-01-06 14:35:45,158 main DEBUG Building
> Plugin[name=SizeBasedTriggeringPolicy,
> class=org.apache.logging.log4j.core.appender.rolling.SizeBasedTriggeringPolicy].
> 2022-01-06 14:35:45,159 main DEBUG createPolicy(size="10MB")
> 2022-01-06 14:35:45,163 main DEBUG Building
> Plugin[name=TimeBasedTriggeringPolicy,
> class=org.apache.logging.log4j.core.appender.rolling.TimeBasedTriggeringPolicy].
>
[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=17470591#comment-17470591
]
Gary D. Gregory commented on LOG4J2-3298:
-
I agree with [~vy] : We should direct users to use the Log4j feature that best
fits the use case like MDC, MapMessage, and ObjectMessage, as oppose to trying
to retrofit this behavior into JTL. (I use MapMessage at work quite nicely for
this kind of behavior.)
> 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 JSON string is pushed to ThreadContext, 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}
> {
> "instant": {
> "epochSecond": 1640632561,
> "nanoOfSecond": 287515000
> },
> "thread": "main",
> "level": "INFO",
> "loggerName": "io.hyte.dev.c.ServiceC",
> "message": "Doing way other thing with order: 3235",
> "contextStack": ["{ \"Task\" {\
> "id\":\"3623\", \"orderId\": "1345\", \"taskStatus\":null,
> \"startDateTime\": \"2021-12-27T06:07:01.363232-06:00\", \"endDateTime\":
> \"2021-12-27T17:10:01.365430-06:00\"} }",
> "{ \"Order\" { \"id\": \"3235\", \"customerName\": \"Customer-8780\",
> \"createdDate\" :\"2021-12-27T08:55:01.366162-06:00\"} }"],
>
> "endOfBatch": false,
> "loggerFqcn": "org.apache.logging.log4j.spi.AbstractLogger",
> "threadId": 1,
> "threadPriority": 5
> }
> {noformat}
> Desired output:
> {noformat}
> {
> "instant": {
> "epochSecond": 1640632561,
> "nanoOfSecond": 287515000
> },
> "thread": "main",
> "level": "INFO",
> "loggerName": "io.hyte.dev.c.ServiceC",
> "message": "Doing way other thing with order: 3235",
> "contextStack": [{ "Task" { "id": "3623", "orderId": "1345",
> "taskStatus":null, "startDateTime": "2021-12-27T06:07:01.363232-06:00",
> "endDateTime": "2021-12-27T17:10:01.365430-06:00"} }",
>{ "Order" { "id": "3235", "customerName": "Customer-8780",
> "createdDate": "2021-12-27T08:55:01.366162-06:00"} }],
> "endOfBatch": false,
> "loggerFqcn": "org.apache.logging.log4j.spi.AbstractLogger",
> "threadId": 1,
> "threadPriority": 5
> }
> {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. Prefix {noformat}{noesc}{noformat} or other marker macro to instruct
> JSONWriter skip escaping for that string
> {noformat}
> ThreadContext.push("{noesc}" + JSONString(myModelObject));
> {noformat}
> _or_
> 2. Alternatively, the JSONWriter could invoke a JSONReader on the marked
> payload and then ensure that fields are properly escaped, but not escape the
> whole payload. This would involve add'l cycles, but remove the pre-req and
> potential hazard of user calling with malformed JSON
> Developer codes:
> {noformat}
> ThreadContext.push("{json}" + JSONString(myModelObject));
> ...
> JSONWriter detects prefix {json}.. then invokes JSONReader on the payload
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3312) Bridge does not convert properties
[
https://issues.apache.org/jira/browse/LOG4J2-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LOG4J2-3312.
-
Fix Version/s: 2.17.2
Resolution: Fixed
> Bridge does not convert properties
> --
>
> Key: LOG4J2-3312
> URL: https://issues.apache.org/jira/browse/LOG4J2-3312
> Project: Log4j 2
> Issue Type: Bug
> Components: log4j 1.2 emulation
>Affects Versions: 2.17.1
>Reporter: Enrico Scantamburlo
>Priority: Major
> Fix For: 2.17.2
>
>
> I have tried to migrate my application from Log4j 1.2.17 to the latest.
> The first problem was that the class FileAppender was not inside the bridge
> jar.
> I resolved the issue copying the java file from the old version.
> Now I found out the that the properties that are in the log4j.properties are
> not converted when passed to my custom appeder.
> Like
> {{log4j.appender.FULL.file = ${user.home}/${user.name}}}
> is not expanded to {{/home/escantam/escantam}}
> The properties file is found and loaded but the properties no expanded when
> the setFile method is called.
> Is this a bug?
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3319) Add minimal support for log4j 1.2 API bundle usage in Eclipse IDE
[
https://issues.apache.org/jira/browse/LOG4J2-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469414#comment-17469414
]
Gary D. Gregory commented on LOG4J2-3319:
-
Does Eclipse 4.22 fix this?
Do we have to build 1.2 bridge bundle as a fragment or would it work if we
built it as a normal bundle?
> Add minimal support for log4j 1.2 API bundle usage in Eclipse IDE
> -
>
> Key: LOG4J2-3319
> URL: https://issues.apache.org/jira/browse/LOG4J2-3319
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core, log4j 1.2 emulation, OSGi
>Affects Versions: 2.12.4
>Reporter: Benjamin Röhl
>Priority: Major
>
> h2. Status Quo
> The "log4j core" and "log4j 1.2 api" library (and others as well) are build
> as bundle.
> The compatibility library is build as fragment.
> h2. Problem
> Using the log4j core and 1.2 api library in Eclipse-runtime (via [target
> platform|https://wiki.eclipse.org/PDE/Target_Definitions]) does not properly
> work out, since the _1.2 api_ fragment bundle is extending the _core_
> bundle's api, by declaring extra _Export-Packages_ statements for log4j 1.2
> api.
> Unfortunately Eclipse is not capable of resolving those extra added API (via
> {_}Export-Packages{_}) from a fragement, even though at runtime it is
> supposed to work.
> h2. Solution Proposal
> Add the following bundle manifest header to _core_ bundle, to support the
> extra added API by the _1.2 api_ fragement bundle:
> {code:java}
> Eclipse-ExtensibleAPI: true{code}
> Please see _The Eclipse-ExtensibleAPI Header_ section of Eclipse's [Platform
> Plugin-In Developer
> Guide|https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fbundle_manifest.html]
> documentation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3319) Add minimal support for log4j 1.2 API bundle usage in Eclipse IDE
[
https://issues.apache.org/jira/browse/LOG4J2-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469270#comment-17469270
]
Gary D. Gregory commented on LOG4J2-3319:
-
What version of Eclipse are you using?
> Add minimal support for log4j 1.2 API bundle usage in Eclipse IDE
> -
>
> Key: LOG4J2-3319
> URL: https://issues.apache.org/jira/browse/LOG4J2-3319
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core, log4j 1.2 emulation, OSGi
>Affects Versions: 2.12.4
>Reporter: Benjamin Röhl
>Priority: Major
>
> h2. Status Quo
> The "log4j core" and "log4j 1.2 api" library (and others as well) are build
> as bundle.
> The compatibility library is build as fragment.
> h2. Problem
> Using the log4j core and 1.2 api library in Eclipse-runtime (via [target
> platform|https://wiki.eclipse.org/PDE/Target_Definitions]) does not properly
> work out, since the _1.2 api_ fragment bundle is extending the _core_
> bundle's api, by declaring extra _Export-Packages_ statements for log4j 1.2
> api.
> Unfortunately Eclipse is not capable of resolving those extra added API (via
> {_}Export-Packages{_}) from a fragement, even though at runtime it is
> supposed to work.
> h2. Solution Proposal
> Add the following bundle manifest header to _core_ bundle, to support the
> extra added API by the _1.2 api_ fragement bundle:
> {code:java}
> Eclipse-ExtensibleAPI: true{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work stopped] (LOG4J2-3316) Log4j 1.2 bridge should ignore case in properties file keys
[
https://issues.apache.org/jira/browse/LOG4J2-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on LOG4J2-3316 stopped by Gary D. Gregory.
---
> Log4j 1.2 bridge should ignore case in properties file keys
> ---
>
> Key: LOG4J2-3316
> URL: https://issues.apache.org/jira/browse/LOG4J2-3316
> Project: Log4j 2
> Issue Type: Improvement
> Components: log4j 1.2 emulation
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
>
> Log4j 1.2 bridge should ignore case in properties file keys.
> This will allow both of these styles to work:
> log4j.appender.FILE_APPENDER.file=${java.io.tmpdir}/${hadoop.log.file}
> log4j.appender.FILE_APPENDER.File=${java.io.tmpdir}/${hadoop.log.file}
> Notice the "file" vs. "File"
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3316) Log4j 1.2 bridge should ignore case in properties file keys
[
https://issues.apache.org/jira/browse/LOG4J2-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LOG4J2-3316.
-
Fix Version/s: 2.17.2
Resolution: Fixed
> Log4j 1.2 bridge should ignore case in properties file keys
> ---
>
> Key: LOG4J2-3316
> URL: https://issues.apache.org/jira/browse/LOG4J2-3316
> Project: Log4j 2
> Issue Type: Improvement
> Components: log4j 1.2 emulation
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> Log4j 1.2 bridge should ignore case in properties file keys.
> This will allow both of these styles to work:
> log4j.appender.FILE_APPENDER.file=${java.io.tmpdir}/${hadoop.log.file}
> log4j.appender.FILE_APPENDER.File=${java.io.tmpdir}/${hadoop.log.file}
> Notice the "file" vs. "File"
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3281) Log4j 1.2 bridge PropertiesConfiguration.buildAppender not adding filters to custom appender
[
https://issues.apache.org/jira/browse/LOG4J2-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LOG4J2-3281:
Summary: Log4j 1.2 bridge PropertiesConfiguration.buildAppender not adding
filters to custom appender (was: PropertiesConfiguration.buildAppender not
adding filters to custom appender)
> Log4j 1.2 bridge PropertiesConfiguration.buildAppender not adding filters to
> custom appender
>
>
> Key: LOG4J2-3281
> URL: https://issues.apache.org/jira/browse/LOG4J2-3281
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
>Affects Versions: 2.17.1, 2.17.0
>Reporter: Fábio Constantino
>Priority: Blocker
> Fix For: 2.17.2
>
>
> When building an appender, the _parseAppenderFilters_ method correctly finds
> my custom filter configuration in the properties file, builds it and returns
> it, but the caller ({_}buildAppender{_} method) does nothing with it
> resulting in the appender not having any filters added to it.
>
> This is related to the linked issue -
> [LOG4J2-3247|https://issues.apache.org/jira/browse/LOG4J2-3247] - where the
> scenario is the same (properties file config):
> {code:java}
> log4j1.compatibility=true
> log4j.appender.LOG_REQUEST_START_DB=my.appender.class
> log4j.appender.LOG_REQUEST_START_DB.filter.ID=my.filter.class {code}
> the Filter class I'm working with is the following:
> {code:java}
> import org.apache.log4j.spi.Filter;
> import org.apache.log4j.spi.LoggingEvent;
> public class MonitorFilter extends Filter {
> @Override
> public int decide(LoggingEvent event) {
> String requestId = (String)event.getMDC("requestId");
> if (StringHelper.isNullOrEmpty(requestId))
> return DENY;
>
> if
> (!MonitorScriptManager.getInstance().getMonitorScript().filter(event))
> return DENY;
>
> return ACCEPT;
> }
> } {code}
> I am using the following log4j dependencies:
> {code:java}
>
> org.apache.logging.log4j
> log4j-core
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-api
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-1.2-api
> 2.17.0
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (LOG4J2-3316) Log4j 1.2 bridge should ignore case in properties file keys
Gary D. Gregory created LOG4J2-3316:
---
Summary: Log4j 1.2 bridge should ignore case in properties file
keys
Key: LOG4J2-3316
URL: https://issues.apache.org/jira/browse/LOG4J2-3316
Project: Log4j 2
Issue Type: Improvement
Components: log4j 1.2 emulation
Reporter: Gary D. Gregory
Assignee: Gary D. Gregory
Log4j 1.2 bridge should ignore case in properties file keys.
This will allow both of these styles to work:
log4j.appender.FILE_APPENDER.file=${java.io.tmpdir}/${hadoop.log.file}
log4j.appender.FILE_APPENDER.File=${java.io.tmpdir}/${hadoop.log.file}
Notice the "file" vs. "File"
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work started] (LOG4J2-3316) Log4j 1.2 bridge should ignore case in properties file keys
[
https://issues.apache.org/jira/browse/LOG4J2-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on LOG4J2-3316 started by Gary D. Gregory.
---
> Log4j 1.2 bridge should ignore case in properties file keys
> ---
>
> Key: LOG4J2-3316
> URL: https://issues.apache.org/jira/browse/LOG4J2-3316
> Project: Log4j 2
> Issue Type: Improvement
> Components: log4j 1.2 emulation
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
>
> Log4j 1.2 bridge should ignore case in properties file keys.
> This will allow both of these styles to work:
> log4j.appender.FILE_APPENDER.file=${java.io.tmpdir}/${hadoop.log.file}
> log4j.appender.FILE_APPENDER.File=${java.io.tmpdir}/${hadoop.log.file}
> Notice the "file" vs. "File"
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3315) %X[key] is not working with bridge api ( Log4j 1.x bridge 2.15.0)
[
https://issues.apache.org/jira/browse/LOG4J2-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468829#comment-17468829
]
Gary D. Gregory commented on LOG4J2-3315:
-
Hi [~kamleshsilag]
You should use 2.17.1, not 2.15.0, for the safest setup.
Would you confirm whether this still happens in 2.17.1?
> %X[key] is not working with bridge api ( Log4j 1.x bridge 2.15.0)
> -
>
> Key: LOG4J2-3315
> URL: https://issues.apache.org/jira/browse/LOG4J2-3315
> Project: Log4j 2
> Issue Type: Question
> Components: Configuration
>Affects Versions: 2.15.0
>Reporter: Kamlesh Silag
>Priority: Minor
>
> Hi, I am trying to migrate one of the app from 1.x to 2.15.0. We were using
> MDC for lookups and as per bridge api, we can still use MDC for lookups.
> In Code, we use
>
> {code:java}
> MDC.put("PID", someFunction());{code}
>
> FYI, _MDC.get("PID)_ gives correct lookup information
> Configuration File-
>
> {code:java}
> appender.rolling.layout.type = PatternLayout
> appender.rolling.layout.pattern = %d{dd MMM HH:mm:ss,SSS} %-5p [%t]
> [%X{PID}] %c - %m%n{code}
> h2. *But, %X\{PID} is giving blank.*
>
> Dependencies we are using-
> # log4j-1.2-api-2.15.0.jar
> # log4j-api-2.15.0.jar
> # log4j-core-2.15.0.jar
> # log4j-jcl-2.15.0.jar
> # commons-logging-1.1.1.jar
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3312) Bridge does not convert properties
[
https://issues.apache.org/jira/browse/LOG4J2-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468635#comment-17468635
]
Gary D. Gregory edited comment on LOG4J2-3312 at 1/4/22, 4:47 PM:
--
Hi [~scanti81]
Please post your Log4j 1 properties file.
was (Author: garydgregory):
Hi [~scanti81]
Please posy your Log4j 1 properties file.
> Bridge does not convert properties
> --
>
> Key: LOG4J2-3312
> URL: https://issues.apache.org/jira/browse/LOG4J2-3312
> Project: Log4j 2
> Issue Type: Bug
> Components: log4j 1.2 emulation
>Affects Versions: 2.17.1
>Reporter: Enrico Scantamburlo
>Priority: Major
>
> I have tried to migrate my application from Log4j 1.2.17 to the latest.
> The first problem was that the class FileAppender was not inside the bridge
> jar.
> I resolved the issue copying the java file from the old version.
> Now I found out the that the properties that are in the log4j.properties are
> not converted when passed to my custom appeder.
> Like
> {{log4j.appender.FULL.file = ${user.home}/${user.name}}}
> is not expanded to {{/home/escantam/escantam}}
> The properties file is found and loaded but the properties no expanded when
> the setFile method is called.
> Is this a bug?
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3314) checksum and signature checks fail for 2.17.1 bin zip and tgz
[ https://issues.apache.org/jira/browse/LOG4J2-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468717#comment-17468717 ] Gary D. Gregory commented on LOG4J2-3314: - Please provide a specific example so we can compare. > checksum and signature checks fail for 2.17.1 bin zip and tgz > - > > Key: LOG4J2-3314 > URL: https://issues.apache.org/jira/browse/LOG4J2-3314 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.1 >Reporter: Adam Dalhed >Priority: Major > > The linked binary downloads on > [https://logging.apache.org/log4j/2.x/download.html] fail the signature and > sha512 checksums. I didn't check the src downloads. I had to download the > binaries from the [main distribution > directory|https://www.apache.org/dist/logging/] to pass the checks. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] (LOG4J2-3312) Bridge does not convert properties
[ https://issues.apache.org/jira/browse/LOG4J2-3312 ]
Gary D. Gregory deleted comment on LOG4J2-3312:
-
was (Author: garydgregory):
Hm... debugging a sample config shows for me that a rolling file appended is
created instead of a file appended, I'll have to take a look unless someone
else gets to it first.
> Bridge does not convert properties
> --
>
> Key: LOG4J2-3312
> URL: https://issues.apache.org/jira/browse/LOG4J2-3312
> Project: Log4j 2
> Issue Type: Bug
> Components: log4j 1.2 emulation
>Affects Versions: 2.17.1
>Reporter: Enrico Scantamburlo
>Priority: Major
>
> I have tried to migrate my application from Log4j 1.2.17 to the latest.
> The first problem was that the class FileAppender was not inside the bridge
> jar.
> I resolved the issue copying the java file from the old version.
> Now I found out the that the properties that are in the log4j.properties are
> not converted when passed to my custom appeder.
> Like
> {{log4j.appender.FULL.file = ${user.home}/${user.name}}}
> is not expanded to {{/home/escantam/escantam}}
> The properties file is found and loaded but the properties no expanded when
> the setFile method is called.
> Is this a bug?
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3312) Bridge does not convert properties
[
https://issues.apache.org/jira/browse/LOG4J2-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468635#comment-17468635
]
Gary D. Gregory commented on LOG4J2-3312:
-
Hi [~scanti81]
Please posy your Log4j 1 properties file.
> Bridge does not convert properties
> --
>
> Key: LOG4J2-3312
> URL: https://issues.apache.org/jira/browse/LOG4J2-3312
> Project: Log4j 2
> Issue Type: Bug
> Components: log4j 1.2 emulation
>Affects Versions: 2.17.1
>Reporter: Enrico Scantamburlo
>Priority: Major
>
> I have tried to migrate my application from Log4j 1.2.17 to the latest.
> The first problem was that the class FileAppender was not inside the bridge
> jar.
> I resolved the issue copying the java file from the old version.
> Now I found out the that the properties that are in the log4j.properties are
> not converted when passed to my custom appeder.
> Like
> {{log4j.appender.FULL.file = ${user.home}/${user.name}}}
> is not expanded to {{/home/escantam/escantam}}
> The properties file is found and loaded but the properties no expanded when
> the setFile method is called.
> Is this a bug?
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3312) Bridge does not convert properties
[
https://issues.apache.org/jira/browse/LOG4J2-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468628#comment-17468628
]
Gary D. Gregory commented on LOG4J2-3312:
-
Hm... debugging a sample config shows for me that a rolling file appended is
created instead of a file appended, I'll have to take a look unless someone
else gets to it first.
> Bridge does not convert properties
> --
>
> Key: LOG4J2-3312
> URL: https://issues.apache.org/jira/browse/LOG4J2-3312
> Project: Log4j 2
> Issue Type: Bug
> Components: log4j 1.2 emulation
>Affects Versions: 2.17.1
>Reporter: Enrico Scantamburlo
>Priority: Major
>
> I have tried to migrate my application from Log4j 1.2.17 to the latest.
> The first problem was that the class FileAppender was not inside the bridge
> jar.
> I resolved the issue copying the java file from the old version.
> Now I found out the that the properties that are in the log4j.properties are
> not converted when passed to my custom appeder.
> Like
> {{log4j.appender.FULL.file = ${user.home}/${user.name}}}
> is not expanded to {{/home/escantam/escantam}}
> The properties file is found and loaded but the properties no expanded when
> the setFile method is called.
> Is this a bug?
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3312) Bridge does not convert properties
[
https://issues.apache.org/jira/browse/LOG4J2-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468622#comment-17468622
]
Gary D. Gregory commented on LOG4J2-3312:
-
Hi [~scanti81]
"The first problem was that the class FileAppender was not inside the bridge
jar."
That's not how the bridge works. The bridge, well, bridges, your old v1
configuration to the new v2 classes such that your v1 calls are forwarded to
the v2 implementation.
We've fixed issues in the bridge since 2.17.1 and you should try
2.17.2-SNAPSHOT from the snapshot repo:
[https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/]
> Bridge does not convert properties
> --
>
> Key: LOG4J2-3312
> URL: https://issues.apache.org/jira/browse/LOG4J2-3312
> Project: Log4j 2
> Issue Type: Bug
> Components: log4j 1.2 emulation
>Affects Versions: 2.17.1
>Reporter: Enrico Scantamburlo
>Priority: Major
>
> I have tried to migrate my application from Log4j 1.2.17 to the latest.
> The first problem was that the class FileAppender was not inside the bridge
> jar.
> I resolved the issue copying the java file from the old version.
> Now I found out the that the properties that are in the log4j.properties are
> not converted when passed to my custom appeder.
> Like
> {{log4j.appender.FULL.file = ${user.home}/${user.name}}}
> is not expanded to {{/home/escantam/escantam}}
> The properties file is found and loaded but the properties no expanded when
> the setFile method is called.
> Is this a bug?
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3309) SetUtils class is missing in Log4j 2.17.x
[
https://issues.apache.org/jira/browse/LOG4J2-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468614#comment-17468614
]
Gary D. Gregory commented on LOG4J2-3309:
-
Hi [~habdank]
Ideally, you should not depend on types that are internal to Log4j's
implementation. There is no remedy here aside from copying this code into your
application or using another library like [Apache Commons
Collections|https://commons.apache.org/proper/commons-collections/].
> SetUtils class is missing in Log4j 2.17.x
> -
>
> Key: LOG4J2-3309
> URL: https://issues.apache.org/jira/browse/LOG4J2-3309
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Seweryn Habdank-Wojewodzki
>Priority: Major
>
> Hi,
>
> According to:
> [https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core]
> it is recommended to use Log4j v. 2.17.1, but when I use this version I
> cannot compile the code, as I am getting error:
> {code}
> error: cannot find symbol
> symbol: class SetUtils
> location: package org.apache.logging.log4j.core.util
> {code}
> I found similar question is SO:
> [https://stackoverflow.com/questions/70428495/issue-with-log4j-2-17-0-update-classnotfoundexception-setutils]
> But when I look in the Java Doc this class is also not there:
> [https://logging.apache.org/log4j/log4j-2.17.0/log4j-web/apidocs/index.html?overview-summary.html]
>
> Can you provide migration/update documentation when updating from Log4j v.
> 2.16.0 to 2.17.1, please?
> Thanks in advance,
> Seweryn.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3281) PropertiesConfiguration.buildAppender not adding filters to custom appender
[
https://issues.apache.org/jira/browse/LOG4J2-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468607#comment-17468607
]
Gary D. Gregory commented on LOG4J2-3281:
-
I had reverted the commit incorrectly while working on a different issue. Fixed
in release-2.x. I am deploying again, please try again and I offer my apologies!
> PropertiesConfiguration.buildAppender not adding filters to custom appender
> ---
>
> Key: LOG4J2-3281
> URL: https://issues.apache.org/jira/browse/LOG4J2-3281
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
>Affects Versions: 2.17.1, 2.17.0
>Reporter: Fábio Constantino
>Priority: Blocker
> Fix For: 2.17.2
>
>
> When building an appender, the _parseAppenderFilters_ method correctly finds
> my custom filter configuration in the properties file, builds it and returns
> it, but the caller ({_}buildAppender{_} method) does nothing with it
> resulting in the appender not having any filters added to it.
>
> This is related to the linked issue -
> [LOG4J2-3247|https://issues.apache.org/jira/browse/LOG4J2-3247] - where the
> scenario is the same (properties file config):
> {code:java}
> log4j1.compatibility=true
> log4j.appender.LOG_REQUEST_START_DB=my.appender.class
> log4j.appender.LOG_REQUEST_START_DB.filter.ID=my.filter.class {code}
> the Filter class I'm working with is the following:
> {code:java}
> import org.apache.log4j.spi.Filter;
> import org.apache.log4j.spi.LoggingEvent;
> public class MonitorFilter extends Filter {
> @Override
> public int decide(LoggingEvent event) {
> String requestId = (String)event.getMDC("requestId");
> if (StringHelper.isNullOrEmpty(requestId))
> return DENY;
>
> if
> (!MonitorScriptManager.getInstance().getMonitorScript().filter(event))
> return DENY;
>
> return ACCEPT;
> }
> } {code}
> I am using the following log4j dependencies:
> {code:java}
>
> org.apache.logging.log4j
> log4j-core
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-api
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-1.2-api
> 2.17.0
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3105) not able to deploy log4j-core-2.14.1 in weblogic12c
[ https://issues.apache.org/jira/browse/LOG4J2-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17465051#comment-17465051 ] Gary D. Gregory edited comment on LOG4J2-3105 at 1/4/22, 11:01 AM: --- [~vy] , [~esteve.blanch] wrote/edited to say Java 7. I've seen this before unfortunately where tooling like some Android tooling IIRC, and in this case, a web server scan a whole jar file and do not know about the mess multi-release Jars made with jar files. was (Author: garydgregory): [~vy] , [~esteve.blanch] wrote/edited to say Java 7. I've seen this before unfortunately where tooling like some Android tooling IIRC, and in this case, a web server scan a whole jar file and do not know about the mess JPMS made with jar files. > not able to deploy log4j-core-2.14.1 in weblogic12c > --- > > Key: LOG4J2-3105 > URL: https://issues.apache.org/jira/browse/LOG4J2-3105 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.11.1, 2.12.1, 2.14.0, 2.13.3, 2.14.1 > Environment: WebLogic Server Version: 12.1.3.0.0 >Reporter: Siddharth jain >Priority: Major > Fix For: 2.14.1 > > Attachments: log4j2config.xml, web.xml, weblogic.xml > > > I m trying to upgrade my log4j to log4j2 , itried with log4j 2.8.1 with > changes in web.xml, weblogic.xml and log4j2.xml files, it was getting > deployed successfully. As this version is having vulnerability i tried with > other versions 2.13.1, 2.13.2, 2.13.3, 2.14.0, 2.14.1 with log4j-api and > log4j-core jar and log4j-slf4j-impl all with same version, slf4j-api-1.7.30 > all giving following error : > An error occurred during activation of changes, please see the log for > details. > null null > java.lang.IllegalArgumentException: > > *in weblogic server logs :* > > following error: weblogic.application.ModuleException: null > null > at > weblogic.servlet.internal.WebAppModule.createModuleException(WebAppModule.java:1824) > at weblogic.servlet.internal.WebAppModule.init(WebAppModule.java:270) > at weblogic.servlet.internal.WebAppModule.init(WebAppModule.java:682) > at > weblogic.application.internal.flow.ScopedModuleDriver.init(ScopedModuleDriver.java:162) > at > weblogic.application.internal.ExtensibleModuleWrapper.init(ExtensibleModuleWrapper.java:98) > at > weblogic.application.internal.flow.ModuleListenerInvoker.init(ModuleListenerInvoker.java:84) > at > weblogic.application.internal.flow.InitModulesFlow.initModule(InitModulesFlow.java:288) > at > weblogic.application.internal.flow.InitModulesFlow.initModules(InitModulesFlow.java:301) > at > weblogic.application.internal.flow.InitModulesFlow.prepare(InitModulesFlow.java:329) > at > weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:706) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at > weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:237) > at > weblogic.application.internal.SingleModuleDeployment.prepare(SingleModuleDeployment.java:48) > at > weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:158) > at > weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:61) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:208) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:98) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:233) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:749) > at > weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1238) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:252) > at > weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:172) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:171) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:13) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:46) > at > weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:263) >
[jira] [Commented] (LOG4J2-3105) not able to deploy log4j-core-2.14.1 in weblogic12c
[ https://issues.apache.org/jira/browse/LOG4J2-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468575#comment-17468575 ] Gary D. Gregory commented on LOG4J2-3105: - If you are stuck on Java 7, make sure you use 2.12.4. > not able to deploy log4j-core-2.14.1 in weblogic12c > --- > > Key: LOG4J2-3105 > URL: https://issues.apache.org/jira/browse/LOG4J2-3105 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.11.1, 2.12.1, 2.14.0, 2.13.3, 2.14.1 > Environment: WebLogic Server Version: 12.1.3.0.0 >Reporter: Siddharth jain >Priority: Major > Fix For: 2.14.1 > > Attachments: log4j2config.xml, web.xml, weblogic.xml > > > I m trying to upgrade my log4j to log4j2 , itried with log4j 2.8.1 with > changes in web.xml, weblogic.xml and log4j2.xml files, it was getting > deployed successfully. As this version is having vulnerability i tried with > other versions 2.13.1, 2.13.2, 2.13.3, 2.14.0, 2.14.1 with log4j-api and > log4j-core jar and log4j-slf4j-impl all with same version, slf4j-api-1.7.30 > all giving following error : > An error occurred during activation of changes, please see the log for > details. > null null > java.lang.IllegalArgumentException: > > *in weblogic server logs :* > > following error: weblogic.application.ModuleException: null > null > at > weblogic.servlet.internal.WebAppModule.createModuleException(WebAppModule.java:1824) > at weblogic.servlet.internal.WebAppModule.init(WebAppModule.java:270) > at weblogic.servlet.internal.WebAppModule.init(WebAppModule.java:682) > at > weblogic.application.internal.flow.ScopedModuleDriver.init(ScopedModuleDriver.java:162) > at > weblogic.application.internal.ExtensibleModuleWrapper.init(ExtensibleModuleWrapper.java:98) > at > weblogic.application.internal.flow.ModuleListenerInvoker.init(ModuleListenerInvoker.java:84) > at > weblogic.application.internal.flow.InitModulesFlow.initModule(InitModulesFlow.java:288) > at > weblogic.application.internal.flow.InitModulesFlow.initModules(InitModulesFlow.java:301) > at > weblogic.application.internal.flow.InitModulesFlow.prepare(InitModulesFlow.java:329) > at > weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:706) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at > weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:237) > at > weblogic.application.internal.SingleModuleDeployment.prepare(SingleModuleDeployment.java:48) > at > weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:158) > at > weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:61) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:208) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:98) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:233) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:749) > at > weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1238) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:252) > at > weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:172) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:171) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:13) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:46) > at > weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:263) > Caused by: java.lang.IllegalArgumentException: > at com.bea.objectweb.asm.ClassReader.(Unknown Source) > at com.bea.objectweb.asm.ClassReader.(Unknown Source) > at > weblogic.application.utils.annotation.ClassInfoImpl.(ClassInfoImpl.java:41) > at > weblogic.application.utils.annotation.ClassfinderClassInfos.polulateOneClassInfo(ClassfinderClassInfos.java:240) > at > weblogic.application.utils.annotation.ClassfinderClassInfos.populateClassInfos(ClassfinderClassInfos.java:193) > at >
[jira] [Commented] (LOG4J2-3281) PropertiesConfiguration.buildAppender not adding filters to custom appender
[
https://issues.apache.org/jira/browse/LOG4J2-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468103#comment-17468103
]
Gary D. Gregory commented on LOG4J2-3281:
-
[~coredumped]
Well, crud, I am so sorry about that. I will have to take a look at applying
the fix again to the release-2.x branch as I am not sure how that got mixed in
a revert. It won't be until much later tonight though.
> PropertiesConfiguration.buildAppender not adding filters to custom appender
> ---
>
> Key: LOG4J2-3281
> URL: https://issues.apache.org/jira/browse/LOG4J2-3281
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
>Affects Versions: 2.17.1, 2.17.0
>Reporter: Fábio Constantino
>Priority: Blocker
> Fix For: 2.17.2
>
>
> When building an appender, the _parseAppenderFilters_ method correctly finds
> my custom filter configuration in the properties file, builds it and returns
> it, but the caller ({_}buildAppender{_} method) does nothing with it
> resulting in the appender not having any filters added to it.
>
> This is related to the linked issue -
> [LOG4J2-3247|https://issues.apache.org/jira/browse/LOG4J2-3247] - where the
> scenario is the same (properties file config):
> {code:java}
> log4j1.compatibility=true
> log4j.appender.LOG_REQUEST_START_DB=my.appender.class
> log4j.appender.LOG_REQUEST_START_DB.filter.ID=my.filter.class {code}
> the Filter class I'm working with is the following:
> {code:java}
> import org.apache.log4j.spi.Filter;
> import org.apache.log4j.spi.LoggingEvent;
> public class MonitorFilter extends Filter {
> @Override
> public int decide(LoggingEvent event) {
> String requestId = (String)event.getMDC("requestId");
> if (StringHelper.isNullOrEmpty(requestId))
> return DENY;
>
> if
> (!MonitorScriptManager.getInstance().getMonitorScript().filter(event))
> return DENY;
>
> return ACCEPT;
> }
> } {code}
> I am using the following log4j dependencies:
> {code:java}
>
> org.apache.logging.log4j
> log4j-core
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-api
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-1.2-api
> 2.17.0
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3281) PropertiesConfiguration.buildAppender not adding filters to custom appender
[
https://issues.apache.org/jira/browse/LOG4J2-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468005#comment-17468005
]
Gary D. Gregory commented on LOG4J2-3281:
-
If you use Maven to build make sure to specify {{-U}} on the command line to
force a SNAPSHOT refresh. It should be there. I am deploying another snapshot
as I type just in case... Give it 10 minutes.
> PropertiesConfiguration.buildAppender not adding filters to custom appender
> ---
>
> Key: LOG4J2-3281
> URL: https://issues.apache.org/jira/browse/LOG4J2-3281
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
>Affects Versions: 2.17.1, 2.17.0
>Reporter: Fábio Constantino
>Priority: Blocker
> Fix For: 2.17.2
>
>
> When building an appender, the _parseAppenderFilters_ method correctly finds
> my custom filter configuration in the properties file, builds it and returns
> it, but the caller ({_}buildAppender{_} method) does nothing with it
> resulting in the appender not having any filters added to it.
>
> This is related to the linked issue -
> [LOG4J2-3247|https://issues.apache.org/jira/browse/LOG4J2-3247] - where the
> scenario is the same (properties file config):
> {code:java}
> log4j1.compatibility=true
> log4j.appender.LOG_REQUEST_START_DB=my.appender.class
> log4j.appender.LOG_REQUEST_START_DB.filter.ID=my.filter.class {code}
> the Filter class I'm working with is the following:
> {code:java}
> import org.apache.log4j.spi.Filter;
> import org.apache.log4j.spi.LoggingEvent;
> public class MonitorFilter extends Filter {
> @Override
> public int decide(LoggingEvent event) {
> String requestId = (String)event.getMDC("requestId");
> if (StringHelper.isNullOrEmpty(requestId))
> return DENY;
>
> if
> (!MonitorScriptManager.getInstance().getMonitorScript().filter(event))
> return DENY;
>
> return ACCEPT;
> }
> } {code}
> I am using the following log4j dependencies:
> {code:java}
>
> org.apache.logging.log4j
> log4j-core
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-api
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-1.2-api
> 2.17.0
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3254) Need a log4j-core version 2.16 osgi compatible
[
https://issues.apache.org/jira/browse/LOG4J2-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467294#comment-17467294
]
Gary D. Gregory commented on LOG4J2-3254:
-
[~4535992]
Do you have step-by-step instructions I could follow to simply reproduce this
issue? Then I can try to fix it and test local builds.
> Need a log4j-core version 2.16 osgi compatible
> --
>
> Key: LOG4J2-3254
> URL: https://issues.apache.org/jira/browse/LOG4J2-3254
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core, OSGi
>Affects Versions: 2.16.0, 2.17.1, 2.17.0
>Reporter: Marco Tenti
>Priority: Major
>
> After the big security issue discovered with log4j2 , we need to update all
> the "old" osgi/karaf installation.
> When i run this piece of coce
> {code:sh}
> osgi:install -s mvn:org.apache.logging.log4j/log4j-core/2.13.0
> {code}
> is work fine with this :
> {code:sh}
> osgi:install -s mvn:org.apache.logging.log4j/log4j-core/2.16.0
> {code}
> I get this error :
> {code:sh}
> Error executing command: Error installing bundles:
> Unable to start bundle
> mvn:org.apache.logging.log4j/log4j-core/2.16.0:
> org.osgi.framework.BundleException: Unable to resolve
> org.apache.logging.log4j.core [521](R 521.0): missing requirement
> [org.apache.logging.log4j.core [521](R 521.0)] osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.logging.log4j)(version>=2.16.0)(!(version>=3.0.0)))
> Unresolved requirements: [[org.apache.logging.log4j.core [521](R 521.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.logging.log4j)(version>=2.16.0)(!(version>=3.0.0)))]
> {code}
> it is a bug ? or i must use some other library ? i try to use [log4j-osgi
> (version
> 2.16)|https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-osgi/2.16.0]
> like this
> {code:sh}
> osgi:install -s mvn:org.apache.logging.log4j/log4j-osgi/2.16.0
> {code}
> it's work fine, but i still get the error from my bundles project:
> {code:sh}
> Error executing command: Error executing command on bundles:
> Error starting bundle 515: Unable to resolve XXX [515](R 515.0):
> missing requirement [XXX [515](R 515.0)] osgi.wiring.package;
> (osgi.wiring.package=org.apache.logging.log4j.core) Unresolved requirements:
> [[XXX [515](R 515.0)] osgi.wiring.package;
> (osgi.wiring.package=org.apache.logging.log4j.core)]
> {code}
> this error is not happening with version 2.13
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3267) Getting public access to org.apache.logging.log4j.core.tools.Generate#generate method for automated code generation
[
https://issues.apache.org/jira/browse/LOG4J2-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LOG4J2-3267:
Priority: Minor (was: Trivial)
> Getting public access to
> org.apache.logging.log4j.core.tools.Generate#generate method for automated
> code generation
> ---
>
> Key: LOG4J2-3267
> URL: https://issues.apache.org/jira/browse/LOG4J2-3267
> Project: Log4j 2
> Issue Type: Wish
> Components: Core
>Affects Versions: 2.17.0
>Reporter: Gotthard Witsch
>Assignee: Remko Popma
>Priority: Minor
> Fix For: 2.17.2
>
>
> Hi devs,
> I'd like to automate the creation of a custom logger with gradle.
> Sticking to the documentation i've tried to use
> org.apache.logging.log4j.core.tools.ExtendedLoggerGenerator as mentioned in
> [Log4j – Custom Log Levels
> (apache.org)|https://logging.apache.org/log4j/2.x/manual/customloglevels.html#CustomLoggers]
> Unfortunately the output can only be consumed from console, making it very
> hard for automation.
> Investigating the implemenation led me to
> org.apache.logging.log4j.core.tools.Generate.generate.
> Unfortunately the required method is package private.
> Therefore it would be helpful to change the generate-method's visibility to
> public to gain access in gradle scripts.
> {code:java}
> static void generate(final String[] args, final Type type, final PrintStream
> printStream) {code}
> Is there any chance of changing this? Or what was the intention to keep it
> package-private?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3281) PropertiesConfiguration.buildAppender not adding filters to custom appender
[
https://issues.apache.org/jira/browse/LOG4J2-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467288#comment-17467288
]
Gary D. Gregory commented on LOG4J2-3281:
-
[~coredumped]
I just pushed snapshots to
[https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j]
> PropertiesConfiguration.buildAppender not adding filters to custom appender
> ---
>
> Key: LOG4J2-3281
> URL: https://issues.apache.org/jira/browse/LOG4J2-3281
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
>Affects Versions: 2.17.1, 2.17.0
>Reporter: Fábio Constantino
>Priority: Blocker
> Fix For: 2.17.2
>
>
> When building an appender, the _parseAppenderFilters_ method correctly finds
> my custom filter configuration in the properties file, builds it and returns
> it, but the caller ({_}buildAppender{_} method) does nothing with it
> resulting in the appender not having any filters added to it.
>
> This is related to the linked issue -
> [LOG4J2-3247|https://issues.apache.org/jira/browse/LOG4J2-3247] - where the
> scenario is the same (properties file config):
> {code:java}
> log4j1.compatibility=true
> log4j.appender.LOG_REQUEST_START_DB=my.appender.class
> log4j.appender.LOG_REQUEST_START_DB.filter.ID=my.filter.class {code}
> the Filter class I'm working with is the following:
> {code:java}
> import org.apache.log4j.spi.Filter;
> import org.apache.log4j.spi.LoggingEvent;
> public class MonitorFilter extends Filter {
> @Override
> public int decide(LoggingEvent event) {
> String requestId = (String)event.getMDC("requestId");
> if (StringHelper.isNullOrEmpty(requestId))
> return DENY;
>
> if
> (!MonitorScriptManager.getInstance().getMonitorScript().filter(event))
> return DENY;
>
> return ACCEPT;
> }
> } {code}
> I am using the following log4j dependencies:
> {code:java}
>
> org.apache.logging.log4j
> log4j-core
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-api
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-1.2-api
> 2.17.0
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3281) PropertiesConfiguration.buildAppender not adding filters to custom appender
[
https://issues.apache.org/jira/browse/LOG4J2-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LOG4J2-3281.
-
Fix Version/s: 2.17.2
Resolution: Fixed
> PropertiesConfiguration.buildAppender not adding filters to custom appender
> ---
>
> Key: LOG4J2-3281
> URL: https://issues.apache.org/jira/browse/LOG4J2-3281
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
>Affects Versions: 2.17.0
>Reporter: Fábio Constantino
>Priority: Blocker
> Fix For: 2.17.2
>
>
> When building an appender, the _parseAppenderFilters_ method correctly finds
> my custom filter configuration in the properties file, builds it and returns
> it, but the caller ({_}buildAppender{_} method) does nothing with it
> resulting in the appender not having any filters added to it.
>
> This is related to the linked issue -
> [LOG4J2-3247|https://issues.apache.org/jira/browse/LOG4J2-3247] - where the
> scenario is the same (properties file config):
> {code:java}
> log4j1.compatibility=true
> log4j.appender.LOG_REQUEST_START_DB=my.appender.class
> log4j.appender.LOG_REQUEST_START_DB.filter.ID=my.filter.class {code}
> the Filter class I'm working with is the following:
> {code:java}
> import org.apache.log4j.spi.Filter;
> import org.apache.log4j.spi.LoggingEvent;
> public class MonitorFilter extends Filter {
> @Override
> public int decide(LoggingEvent event) {
> String requestId = (String)event.getMDC("requestId");
> if (StringHelper.isNullOrEmpty(requestId))
> return DENY;
>
> if
> (!MonitorScriptManager.getInstance().getMonitorScript().filter(event))
> return DENY;
>
> return ACCEPT;
> }
> } {code}
> I am using the following log4j dependencies:
> {code:java}
>
> org.apache.logging.log4j
> log4j-core
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-api
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-1.2-api
> 2.17.0
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3281) PropertiesConfiguration.buildAppender not adding filters to custom appender
[
https://issues.apache.org/jira/browse/LOG4J2-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LOG4J2-3281:
Affects Version/s: 2.17.1
> PropertiesConfiguration.buildAppender not adding filters to custom appender
> ---
>
> Key: LOG4J2-3281
> URL: https://issues.apache.org/jira/browse/LOG4J2-3281
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
>Affects Versions: 2.17.1, 2.17.0
>Reporter: Fábio Constantino
>Priority: Blocker
> Fix For: 2.17.2
>
>
> When building an appender, the _parseAppenderFilters_ method correctly finds
> my custom filter configuration in the properties file, builds it and returns
> it, but the caller ({_}buildAppender{_} method) does nothing with it
> resulting in the appender not having any filters added to it.
>
> This is related to the linked issue -
> [LOG4J2-3247|https://issues.apache.org/jira/browse/LOG4J2-3247] - where the
> scenario is the same (properties file config):
> {code:java}
> log4j1.compatibility=true
> log4j.appender.LOG_REQUEST_START_DB=my.appender.class
> log4j.appender.LOG_REQUEST_START_DB.filter.ID=my.filter.class {code}
> the Filter class I'm working with is the following:
> {code:java}
> import org.apache.log4j.spi.Filter;
> import org.apache.log4j.spi.LoggingEvent;
> public class MonitorFilter extends Filter {
> @Override
> public int decide(LoggingEvent event) {
> String requestId = (String)event.getMDC("requestId");
> if (StringHelper.isNullOrEmpty(requestId))
> return DENY;
>
> if
> (!MonitorScriptManager.getInstance().getMonitorScript().filter(event))
> return DENY;
>
> return ACCEPT;
> }
> } {code}
> I am using the following log4j dependencies:
> {code:java}
>
> org.apache.logging.log4j
> log4j-core
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-api
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-1.2-api
> 2.17.0
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3281) PropertiesConfiguration.buildAppender not adding filters to custom appender
[
https://issues.apache.org/jira/browse/LOG4J2-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467267#comment-17467267
]
Gary D. Gregory commented on LOG4J2-3281:
-
[~coredumped]
I patched the {{release-2.x}} branch, please give it a try or use a snapshot
build from our snapshot Maven repository at
[https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j]
> PropertiesConfiguration.buildAppender not adding filters to custom appender
> ---
>
> Key: LOG4J2-3281
> URL: https://issues.apache.org/jira/browse/LOG4J2-3281
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
>Affects Versions: 2.17.0
>Reporter: Fábio Constantino
>Priority: Blocker
>
> When building an appender, the _parseAppenderFilters_ method correctly finds
> my custom filter configuration in the properties file, builds it and returns
> it, but the caller ({_}buildAppender{_} method) does nothing with it
> resulting in the appender not having any filters added to it.
>
> This is related to the linked issue -
> [LOG4J2-3247|https://issues.apache.org/jira/browse/LOG4J2-3247] - where the
> scenario is the same (properties file config):
> {code:java}
> log4j1.compatibility=true
> log4j.appender.LOG_REQUEST_START_DB=my.appender.class
> log4j.appender.LOG_REQUEST_START_DB.filter.ID=my.filter.class {code}
> the Filter class I'm working with is the following:
> {code:java}
> import org.apache.log4j.spi.Filter;
> import org.apache.log4j.spi.LoggingEvent;
> public class MonitorFilter extends Filter {
> @Override
> public int decide(LoggingEvent event) {
> String requestId = (String)event.getMDC("requestId");
> if (StringHelper.isNullOrEmpty(requestId))
> return DENY;
>
> if
> (!MonitorScriptManager.getInstance().getMonitorScript().filter(event))
> return DENY;
>
> return ACCEPT;
> }
> } {code}
> I am using the following log4j dependencies:
> {code:java}
>
> org.apache.logging.log4j
> log4j-core
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-api
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-1.2-api
> 2.17.0
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3281) PropertiesConfiguration.buildAppender not adding filters to custom appender
[
https://issues.apache.org/jira/browse/LOG4J2-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LOG4J2-3281:
Summary: PropertiesConfiguration.buildAppender not adding filters to custom
appender (was: PropertiesConfiguration.buildAppender not adding filters to
appender)
> PropertiesConfiguration.buildAppender not adding filters to custom appender
> ---
>
> Key: LOG4J2-3281
> URL: https://issues.apache.org/jira/browse/LOG4J2-3281
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
>Affects Versions: 2.17.0
>Reporter: Fábio Constantino
>Priority: Blocker
>
> When building an appender, the _parseAppenderFilters_ method correctly finds
> my custom filter configuration in the properties file, builds it and returns
> it, but the caller ({_}buildAppender{_} method) does nothing with it
> resulting in the appender not having any filters added to it.
>
> This is related to the linked issue -
> [LOG4J2-3247|https://issues.apache.org/jira/browse/LOG4J2-3247] - where the
> scenario is the same (properties file config):
> {code:java}
> log4j1.compatibility=true
> log4j.appender.LOG_REQUEST_START_DB=my.appender.class
> log4j.appender.LOG_REQUEST_START_DB.filter.ID=my.filter.class {code}
> the Filter class I'm working with is the following:
> {code:java}
> import org.apache.log4j.spi.Filter;
> import org.apache.log4j.spi.LoggingEvent;
> public class MonitorFilter extends Filter {
> @Override
> public int decide(LoggingEvent event) {
> String requestId = (String)event.getMDC("requestId");
> if (StringHelper.isNullOrEmpty(requestId))
> return DENY;
>
> if
> (!MonitorScriptManager.getInstance().getMonitorScript().filter(event))
> return DENY;
>
> return ACCEPT;
> }
> } {code}
> I am using the following log4j dependencies:
> {code:java}
>
> org.apache.logging.log4j
> log4j-core
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-api
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-1.2-api
> 2.17.0
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3281) PropertiesConfiguration.buildAppender not adding filters to appender
[
https://issues.apache.org/jira/browse/LOG4J2-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467262#comment-17467262
]
Gary D. Gregory commented on LOG4J2-3281:
-
[~coredumped]
Thank you for the detailed information. I can now reproduce this locally.
> PropertiesConfiguration.buildAppender not adding filters to appender
>
>
> Key: LOG4J2-3281
> URL: https://issues.apache.org/jira/browse/LOG4J2-3281
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
>Affects Versions: 2.17.0
>Reporter: Fábio Constantino
>Priority: Blocker
>
> When building an appender, the _parseAppenderFilters_ method correctly finds
> my custom filter configuration in the properties file, builds it and returns
> it, but the caller ({_}buildAppender{_} method) does nothing with it
> resulting in the appender not having any filters added to it.
>
> This is related to the linked issue -
> [LOG4J2-3247|https://issues.apache.org/jira/browse/LOG4J2-3247] - where the
> scenario is the same (properties file config):
> {code:java}
> log4j1.compatibility=true
> log4j.appender.LOG_REQUEST_START_DB=my.appender.class
> log4j.appender.LOG_REQUEST_START_DB.filter.ID=my.filter.class {code}
> the Filter class I'm working with is the following:
> {code:java}
> import org.apache.log4j.spi.Filter;
> import org.apache.log4j.spi.LoggingEvent;
> public class MonitorFilter extends Filter {
> @Override
> public int decide(LoggingEvent event) {
> String requestId = (String)event.getMDC("requestId");
> if (StringHelper.isNullOrEmpty(requestId))
> return DENY;
>
> if
> (!MonitorScriptManager.getInstance().getMonitorScript().filter(event))
> return DENY;
>
> return ACCEPT;
> }
> } {code}
> I am using the following log4j dependencies:
> {code:java}
>
> org.apache.logging.log4j
> log4j-core
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-api
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-1.2-api
> 2.17.0
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-2951) Properties are not resolved with Log4J1 configuration
[
https://issues.apache.org/jira/browse/LOG4J2-2951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466477#comment-17466477
]
Gary D. Gregory commented on LOG4J2-2951:
-
[~thackel]
Thank you for the confirmation.
Do upgrade to 2.17.1 though.
Also, let us know if you encounter other 1.2 bridge issues, I'd like to make
that as solid as we can.
> Properties are not resolved with Log4J1 configuration
> -
>
> Key: LOG4J2-2951
> URL: https://issues.apache.org/jira/browse/LOG4J2-2951
> Project: Log4j 2
> Issue Type: Bug
> Components: log4j 1.2 emulation
>Affects Versions: 2.13.3
>Reporter: Thomas Hackel
>Assignee: Ralph Goers
>Priority: Major
> Fix For: 2.15.0
>
>
> When using the log4j 1.2 emulation, the resolution of variables in the
> log4j.properties does not work.
> {code:java}
> ...
> maxbackupindex=20
> log4j.appender.RFA=org.apache.log4j.RollingFileAppender
> log4j.appender.RFA.MaxBackupIndex=${maxbackupindex}
> ...
> {code}
> I've also created a sample project which shows the problem:
> [https://github.com/thackel/log4j2-legacy-test]
> The log4j1 initialization (using system property) works and the property file
> is read automatically from the classpath, just the variable substitution does
> not work.
> Whats interesting that there is an existing Testcase in Log4J, which shows
> that it somehow works:
> [Log4j1ConfigurationFactoryTest.java
> |https://github.com/apache/logging-log4j2/blob/log4j-2.13.3/log4j-1.2-api/src/test/java/org/apache/log4j/config/Log4j1ConfigurationFactoryTest.java#L159]with
> its
> [log4j.properties|https://github.com/apache/logging-log4j2/blob/log4j-2.13.3/log4j-1.2-api/src/test/resources/config-1.2/log4j-RollingFileAppender-with-props.properties].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3293) JDBC Appender should use JNDI Manager and JNDI access should be limited.
[ https://issues.apache.org/jira/browse/LOG4J2-3293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466471#comment-17466471 ] Gary D. Gregory commented on LOG4J2-3293: - Hello [~yhorndt] The 2.12.4 and 2.3.2 releases are in flight and should be available today if all goes well, please be patient :) > JDBC Appender should use JNDI Manager and JNDI access should be limited. > > > Key: LOG4J2-3293 > URL: https://issues.apache.org/jira/browse/LOG4J2-3293 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.17.0, 2.12.3, 2.3.1 >Reporter: Ralph Goers >Assignee: Gary D. Gregory >Priority: Major > Fix For: 2.17.1, 2.3.2, 2.12.4 > > > JDBC Appender should use JndiManager when accessing JNDI. JNDI access should > be controlled via a system property. > Related to > [CVE-2021-44832|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832] > where an attacker with permission to modify the logging configuration file > can construct a malicious configuration using a JDBC Appender with a data > source referencing a JNDI URI which can execute remote code. > Fixed in > [https://github.com/apache/logging-log4j2/commit/05db5f9527254632b59aed2a1d78a32c5ab74f16] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3293) JDBC Appender should use JNDI Manager and JNDI access should be limited.
[ https://issues.apache.org/jira/browse/LOG4J2-3293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466262#comment-17466262 ] Gary D. Gregory commented on LOG4J2-3293: - You should contact your vendors for certain, they would only know what is safe to do and not to do with their particular product. You'll have to assume the risk for anything you do yourself to their software, unfortunately. It might be safe to replace this jar with that jar but there is no way to tell what the consequences are from the outside looking in. > JDBC Appender should use JNDI Manager and JNDI access should be limited. > > > Key: LOG4J2-3293 > URL: https://issues.apache.org/jira/browse/LOG4J2-3293 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.17.0 >Reporter: Ralph Goers >Assignee: Gary D. Gregory >Priority: Major > Fix For: 2.17.1 > > > JDBC Appender should use JndiManager when accessing JNDI. JNDI access should > be controlled via a system property. > Related to > [CVE-2021-44832|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832] > where an attacker with permission to modify the logging configuration file > can construct a malicious configuration using a JDBC Appender with a data > source referencing a JNDI URI which can execute remote code. > Fixed in > [https://github.com/apache/logging-log4j2/commit/05db5f9527254632b59aed2a1d78a32c5ab74f16] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3291) while deploying spring application to weblogic server with version 2.17.0 giving ArrayIndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LOG4J2-3291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17465750#comment-17465750 ] Gary D. Gregory commented on LOG4J2-3291: - [~shahidlk] You've given us nothing to work with here. Please post a reproducible scenario or at the very least your stack trace and Log4j configuration file. Also, what version of WebLogic? > while deploying spring application to weblogic server with version 2.17.0 > giving ArrayIndexOutOfBoundsException > --- > > Key: LOG4J2-3291 > URL: https://issues.apache.org/jira/browse/LOG4J2-3291 > Project: Log4j 2 > Issue Type: Bug >Reporter: shahid shaikh >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3256) Reduce ignored package scope of KafkaAppender
[
https://issues.apache.org/jira/browse/LOG4J2-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LOG4J2-3256.
-
Fix Version/s: 2.17.1
Resolution: Fixed
[~dongjin]
I modified GitHub patch #640 and pushed patches to branches {{release-2.x}} and
{{{}master{}}}.
You are credited in {{{}changes.xml{}}}.
Thank you for your help!
G
> Reduce ignored package scope of KafkaAppender
> -
>
> Key: LOG4J2-3256
> URL: https://issues.apache.org/jira/browse/LOG4J2-3256
> Project: Log4j 2
> Issue Type: Improvement
>Reporter: Dongjin Lee
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.1
>
>
> As of present, KafkaAppender ignores logging messages from the loggers
> starting with "org.apache.kafka". This is because KafkaAppender uses
> KafkaPoducer internally and to avoid recursive logging.
> However, the current ignored package scope, "org.apache.kafka", is too large,
> since KafkaProducer uses "org.apache.kafka.common" and
> "org.apache.kafka.client" only. It is problematic when Apache Kafka uses
> log4j2 for its logging.
> As of present, Apache Kafka is still using log4j 1.x, but a migration project
> is under-progress:
> * KAFKA-9366
> * KAFKA-12399
> If this project is taken, Apache Kafka will deprecate its log4j-appender and
> migrate into log4j2's KafkaAppender. Reducing the ignored package scope is a
> prior task to this work.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3256) Reduce ignored package scope of KafkaAppender
[ https://issues.apache.org/jira/browse/LOG4J2-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory reassigned LOG4J2-3256: --- Assignee: Gary D. Gregory > Reduce ignored package scope of KafkaAppender > - > > Key: LOG4J2-3256 > URL: https://issues.apache.org/jira/browse/LOG4J2-3256 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Dongjin Lee >Assignee: Gary D. Gregory >Priority: Major > > As of present, KafkaAppender ignores logging messages from the loggers > starting with "org.apache.kafka". This is because KafkaAppender uses > KafkaPoducer internally and to avoid recursive logging. > However, the current ignored package scope, "org.apache.kafka", is too large, > since KafkaProducer uses "org.apache.kafka.common" and > "org.apache.kafka.client" only. It is problematic when Apache Kafka uses > log4j2 for its logging. > As of present, Apache Kafka is still using log4j 1.x, but a migration project > is under-progress: > * KAFKA-9366 > * KAFKA-12399 > If this project is taken, Apache Kafka will deprecate its log4j-appender and > migrate into log4j2's KafkaAppender. Reducing the ignored package scope is a > prior task to this work. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3105) not able to deploy log4j-core-2.14.1 in weblogic12c
[ https://issues.apache.org/jira/browse/LOG4J2-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17465051#comment-17465051 ] Gary D. Gregory edited comment on LOG4J2-3105 at 12/24/21, 4:31 PM: [~vy] , [~esteve.blanch] wrote/edited to say Java 7. I've seen this before unfortunately where tooling like some Android tooling IIRC, and in this case, a web server scan a whole jar file and do not know about the mess JPMS made with jar files. was (Author: garydgregory): [~vy] , [~esteve.blanch] wrote/edited to say Java 7. > not able to deploy log4j-core-2.14.1 in weblogic12c > --- > > Key: LOG4J2-3105 > URL: https://issues.apache.org/jira/browse/LOG4J2-3105 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.11.1, 2.12.1, 2.14.0, 2.13.3, 2.14.1 > Environment: WebLogic Server Version: 12.1.3.0.0 >Reporter: Siddharth jain >Priority: Major > Fix For: 2.14.1 > > Attachments: log4j2config.xml, web.xml, weblogic.xml > > > I m trying to upgrade my log4j to log4j2 , itried with log4j 2.8.1 with > changes in web.xml, weblogic.xml and log4j2.xml files, it was getting > deployed successfully. As this version is having vulnerability i tried with > other versions 2.13.1, 2.13.2, 2.13.3, 2.14.0, 2.14.1 with log4j-api and > log4j-core jar and log4j-slf4j-impl all with same version, slf4j-api-1.7.30 > all giving following error : > An error occurred during activation of changes, please see the log for > details. > null null > java.lang.IllegalArgumentException: > > *in weblogic server logs :* > > following error: weblogic.application.ModuleException: null > null > at > weblogic.servlet.internal.WebAppModule.createModuleException(WebAppModule.java:1824) > at weblogic.servlet.internal.WebAppModule.init(WebAppModule.java:270) > at weblogic.servlet.internal.WebAppModule.init(WebAppModule.java:682) > at > weblogic.application.internal.flow.ScopedModuleDriver.init(ScopedModuleDriver.java:162) > at > weblogic.application.internal.ExtensibleModuleWrapper.init(ExtensibleModuleWrapper.java:98) > at > weblogic.application.internal.flow.ModuleListenerInvoker.init(ModuleListenerInvoker.java:84) > at > weblogic.application.internal.flow.InitModulesFlow.initModule(InitModulesFlow.java:288) > at > weblogic.application.internal.flow.InitModulesFlow.initModules(InitModulesFlow.java:301) > at > weblogic.application.internal.flow.InitModulesFlow.prepare(InitModulesFlow.java:329) > at > weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:706) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at > weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:237) > at > weblogic.application.internal.SingleModuleDeployment.prepare(SingleModuleDeployment.java:48) > at > weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:158) > at > weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:61) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:208) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:98) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:233) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:749) > at > weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1238) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:252) > at > weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:172) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:171) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:13) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:46) > at > weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:263) > Caused by: java.lang.IllegalArgumentException: > at com.bea.objectweb.asm.ClassReader.(Unknown Source) > at com.bea.objectweb.asm.ClassReader.(Unknown Source) > at >
[jira] [Commented] (LOG4J2-3105) not able to deploy log4j-core-2.14.1 in weblogic12c
[ https://issues.apache.org/jira/browse/LOG4J2-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17465051#comment-17465051 ] Gary D. Gregory commented on LOG4J2-3105: - [~vy] , [~esteve.blanch] wrote/edited to say Java 7. > not able to deploy log4j-core-2.14.1 in weblogic12c > --- > > Key: LOG4J2-3105 > URL: https://issues.apache.org/jira/browse/LOG4J2-3105 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.11.1, 2.12.1, 2.14.0, 2.13.3, 2.14.1 > Environment: WebLogic Server Version: 12.1.3.0.0 >Reporter: Siddharth jain >Priority: Major > Fix For: 2.14.1 > > Attachments: log4j2config.xml, web.xml, weblogic.xml > > > I m trying to upgrade my log4j to log4j2 , itried with log4j 2.8.1 with > changes in web.xml, weblogic.xml and log4j2.xml files, it was getting > deployed successfully. As this version is having vulnerability i tried with > other versions 2.13.1, 2.13.2, 2.13.3, 2.14.0, 2.14.1 with log4j-api and > log4j-core jar and log4j-slf4j-impl all with same version, slf4j-api-1.7.30 > all giving following error : > An error occurred during activation of changes, please see the log for > details. > null null > java.lang.IllegalArgumentException: > > *in weblogic server logs :* > > following error: weblogic.application.ModuleException: null > null > at > weblogic.servlet.internal.WebAppModule.createModuleException(WebAppModule.java:1824) > at weblogic.servlet.internal.WebAppModule.init(WebAppModule.java:270) > at weblogic.servlet.internal.WebAppModule.init(WebAppModule.java:682) > at > weblogic.application.internal.flow.ScopedModuleDriver.init(ScopedModuleDriver.java:162) > at > weblogic.application.internal.ExtensibleModuleWrapper.init(ExtensibleModuleWrapper.java:98) > at > weblogic.application.internal.flow.ModuleListenerInvoker.init(ModuleListenerInvoker.java:84) > at > weblogic.application.internal.flow.InitModulesFlow.initModule(InitModulesFlow.java:288) > at > weblogic.application.internal.flow.InitModulesFlow.initModules(InitModulesFlow.java:301) > at > weblogic.application.internal.flow.InitModulesFlow.prepare(InitModulesFlow.java:329) > at > weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:706) > at > weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at > weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:237) > at > weblogic.application.internal.SingleModuleDeployment.prepare(SingleModuleDeployment.java:48) > at > weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:158) > at > weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:61) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:208) > at > weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:98) > at > weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:233) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:749) > at > weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1238) > at > weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:252) > at > weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:172) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:171) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:13) > at > weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:46) > at > weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:263) > Caused by: java.lang.IllegalArgumentException: > at com.bea.objectweb.asm.ClassReader.(Unknown Source) > at com.bea.objectweb.asm.ClassReader.(Unknown Source) > at > weblogic.application.utils.annotation.ClassInfoImpl.(ClassInfoImpl.java:41) > at > weblogic.application.utils.annotation.ClassfinderClassInfos.polulateOneClassInfo(ClassfinderClassInfos.java:240) > at > weblogic.application.utils.annotation.ClassfinderClassInfos.populateClassInfos(ClassfinderClassInfos.java:193) > at >
[jira] [Commented] (LOG4J2-3261) Improve Configuration manual page
[ https://issues.apache.org/jira/browse/LOG4J2-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17465037#comment-17465037 ] Gary D. Gregory commented on LOG4J2-3261: - I voted +1 in Jira :) > Improve Configuration manual page > - > > Key: LOG4J2-3261 > URL: https://issues.apache.org/jira/browse/LOG4J2-3261 > Project: Log4j 2 > Issue Type: Documentation > Components: Documentation >Affects Versions: 2.17.0 >Reporter: Remko Popma >Assignee: Remko Popma >Priority: Major > > The configuration page can be improved to be more approachable for new users > of Log4j 2: > * basic concepts first and more prominent (what should the configuration file > be named and where to put it, etc) > * start with simple example (like a file appender and a console appender) > * In general: smaller code examples, less text (where possible) > * create separate Advanced Configuration page and move some contents there -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3282) log4j-to-jul Adapter
[
https://issues.apache.org/jira/browse/LOG4J2-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464789#comment-17464789
]
Gary D. Gregory commented on LOG4J2-3282:
-
Hello [~vorburger]
Feel free to provide a PR on GitHub.
We cannot assign this ticket to you due to the way this Jira project is set up.
Let us know on the dev mailing list if you have any questions.
Good luck!
> log4j-to-jul Adapter
>
>
> Key: LOG4J2-3282
> URL: https://issues.apache.org/jira/browse/LOG4J2-3282
> Project: Log4j 2
> Issue Type: Improvement
>Affects Versions: 2.17.0
>Reporter: Michael Vorburger
>Priority: Major
> Fix For: 2.17.1
>
>
> I (we, internal project at work) would like to have a {{{}log4j-to-jul{}}}.
> So the "opposite" of [https://logging.apache.org/log4j/2.x/log4j-jul/] (from
> [https://github.com/apache/logging-log4j2/tree/master/log4j-jul]). The use
> case here is if one has an existing JUL-based set-up into which you would
> like to see logs from a library that has been coded against the Log4j API.
> Poking around
> [https://github.com/apache/logging-log4j2/tree/master/log4j-to-slf4j/src/main/java/org/apache/logging/slf4j],
> I hope this won't be very hard to do, unless I'm missing something. I want
> log4j-to-jul to only depend on log4j-api and nothing else, notably NOT
> log4j-core.
> Please assign this issue to me so that I can work on this and contribute it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3122) Logging to Log4j2 MongoDb4 Appender get ERROR on trace, debug and info level.
[ https://issues.apache.org/jira/browse/LOG4J2-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464744#comment-17464744 ] Gary D. Gregory commented on LOG4J2-3122: - I can reproduce this with 2.14.1 but NOT with 2.17.0. You should, of course, update ASAP. > Logging to Log4j2 MongoDb4 Appender get ERROR on trace, debug and info level. > - > > Key: LOG4J2-3122 > URL: https://issues.apache.org/jira/browse/LOG4J2-3122 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.14.1 >Reporter: Red Apple >Priority: Blocker > Attachments: log4j2-mongodb4-appender-main.zip > > > Logging to Log4j2 MongoDb4 Appender on trace, debug and info log level give > the following error > *ERROR Recursive call to appender* > but give success result and the log got written to the mongodb database when > using warn or error log level. > Possibly something recursive call happens with info log level that causing > this bug. > [Here is the repository|https://github.com/redapel/log4j2-mongodb4-appender] > that contain the very minimal code to reproduce the error. The configuration > is provided in the *log4j2.xml* file. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3281) PropertiesConfiguration.buildAppender not adding filters to appender
[
https://issues.apache.org/jira/browse/LOG4J2-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464684#comment-17464684
]
Gary D. Gregory commented on LOG4J2-3281:
-
>Did yours produce a different outcome?
Yes, please see org.apache.log4j.config.PropertiesConfigurationTest.testFilter()
> PropertiesConfiguration.buildAppender not adding filters to appender
>
>
> Key: LOG4J2-3281
> URL: https://issues.apache.org/jira/browse/LOG4J2-3281
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
>Affects Versions: 2.17.0
>Reporter: Fábio Constantino
>Priority: Blocker
>
> When building an appender, the _parseAppenderFilters_ method correctly finds
> my custom filter configuration in the properties file, builds it and returns
> it, but the caller ({_}buildAppender{_} method) does nothing with it
> resulting in the appender not having any filters added to it.
>
> This is related to the linked issue -
> [LOG4J2-3247|https://issues.apache.org/jira/browse/LOG4J2-3247] - where the
> scenario is the same (properties file config):
> {code:java}
> log4j1.compatibility=true
> log4j.appender.LOG_REQUEST_START_DB=my.appender.class
> log4j.appender.LOG_REQUEST_START_DB.filter.ID=my.filter.class {code}
> the Filter class I'm working with is the following:
> {code:java}
> import org.apache.log4j.spi.Filter;
> import org.apache.log4j.spi.LoggingEvent;
> public class MonitorFilter extends Filter {
> @Override
> public int decide(LoggingEvent event) {
> String requestId = (String)event.getMDC("requestId");
> if (StringHelper.isNullOrEmpty(requestId))
> return DENY;
>
> if
> (!MonitorScriptManager.getInstance().getMonitorScript().filter(event))
> return DENY;
>
> return ACCEPT;
> }
> } {code}
> I am using the following log4j dependencies:
> {code:java}
>
> org.apache.logging.log4j
> log4j-core
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-api
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-1.2-api
> 2.17.0
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3281) PropertiesConfiguration.buildAppender not adding filters to appender
[
https://issues.apache.org/jira/browse/LOG4J2-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464652#comment-17464652
]
Gary D. Gregory edited comment on LOG4J2-3281 at 12/23/21, 3:38 PM:
[~coredumped]
So far, things look OK based on the new test
{{org.apache.log4j.config.PropertiesConfigurationTest.testFilter()}} in the git
branch {{release-2.x}}.
As of now, there are no difference between 2.17.0 and 2.17.1-SNAPSHOT to
account for this so we need to look for something else.
How do you call Log4j? May you provide a reproducer, either as a GitHub PR or a
standalone Maven project?
was (Author: garydgregory):
[~coredumped]
So far, things look OK based on the new test
{{org.apache.log4j.config.PropertiesConfigurationTest.testFilter()}} in the git
branch {{release-2.x}}.
As of now, there are no difference between 2.17.0 and 2.17.1-SNAPSHOT to
account for this so we need to look for something else.
> PropertiesConfiguration.buildAppender not adding filters to appender
>
>
> Key: LOG4J2-3281
> URL: https://issues.apache.org/jira/browse/LOG4J2-3281
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
>Affects Versions: 2.17.0
>Reporter: Fábio Constantino
>Priority: Blocker
>
> When building an appender, the _parseAppenderFilters_ method correctly finds
> my custom filter configuration in the properties file, builds it and returns
> it, but the caller ({_}buildAppender{_} method) does nothing with it
> resulting in the appender not having any filters added to it.
>
> This is related to the linked issue -
> [LOG4J2-3247|https://issues.apache.org/jira/browse/LOG4J2-3247] - where the
> scenario is the same (properties file config):
> {code:java}
> log4j1.compatibility=true
> log4j.appender.LOG_REQUEST_START_DB=my.appender.class
> log4j.appender.LOG_REQUEST_START_DB.filter.ID=my.filter.class {code}
> the Filter class I'm working with is the following:
> {code:java}
> import org.apache.log4j.spi.Filter;
> import org.apache.log4j.spi.LoggingEvent;
> public class MonitorFilter extends Filter {
> @Override
> public int decide(LoggingEvent event) {
> String requestId = (String)event.getMDC("requestId");
> if (StringHelper.isNullOrEmpty(requestId))
> return DENY;
>
> if
> (!MonitorScriptManager.getInstance().getMonitorScript().filter(event))
> return DENY;
>
> return ACCEPT;
> }
> } {code}
> I am using the following log4j dependencies:
> {code:java}
>
> org.apache.logging.log4j
> log4j-core
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-api
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-1.2-api
> 2.17.0
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3281) PropertiesConfiguration.buildAppender not adding filters to appender
[
https://issues.apache.org/jira/browse/LOG4J2-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464652#comment-17464652
]
Gary D. Gregory commented on LOG4J2-3281:
-
[~coredumped]
So far, things look OK based on the new test
{{org.apache.log4j.config.PropertiesConfigurationTest.testFilter()}} in the git
branch {{release-2.x}}.
As of now, there are no difference between 2.17.0 and 2.17.1-SNAPSHOT to
account for this so we need to look for something else.
> PropertiesConfiguration.buildAppender not adding filters to appender
>
>
> Key: LOG4J2-3281
> URL: https://issues.apache.org/jira/browse/LOG4J2-3281
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
>Affects Versions: 2.17.0
>Reporter: Fábio Constantino
>Priority: Blocker
>
> When building an appender, the _parseAppenderFilters_ method correctly finds
> my custom filter configuration in the properties file, builds it and returns
> it, but the caller ({_}buildAppender{_} method) does nothing with it
> resulting in the appender not having any filters added to it.
>
> This is related to the linked issue -
> [LOG4J2-3247|https://issues.apache.org/jira/browse/LOG4J2-3247] - where the
> scenario is the same (properties file config):
> {code:java}
> log4j1.compatibility=true
> log4j.appender.LOG_REQUEST_START_DB=my.appender.class
> log4j.appender.LOG_REQUEST_START_DB.filter.ID=my.filter.class {code}
> the Filter class I'm working with is the following:
> {code:java}
> import org.apache.log4j.spi.Filter;
> import org.apache.log4j.spi.LoggingEvent;
> public class MonitorFilter extends Filter {
> @Override
> public int decide(LoggingEvent event) {
> String requestId = (String)event.getMDC("requestId");
> if (StringHelper.isNullOrEmpty(requestId))
> return DENY;
>
> if
> (!MonitorScriptManager.getInstance().getMonitorScript().filter(event))
> return DENY;
>
> return ACCEPT;
> }
> } {code}
> I am using the following log4j dependencies:
> {code:java}
>
> org.apache.logging.log4j
> log4j-core
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-api
> 2.17.0
>
>
> org.apache.logging.log4j
> log4j-1.2-api
> 2.17.0
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3247) PropertiesConfiguration.parseAppenderFilters NPE when parsing properties file filters
[
https://issues.apache.org/jira/browse/LOG4J2-3247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464560#comment-17464560
]
Gary D. Gregory commented on LOG4J2-3247:
-
Hi [~coredumped]
Let's keep things cleanly separated in a new ticket since we've fixed this one
issue at least. Please post ALL the information we need in the new ticket like
configuration files, command-line invocation examples, and so on, you can also
"link" the new ticket with the old one which might be handy.
TY for your patience.
Gary
> PropertiesConfiguration.parseAppenderFilters NPE when parsing properties file
> filters
> -
>
> Key: LOG4J2-3247
> URL: https://issues.apache.org/jira/browse/LOG4J2-3247
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
>Affects Versions: 2.16.0
>Reporter: Fábio Constantino
>Priority: Blocker
> Fix For: 2.17.1
>
>
> When parsing appender filters configured in the properties file for example:
> {code:java}
> log4j.appender.LOG_REQUEST_START_DB=my.appender.class
> log4j.appender.LOG_REQUEST_START_DB.filter.ID=my.filter.class{code}
> a NullPointerException is thrown on line 564 of
> org.apache.log4j.config.PropertiesConfiguration. The _next_ variable is
> always _null_ at that point, from what appears to be a bug in the _if_
> condition above (looks like it should be _head == null_ instead of {_}head !=
> null{_}).
>
> Note: this is using the log4j1.compatibility=true property
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3251) Weblookup ${web:rootDir} is not working if old loggercontext is removed and tried to initialize loggerContext using Configurator.initialize
[
https://issues.apache.org/jira/browse/LOG4J2-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464000#comment-17464000
]
Gary D. Gregory commented on LOG4J2-3251:
-
If you get an NPE, it would be nice to have it FTR.
> Weblookup ${web:rootDir} is not working if old loggercontext is removed and
> tried to initialize loggerContext using Configurator.initialize
> ---
>
> Key: LOG4J2-3251
> URL: https://issues.apache.org/jira/browse/LOG4J2-3251
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
>Affects Versions: 2.15.0, 2.16.0
>Reporter: Sankalp
>Priority: Blocker
> Labels: weblookup
> Attachments: console.log
>
>
> In a web application, I am first creating a loggerContext and it log4j.xml
> has ${web:rootDir} for lookup. It is resolved as expected.
> I am removing the older loggerContext and using
> Configurator.initialize(contextName, classlodaer, filePaths, context). This
> API fails and I can observe that inside weblookup it is NOT getting
> servletContext. Below API returns null.
> *ServletContext ctx = WebLoggerContextUtils.getServletContext();*
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3273) Upgrade to Log4j 2.17
[ https://issues.apache.org/jira/browse/LOG4J2-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated LOG4J2-3273: Issue Type: Question (was: Bug) > Upgrade to Log4j 2.17 > - > > Key: LOG4J2-3273 > URL: https://issues.apache.org/jira/browse/LOG4J2-3273 > Project: Log4j 2 > Issue Type: Question > Environment: PRODUCTION >Reporter: Rounal Mudhoo >Priority: Critical > Fix For: 2.17.0 > > > Hello Team, > > We currently have the log4j version 1.x.x and 2.13.3. > We would like to upgrade to the latest version. > > Can you please advise us and share the steps how to perform same ? > > Thanks and Kind Regards, > Rounal -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3274) Log4j2 deadlock version 2.16
[
https://issues.apache.org/jira/browse/LOG4J2-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463916#comment-17463916
]
Gary D. Gregory commented on LOG4J2-3274:
-
Hi [~faskan]
Please consider updating from 2.16.0 to 2.17.0, I think this will make
debugging simpler for all involved.
> Log4j2 deadlock version 2.16
>
>
> Key: LOG4J2-3274
> URL: https://issues.apache.org/jira/browse/LOG4J2-3274
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Faisal Khan Thayub Khan
>Priority: Major
>
> My application is a sprint boot application that uses log4j2 and runs in a
> Wildfly server. After the zero day attack, we upgraded to the latest log4j2
> version(2.16). But after the log4j upgrade, my application stops working once
> in a while. And when I looked at the threaddumps, I found that there is a
> deadlock created by log4j.
> When analysing this issue, I came through a possible defect in log4j code.
> Not sure if that can result in a deadlock.
> *Log4J possible bug* - As per the release notes, there was a fix to {*}Enable
> immediate flush on RollingFileAppender when buffered i/o is not enabled.
> (LOG4J2-3114){*}. But the code just does the opposite in
> {*}RollingFileAppenderBuilder{*}.
> It should have been {{{}if(!bufferedIo) \{ immediateFlush = true; }{{.
> And one of my appender explicitly sets bufferedIo value to true. I know that
> log4j does a bufferedio by default and it is not necessary to set this flag
> explicitly. But unfortunately the code that I am working on is a legacy code
> and the configuration was working fine before the upgrade.
> {{I have added my log4j configuration in here
> [https://stackoverflow.com/questions/70450611/log4j2-deadlock]}}
>
> *Extract from Thread dump:*
> "default task-128" #450 prio=5 os_prio=0 tid=0x7f31f80cf800 nid=0x14c8
> waiting for monitor entry [0x7f31a7d88000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.logging.log4j.core.appender.OutputStreamManager.writeBytes(OutputStreamManager.java:352)
> - waiting to lock <0xc0e70eb0> (a
> org.apache.logging.log4j.core.appender.OutputStreamManager)
> at
> org.apache.logging.log4j.core.layout.TextEncoderHelper.writeEncodedText(TextEncoderHelper.java:96)
> at
> org.apache.logging.log4j.core.layout.TextEncoderHelper.encodeText(TextEncoderHelper.java:65)
> at
> org.apache.logging.log4j.core.layout.StringBuilderEncoder.encode(StringBuilderEncoder.java:68)
> at
> org.apache.logging.log4j.core.layout.StringBuilderEncoder.encode(StringBuilderEncoder.java:32)
> at
> org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:228)
> at
> org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:60)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.directEncodeEvent(AbstractOutputStreamAppender.java:197)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.tryAppend(AbstractOutputStreamAppender.java:190)
> at
> org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:181)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:161)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:134)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:125)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:89)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:542)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:500)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:483)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.logParent(LoggerConfig.java:533)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:502)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:483)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:388)
> at
> org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:63)
> at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:153)
> at org.apache.logging.slf4j.Log4jLogger.log(Log4jLogger.java:376)
> at
> org.apache.commons.logging.impl.SLF4JLocationAwareLog.error(SLF4JLocationAwareLog.java:203)
> at
> org.springframework.boot.web.support.ErrorPageFilter.handleCommittedResponse(ErrorPageFilter.java:225)
--
This message was sent by Atlassian Jira
[jira] [Commented] (LOG4J2-3271) When compiling 2.17.0 java8 error
[ https://issues.apache.org/jira/browse/LOG4J2-3271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463809#comment-17463809 ] Gary D. Gregory commented on LOG4J2-3271: - That's right, you need both Java 8 and 11 installed and a Maven toolchain file defined. Strictly speaking, Java 9 would do instead of 11, but 11 is LTS and 9 is not. > When compiling 2.17.0 java8 error > - > > Key: LOG4J2-3271 > URL: https://issues.apache.org/jira/browse/LOG4J2-3271 > Project: Log4j 2 > Issue Type: Bug > Components: Build >Affects Versions: 2.17.0 >Reporter: slava >Priority: Major > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile > (default-compile) on project log4j-core: Compilation failure > [ERROR] > /builddir/build/BUILD/apache-log4j-2.17.0-src/log4j-core/src/main/java/org/apache/logging/log4j/core/async/DisruptorUtil.java:[76,23] > error: no suitable constructor found for SleepingWaitStrategy(int,long) > [ERROR] constructor SleepingWaitStrategy.SleepingWaitStrategy() is not > applicable > [ERROR] (actual and formal argument lists differ in length) > [ERROR] constructor SleepingWaitStrategy.SleepingWaitStrategy(int) is not > applicable > [ERROR] (actual and formal argument lists differ in length) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3271) When compiling 2.17.0 java8 error
[ https://issues.apache.org/jira/browse/LOG4J2-3271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463781#comment-17463781 ] Gary D. Gregory commented on LOG4J2-3271: - Building from sources is described on our page [https://logging.apache.org/log4j/2.x/build.html] > When compiling 2.17.0 java8 error > - > > Key: LOG4J2-3271 > URL: https://issues.apache.org/jira/browse/LOG4J2-3271 > Project: Log4j 2 > Issue Type: Bug > Components: Build >Affects Versions: 2.17.0 >Reporter: slava >Priority: Major > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile > (default-compile) on project log4j-core: Compilation failure > [ERROR] > /builddir/build/BUILD/apache-log4j-2.17.0-src/log4j-core/src/main/java/org/apache/logging/log4j/core/async/DisruptorUtil.java:[76,23] > error: no suitable constructor found for SleepingWaitStrategy(int,long) > [ERROR] constructor SleepingWaitStrategy.SleepingWaitStrategy() is not > applicable > [ERROR] (actual and formal argument lists differ in length) > [ERROR] constructor SleepingWaitStrategy.SleepingWaitStrategy(int) is not > applicable > [ERROR] (actual and formal argument lists differ in length) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3243) Property log4j.configurationFile incorrectly documented, log4j.configuration missing
[ https://issues.apache.org/jira/browse/LOG4J2-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463467#comment-17463467 ] Gary D. Gregory commented on LOG4J2-3243: - [~lordjaxom] The question is: Are you suggesting a code change or a documentation change? You do not need to test a documentation change. > Property log4j.configurationFile incorrectly documented, log4j.configuration > missing > > > Key: LOG4J2-3243 > URL: https://issues.apache.org/jira/browse/LOG4J2-3243 > Project: Log4j 2 > Issue Type: Documentation > Components: Configuration >Affects Versions: 2.16.0 >Reporter: Sascha Volkenandt >Priority: Minor > > According to [1], Log4j looks for the system property > log4j2.configurationFile. According to the sources of log4j-core-2.16.0 > (ConfigurationFactory.java), the searched property is > log4j.configurationFile. The other property does not seem to have any effect > in recent versions. > [1] [https://logging.apache.org/log4j/2.x/manual/configuration.html] > Additionally, since 2.14.0 it looks for the property log4j.configuration (no > "File"), which was also the property used by Log4j 1.x. As a consequence, > logging stopped working in some of our systems after upgrading to 2.16.0 due > to Log4Shell. Those systems are using both 1.x and 2.x so they have the > property log4j.configuration set but not log4j.configurationFile, because we > relied on the previous behaviour that if log4j.configurationFile is not set > it looks in the classpath. I had to use a debugger to find out why it stopped > working. > It would be nice if that second property would also be mentioned in [1]. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3258) RollingFile fileName containing variables does not work on 2.17.0
[
https://issues.apache.org/jira/browse/LOG4J2-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463463#comment-17463463
]
Gary D. Gregory commented on LOG4J2-3258:
-
Hi [~ckozak]
I think it might be clearer to define the map before the table so you do not
have to repeat property = "Hello" all over.
> RollingFile fileName containing variables does not work on 2.17.0
> -
>
> Key: LOG4J2-3258
> URL: https://issues.apache.org/jira/browse/LOG4J2-3258
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.0
> Environment: Java 17, Ubuntu 20.04.
>Reporter: Konstantinos Liakos
>Priority: Major
> Attachments: log4j2-appender-routing.xml, log4j2.xml
>
>
> A configuration like the below has stopped working since 2.17.0. The
> variables that originate from are not resolved to their actual
> values.
> {code:xml}
> $${env:LOGS_DIRECTORY} {code}
> {code:xml}
> fileName="${logs_dir}/${ctx:logFile}"{code}
>
> Works fine on 2.16.0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3243) Property log4j.configurationFile incorrectly documented, log4j.configuration missing
[ https://issues.apache.org/jira/browse/LOG4J2-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463443#comment-17463443 ] Gary D. Gregory commented on LOG4J2-3243: - A PR that changes code includes a unit test to prove that the main changes actual fix the issue. > Property log4j.configurationFile incorrectly documented, log4j.configuration > missing > > > Key: LOG4J2-3243 > URL: https://issues.apache.org/jira/browse/LOG4J2-3243 > Project: Log4j 2 > Issue Type: Documentation > Components: Configuration >Affects Versions: 2.16.0 >Reporter: Sascha Volkenandt >Priority: Minor > > According to [1], Log4j looks for the system property > log4j2.configurationFile. According to the sources of log4j-core-2.16.0 > (ConfigurationFactory.java), the searched property is > log4j.configurationFile. The other property does not seem to have any effect > in recent versions. > [1] [https://logging.apache.org/log4j/2.x/manual/configuration.html] > Additionally, since 2.14.0 it looks for the property log4j.configuration (no > "File"), which was also the property used by Log4j 1.x. As a consequence, > logging stopped working in some of our systems after upgrading to 2.16.0 due > to Log4Shell. Those systems are using both 1.x and 2.x so they have the > property log4j.configuration set but not log4j.configurationFile, because we > relied on the previous behaviour that if log4j.configurationFile is not set > it looks in the classpath. I had to use a debugger to find out why it stopped > working. > It would be nice if that second property would also be mentioned in [1]. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-2439) xEx{n} broken- Stacktraces are not limited by size - on ExtendedThrowablePatternConverter
[
https://issues.apache.org/jira/browse/LOG4J2-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463353#comment-17463353
]
Gary D. Gregory commented on LOG4J2-2439:
-
May you provide a PR with a test on GitHub?
> xEx{n} broken- Stacktraces are not limited by size - on
> ExtendedThrowablePatternConverter
> -
>
> Key: LOG4J2-2439
> URL: https://issues.apache.org/jira/browse/LOG4J2-2439
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.11.1
>Reporter: Georgios Mournos
>Priority: Major
> Attachments: TestStack.zip
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> I upgraded from log4j-core-2.8.2 to log4j-core-2.11.1 and stacktraces in the
> logs got very long. My xEx\{3} pattern is not working anymore.
> Seems that when ExtendedThrowablePatternConverter calls ThrowableProxy, it
> does not pass the number of lines to restrict the stacktrace.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3255) Performance Benchmarking shows 20% degradation in FileAppenderBenchmark.log4j2file between Log4j2 v2.12.0 & v2.16.0
[ https://issues.apache.org/jira/browse/LOG4J2-3255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463334#comment-17463334 ] Gary D. Gregory commented on LOG4J2-3255: - [~vikrambe] Please do test on 2.17.0. G > Performance Benchmarking shows 20% degradation in > FileAppenderBenchmark.log4j2file between Log4j2 v2.12.0 & v2.16.0 > - > > Key: LOG4J2-3255 > URL: https://issues.apache.org/jira/browse/LOG4J2-3255 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.16.0 > Environment: Mac > # JMH version: 1.21 > # VM version: JDK 9, OpenJDK 64-Bit Server VM, 9+181 > # VM invoker: > /Library/Java/JavaVirtualMachines/adoptopenjdk-9.jdk/Contents/Home/bin/java > # VM options: --add-exports=java.base/jdk.internal.ref=ALL-UNNAMED > # Warmup: 10 iterations, 10 s each > # Measurement: 20 iterations, 10 s each > # Timeout: 10 min per iteration > # Threads: 1 thread, will synchronize iterations > # Benchmark mode: Throughput, ops/time > # Benchmark: > org.apache.logging.log4j.perf.jmh.FileAppenderBenchmark.log4j2file >Reporter: Kranti Vikram >Priority: Major > Attachments: Screenshot 2021-12-17 at 9.39.13 PM.png > > > Performance Benchmarking shows 20% degradation in > FileAppenderBenchmark.log4j2file between Log4j2 v2.12.0 & v2.16.0 > > |Benchmark|2.12.0 op/sec|2.16.0 op/sec| > |FileAppenderBenchmark.log4j2File|84115.661|68789.212| > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3269) Method To Find Log4j Version on Windows Servers
[ https://issues.apache.org/jira/browse/LOG4J2-3269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463300#comment-17463300 ] Gary D. Gregory commented on LOG4J2-3269: - This is not a Windows support forum ;) > Method To Find Log4j Version on Windows Servers > --- > > Key: LOG4J2-3269 > URL: https://issues.apache.org/jira/browse/LOG4J2-3269 > Project: Log4j 2 > Issue Type: Question > Components: Log4j-Audit >Affects Versions: 2.14.1 >Reporter: Ciaran Byrne >Priority: Major > Fix For: 2.14.1 > > > Is there a quick way to find the log4j version that's installed on Windows > servers (we're trying to discover which servers are at risk from the recent > vulnerability)? We're currently trying to find a sure-fire way find this out > and have so far drawn a blank. Any ideas? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3268) do we have any work arround for issue LOG4J2-3230 for existing library.
[ https://issues.apache.org/jira/browse/LOG4J2-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463298#comment-17463298 ] Gary D. Gregory commented on LOG4J2-3268: - You MUST update to 2.17.0 to get full mitigation. > do we have any work arround for issue LOG4J2-3230 for existing library. > --- > > Key: LOG4J2-3268 > URL: https://issues.apache.org/jira/browse/LOG4J2-3268 > Project: Log4j 2 > Issue Type: Bug >Reporter: Rajendra Rathore >Priority: Minor > > do we have any work around for issue LOG4J2-3230 for existing library. I > tried setting environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS=true and it > working fine, is it valid workaround for old library, can you pls confirm? We > are on 2.14.0 version and set the property. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3269) Method To Find Log4j Version on Windows Servers
[ https://issues.apache.org/jira/browse/LOG4J2-3269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463296#comment-17463296 ] Gary D. Gregory commented on LOG4J2-3269: - Search for files that start with "log4j-" and have the ".jar" extension. If you suspect some jar files are shadded or uber jars then you will need to search inside those jar files (which are in fact zip files) for Log4j class files. If you have war files, you should look inside those files (also a zip file) for log4j files. > Method To Find Log4j Version on Windows Servers > --- > > Key: LOG4J2-3269 > URL: https://issues.apache.org/jira/browse/LOG4J2-3269 > Project: Log4j 2 > Issue Type: Question > Components: Log4j-Audit >Affects Versions: 2.14.1 >Reporter: Ciaran Byrne >Priority: Major > Fix For: 2.14.1 > > > Is there a quick way to find the log4j version that's installed on Windows > servers (we're trying to discover which servers are at risk from the recent > vulnerability)? We're currently trying to find a sure-fire way find this out > and have so far drawn a blank. Any ideas? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3230) Certain strings can cause infinite recursion
[
https://issues.apache.org/jira/browse/LOG4J2-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463290#comment-17463290
]
Gary D. Gregory commented on LOG4J2-3230:
-
[~rgoers] edit "If you use 2.31.," -> "If you use 2.3.1,"
> Certain strings can cause infinite recursion
>
>
> Key: LOG4J2-3230
> URL: https://issues.apache.org/jira/browse/LOG4J2-3230
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 2.11.0, 2.11.1,
> 2.11.2, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.13.2, 2.14.0, 2.13.3, 2.14.1,
> 2.15.0, 2.16.0
>Reporter: Ross Cohen
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.0
>
> Attachments: sample.tar.gz
>
>
> If a string substitution is attempted for any reason on the following string,
> it will trigger an infinite recursion, and the application will crash:
> ${${::\-${::\-$${::\-j.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3230) Certain strings can cause infinite recursion
[
https://issues.apache.org/jira/browse/LOG4J2-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17462721#comment-17462721
]
Gary D. Gregory commented on LOG4J2-3230:
-
[~pmalone]
I understand your position as I am dealing similar issues! As you can imagine,
I am short on time ATM so I'd rather simply refer to 2.17.0 than spend time on
what can and can't happen on a now old version when I know a newer version
provides the better mitigation.
> Certain strings can cause infinite recursion
>
>
> Key: LOG4J2-3230
> URL: https://issues.apache.org/jira/browse/LOG4J2-3230
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 2.11.0, 2.11.1,
> 2.11.2, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.13.2, 2.14.0, 2.13.3, 2.14.1,
> 2.15.0, 2.16.0
>Reporter: Ross Cohen
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.0
>
> Attachments: sample.tar.gz
>
>
> If a string substitution is attempted for any reason on the following string,
> it will trigger an infinite recursion, and the application will crash:
> ${${::\-${::\-$${::\-j.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3258) RollingFile fileName containing variables does not work on 2.17.0
[
https://issues.apache.org/jira/browse/LOG4J2-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17462701#comment-17462701
]
Gary D. Gregory commented on LOG4J2-3258:
-
Ouch, if we broke user's configuration files we better document that clearly
with how users are suppose to update their files.
> RollingFile fileName containing variables does not work on 2.17.0
> -
>
> Key: LOG4J2-3258
> URL: https://issues.apache.org/jira/browse/LOG4J2-3258
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.17.0
> Environment: Java 17, Ubuntu 20.04.
>Reporter: Konstantinos Liakos
>Priority: Major
>
> A configuration like the below has stopped working since 2.17.0. The
> variables that originate from are not resolved to their actual
> values.
> {code:xml}
> $${env:LOGS_DIRECTORY} {code}
> {code:xml}
> fileName="${logs_dir}/${ctx:logFile}"{code}
>
> Works fine on 2.16.0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3230) Certain strings can cause infinite recursion
[
https://issues.apache.org/jira/browse/LOG4J2-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17462699#comment-17462699
]
Gary D. Gregory commented on LOG4J2-3230:
-
[~pmalone]
Just update to 2.17.0 where JNDI is completely disabled by default and you get
the latest fixes.
> Certain strings can cause infinite recursion
>
>
> Key: LOG4J2-3230
> URL: https://issues.apache.org/jira/browse/LOG4J2-3230
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 2.11.0, 2.11.1,
> 2.11.2, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.13.2, 2.14.0, 2.13.3, 2.14.1,
> 2.15.0, 2.16.0
>Reporter: Ross Cohen
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.17.0
>
> Attachments: sample.tar.gz
>
>
> If a string substitution is attempted for any reason on the following string,
> it will trigger an infinite recursion, and the application will crash:
> ${${::\-${::\-$${::\-j.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3257) MDC class in 2.17.0 has multiple "put" methods
[
https://issues.apache.org/jira/browse/LOG4J2-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17462218#comment-17462218
]
Gary D. Gregory commented on LOG4J2-3257:
-
This class has not changed its API signature in our {{log4j-1.2-api}} jar 10
years which is when the {{put(String, String)}} method was added, so you have
something else going on.
You likely have some other jar files on your classpath like a log4j 1.x jar
file before {{log4j-1.2-api}}.
> MDC class in 2.17.0 has multiple "put" methods
> --
>
> Key: LOG4J2-3257
> URL: https://issues.apache.org/jira/browse/LOG4J2-3257
> Project: Log4j 2
> Issue Type: Bug
> Components: log4j 1.2 emulation
>Affects Versions: 2.17.0
>Reporter: Mike
>Priority: Major
>
> We use MDC.put for a variety of things. With the 2.17 version, it appears
> there is a bug.
> When including the jar from maven, we can see the following:
>
> {code:java}
> private MDC() {
> }
> public static void put(final String key, final String value) {
> localMap.get().put(key, value);
> ThreadContext.put(key, value);
> }
> public static void put(final String key, final Object value) {
> localMap.get().put(key, value);
> ThreadContext.put(key, value.toString());
> } {code}
> Java is very unhappy when trying to call this, and causes problems in our
> application.
> The error we are getting is:
> {code:java}
> SEVERE: Servlet.service() for servlet [default] in context with path [] threw
> exception [Filter execution threw an exception] with root cause
> java.lang.NoSuchMethodError:
> org.apache.log4j.MDC.put(Ljava/lang/String;Ljava/lang/String;)V {code}
> I have reverted back to 2.16.0 for the time being and we aren't having
> problems.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Deleted] (LOG4J2-3253) demo
[ https://issues.apache.org/jira/browse/LOG4J2-3253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory deleted LOG4J2-3253: > demo > > > Key: LOG4J2-3253 > URL: https://issues.apache.org/jira/browse/LOG4J2-3253 > Project: Log4j 2 > Issue Type: Bug >Reporter: Marton >Priority: Major > > test -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3237) Log4j 1.2 bridge API hard codes the Syslog protocol to TCP
[
https://issues.apache.org/jira/browse/LOG4J2-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LOG4J2-3237:
Summary: Log4j 1.2 bridge API hard codes the Syslog protocol to TCP (was:
Log4j 1.2 bridge API hard codes protocol to TCP)
> Log4j 1.2 bridge API hard codes the Syslog protocol to TCP
> --
>
> Key: LOG4J2-3237
> URL: https://issues.apache.org/jira/browse/LOG4J2-3237
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Appenders
>Affects Versions: 2.16.0
> Environment: *JDK .1.8 :-*
> copy-jdk-configs-3.3-10.el7_5.noarch
> java-1.8.0-openjdk-1.8.0.242.b08-0.el7_7.i686
> java-1.8.0-openjdk-devel-1.8.0.242.b08-0.el7_7.i686
> java-1.8.0-openjdk-headless-1.8.0.242.b08-0.el7_7.i686
> *JVM arguments :-*
> *-Dlog4j1.compatibility=true -jar*
> *Jar used :-*
> log4j-1.2-api-2.16.0.jar
> log4j-api-2.16.0.jar
> log4j-core-2.16.0.jar
>Reporter: Tukesh
>Assignee: Gary D. Gregory
>Priority: Blocker
> Fix For: 2.16.1
>
>
> *Log4j 1.2 bridge API hard codes protocol to TCP and host address and port to
> localhost:514*
>
>
> *-Dlog4j1.compatibility=true -jar*
> *backtrace* :-
>
>
> {code:java}
> 2021-12-16 00:35:32,904 main ERROR TcpSocketManager (TCP:localhost:514)
> caught exception and will continue: java.io.IOException: Unable to create
> socket for localhost at port 514 using ip addresses and ports ,
> 0:0:0:0:0:0:0:1:514
> at
> org.apache.logging.log4j.core.net.TcpSocketManager$TcpSocketManagerFactory.createSocket(TcpSocketManager.java:509)
> at
> org.apache.logging.log4j.core.net.TcpSocketManager$TcpSocketManagerFactory.createManager(TcpSocketManager.java:478)
> at
> org.apache.logging.log4j.core.net.TcpSocketManager$TcpSocketManagerFactory.createManager(TcpSocketManager.java:459)
> at
> org.apache.logging.log4j.core.appender.AbstractManager.getManager(AbstractManager.java:113)
> at
> org.apache.logging.log4j.core.appender.OutputStreamManager.getManager(OutputStreamManager.java:100)
> at
> org.apache.logging.log4j.core.net.TcpSocketManager.getSocketManager(TcpSocketManager.java:202)
> at
> org.apache.logging.log4j.core.appender.SocketAppender.createSocketManager(SocketAppender.java:443)
> at
> org.apache.logging.log4j.core.appender.SocketAppender$Builder.build(SocketAppender.java:221)
> at
> org.apache.log4j.builders.appender.SyslogAppenderBuilder.createAppender(SyslogAppenderBuilder.java:150)
> at
> org.apache.log4j.builders.appender.SyslogAppenderBuilder.parseAppender(SyslogAppenderBuilder.java:121)
> at
> org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:76)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:427)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:405)
> at
> org.apache.log4j.config.PropertiesConfiguration.configureRoot(PropertiesConfiguration.java:325)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:302)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:92)
> at
> org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:59)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:289)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:626)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
> at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:309)
> at org.apache.log4j.Logger$PrivateManager.getContext(Logger.java:59)
> at org.apache.log4j.Logger.getLogger(Logger.java:37)
> at test.logger.Example.(Example.java:12)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at
[jira] [Resolved] (LOG4J2-3237) Log4j 1.2 bridge API hard codes protocol to TCP
[
https://issues.apache.org/jira/browse/LOG4J2-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LOG4J2-3237.
-
Fix Version/s: 2.16.1
Resolution: Fixed
In git branch {{{}release-2.x{}}}.
> Log4j 1.2 bridge API hard codes protocol to TCP
> ---
>
> Key: LOG4J2-3237
> URL: https://issues.apache.org/jira/browse/LOG4J2-3237
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Appenders
>Affects Versions: 2.16.0
> Environment: *JDK .1.8 :-*
> copy-jdk-configs-3.3-10.el7_5.noarch
> java-1.8.0-openjdk-1.8.0.242.b08-0.el7_7.i686
> java-1.8.0-openjdk-devel-1.8.0.242.b08-0.el7_7.i686
> java-1.8.0-openjdk-headless-1.8.0.242.b08-0.el7_7.i686
> *JVM arguments :-*
> *-Dlog4j1.compatibility=true -jar*
> *Jar used :-*
> log4j-1.2-api-2.16.0.jar
> log4j-api-2.16.0.jar
> log4j-core-2.16.0.jar
>Reporter: Tukesh
>Assignee: Gary D. Gregory
>Priority: Blocker
> Fix For: 2.16.1
>
>
> *Log4j 1.2 bridge API hard codes protocol to TCP and host address and port to
> localhost:514*
>
>
> *-Dlog4j1.compatibility=true -jar*
> *backtrace* :-
>
>
> {code:java}
> 2021-12-16 00:35:32,904 main ERROR TcpSocketManager (TCP:localhost:514)
> caught exception and will continue: java.io.IOException: Unable to create
> socket for localhost at port 514 using ip addresses and ports ,
> 0:0:0:0:0:0:0:1:514
> at
> org.apache.logging.log4j.core.net.TcpSocketManager$TcpSocketManagerFactory.createSocket(TcpSocketManager.java:509)
> at
> org.apache.logging.log4j.core.net.TcpSocketManager$TcpSocketManagerFactory.createManager(TcpSocketManager.java:478)
> at
> org.apache.logging.log4j.core.net.TcpSocketManager$TcpSocketManagerFactory.createManager(TcpSocketManager.java:459)
> at
> org.apache.logging.log4j.core.appender.AbstractManager.getManager(AbstractManager.java:113)
> at
> org.apache.logging.log4j.core.appender.OutputStreamManager.getManager(OutputStreamManager.java:100)
> at
> org.apache.logging.log4j.core.net.TcpSocketManager.getSocketManager(TcpSocketManager.java:202)
> at
> org.apache.logging.log4j.core.appender.SocketAppender.createSocketManager(SocketAppender.java:443)
> at
> org.apache.logging.log4j.core.appender.SocketAppender$Builder.build(SocketAppender.java:221)
> at
> org.apache.log4j.builders.appender.SyslogAppenderBuilder.createAppender(SyslogAppenderBuilder.java:150)
> at
> org.apache.log4j.builders.appender.SyslogAppenderBuilder.parseAppender(SyslogAppenderBuilder.java:121)
> at
> org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:76)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:427)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:405)
> at
> org.apache.log4j.config.PropertiesConfiguration.configureRoot(PropertiesConfiguration.java:325)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:302)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:92)
> at
> org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:59)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:289)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:626)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
> at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:309)
> at org.apache.log4j.Logger$PrivateManager.getContext(Logger.java:59)
> at org.apache.log4j.Logger.getLogger(Logger.java:37)
> at test.logger.Example.(Example.java:12)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:607)
> at
>
[jira] [Updated] (LOG4J2-3237) Log4j 1.2 bridge API hard codes protocol to TCP
[
https://issues.apache.org/jira/browse/LOG4J2-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LOG4J2-3237:
Summary: Log4j 1.2 bridge API hard codes protocol to TCP (was: Log4j 1.2
bridge API hard codes protocol to TCP and host address and port to
localhost:514)
> Log4j 1.2 bridge API hard codes protocol to TCP
> ---
>
> Key: LOG4J2-3237
> URL: https://issues.apache.org/jira/browse/LOG4J2-3237
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Appenders
>Affects Versions: 2.16.0
> Environment: *JDK .1.8 :-*
> copy-jdk-configs-3.3-10.el7_5.noarch
> java-1.8.0-openjdk-1.8.0.242.b08-0.el7_7.i686
> java-1.8.0-openjdk-devel-1.8.0.242.b08-0.el7_7.i686
> java-1.8.0-openjdk-headless-1.8.0.242.b08-0.el7_7.i686
> *JVM arguments :-*
> *-Dlog4j1.compatibility=true -jar*
> *Jar used :-*
> log4j-1.2-api-2.16.0.jar
> log4j-api-2.16.0.jar
> log4j-core-2.16.0.jar
>Reporter: Tukesh
>Assignee: Gary D. Gregory
>Priority: Blocker
>
> *Log4j 1.2 bridge API hard codes protocol to TCP and host address and port to
> localhost:514*
>
>
> *-Dlog4j1.compatibility=true -jar*
> *backtrace* :-
>
>
> {code:java}
> 2021-12-16 00:35:32,904 main ERROR TcpSocketManager (TCP:localhost:514)
> caught exception and will continue: java.io.IOException: Unable to create
> socket for localhost at port 514 using ip addresses and ports ,
> 0:0:0:0:0:0:0:1:514
> at
> org.apache.logging.log4j.core.net.TcpSocketManager$TcpSocketManagerFactory.createSocket(TcpSocketManager.java:509)
> at
> org.apache.logging.log4j.core.net.TcpSocketManager$TcpSocketManagerFactory.createManager(TcpSocketManager.java:478)
> at
> org.apache.logging.log4j.core.net.TcpSocketManager$TcpSocketManagerFactory.createManager(TcpSocketManager.java:459)
> at
> org.apache.logging.log4j.core.appender.AbstractManager.getManager(AbstractManager.java:113)
> at
> org.apache.logging.log4j.core.appender.OutputStreamManager.getManager(OutputStreamManager.java:100)
> at
> org.apache.logging.log4j.core.net.TcpSocketManager.getSocketManager(TcpSocketManager.java:202)
> at
> org.apache.logging.log4j.core.appender.SocketAppender.createSocketManager(SocketAppender.java:443)
> at
> org.apache.logging.log4j.core.appender.SocketAppender$Builder.build(SocketAppender.java:221)
> at
> org.apache.log4j.builders.appender.SyslogAppenderBuilder.createAppender(SyslogAppenderBuilder.java:150)
> at
> org.apache.log4j.builders.appender.SyslogAppenderBuilder.parseAppender(SyslogAppenderBuilder.java:121)
> at
> org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:76)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:427)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:405)
> at
> org.apache.log4j.config.PropertiesConfiguration.configureRoot(PropertiesConfiguration.java:325)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:302)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:92)
> at
> org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:59)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:289)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:626)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
> at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:309)
> at org.apache.log4j.Logger$PrivateManager.getContext(Logger.java:59)
> at org.apache.log4j.Logger.getLogger(Logger.java:37)
> at test.logger.Example.(Example.java:12)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:607)
> at
>
[jira] [Assigned] (LOG4J2-3237) Log4j 1.2 bridge API hard codes protocol to TCP and host address and port to localhost:514
[
https://issues.apache.org/jira/browse/LOG4J2-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory reassigned LOG4J2-3237:
---
Assignee: Gary D. Gregory
> Log4j 1.2 bridge API hard codes protocol to TCP and host address and port to
> localhost:514
> --
>
> Key: LOG4J2-3237
> URL: https://issues.apache.org/jira/browse/LOG4J2-3237
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Appenders
>Affects Versions: 2.16.0
> Environment: *JDK .1.8 :-*
> copy-jdk-configs-3.3-10.el7_5.noarch
> java-1.8.0-openjdk-1.8.0.242.b08-0.el7_7.i686
> java-1.8.0-openjdk-devel-1.8.0.242.b08-0.el7_7.i686
> java-1.8.0-openjdk-headless-1.8.0.242.b08-0.el7_7.i686
> *JVM arguments :-*
> *-Dlog4j1.compatibility=true -jar*
> *Jar used :-*
> log4j-1.2-api-2.16.0.jar
> log4j-api-2.16.0.jar
> log4j-core-2.16.0.jar
>Reporter: Tukesh
>Assignee: Gary D. Gregory
>Priority: Blocker
>
> *Log4j 1.2 bridge API hard codes protocol to TCP and host address and port to
> localhost:514*
>
>
> *-Dlog4j1.compatibility=true -jar*
> *backtrace* :-
>
>
> {code:java}
> 2021-12-16 00:35:32,904 main ERROR TcpSocketManager (TCP:localhost:514)
> caught exception and will continue: java.io.IOException: Unable to create
> socket for localhost at port 514 using ip addresses and ports ,
> 0:0:0:0:0:0:0:1:514
> at
> org.apache.logging.log4j.core.net.TcpSocketManager$TcpSocketManagerFactory.createSocket(TcpSocketManager.java:509)
> at
> org.apache.logging.log4j.core.net.TcpSocketManager$TcpSocketManagerFactory.createManager(TcpSocketManager.java:478)
> at
> org.apache.logging.log4j.core.net.TcpSocketManager$TcpSocketManagerFactory.createManager(TcpSocketManager.java:459)
> at
> org.apache.logging.log4j.core.appender.AbstractManager.getManager(AbstractManager.java:113)
> at
> org.apache.logging.log4j.core.appender.OutputStreamManager.getManager(OutputStreamManager.java:100)
> at
> org.apache.logging.log4j.core.net.TcpSocketManager.getSocketManager(TcpSocketManager.java:202)
> at
> org.apache.logging.log4j.core.appender.SocketAppender.createSocketManager(SocketAppender.java:443)
> at
> org.apache.logging.log4j.core.appender.SocketAppender$Builder.build(SocketAppender.java:221)
> at
> org.apache.log4j.builders.appender.SyslogAppenderBuilder.createAppender(SyslogAppenderBuilder.java:150)
> at
> org.apache.log4j.builders.appender.SyslogAppenderBuilder.parseAppender(SyslogAppenderBuilder.java:121)
> at
> org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:76)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:427)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:405)
> at
> org.apache.log4j.config.PropertiesConfiguration.configureRoot(PropertiesConfiguration.java:325)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:302)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:92)
> at
> org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:59)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:289)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:626)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
> at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:309)
> at org.apache.log4j.Logger$PrivateManager.getContext(Logger.java:59)
> at org.apache.log4j.Logger.getLogger(Logger.java:37)
> at test.logger.Example.(Example.java:12)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:607)
> at
>
[jira] [Commented] (LOG4J2-3237) Log4j 1.2 bridge API hard codes protocol to TCP and host address and port to localhost:514
[
https://issues.apache.org/jira/browse/LOG4J2-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461126#comment-17461126
]
Gary D. Gregory commented on LOG4J2-3237:
-
Your configuration file uses port 514 so you must be reporting that the
protocol is hardcoded (which it is), not the port.
> Log4j 1.2 bridge API hard codes protocol to TCP and host address and port to
> localhost:514
> --
>
> Key: LOG4J2-3237
> URL: https://issues.apache.org/jira/browse/LOG4J2-3237
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Appenders
>Affects Versions: 2.16.0
> Environment: *JDK .1.8 :-*
> copy-jdk-configs-3.3-10.el7_5.noarch
> java-1.8.0-openjdk-1.8.0.242.b08-0.el7_7.i686
> java-1.8.0-openjdk-devel-1.8.0.242.b08-0.el7_7.i686
> java-1.8.0-openjdk-headless-1.8.0.242.b08-0.el7_7.i686
> *JVM arguments :-*
> *-Dlog4j1.compatibility=true -jar*
> *Jar used :-*
> log4j-1.2-api-2.16.0.jar
> log4j-api-2.16.0.jar
> log4j-core-2.16.0.jar
>Reporter: Tukesh
>Priority: Blocker
>
> *Log4j 1.2 bridge API hard codes protocol to TCP and host address and port to
> localhost:514*
>
>
> *-Dlog4j1.compatibility=true -jar*
> *backtrace* :-
>
>
> {code:java}
> 2021-12-16 00:35:32,904 main ERROR TcpSocketManager (TCP:localhost:514)
> caught exception and will continue: java.io.IOException: Unable to create
> socket for localhost at port 514 using ip addresses and ports ,
> 0:0:0:0:0:0:0:1:514
> at
> org.apache.logging.log4j.core.net.TcpSocketManager$TcpSocketManagerFactory.createSocket(TcpSocketManager.java:509)
> at
> org.apache.logging.log4j.core.net.TcpSocketManager$TcpSocketManagerFactory.createManager(TcpSocketManager.java:478)
> at
> org.apache.logging.log4j.core.net.TcpSocketManager$TcpSocketManagerFactory.createManager(TcpSocketManager.java:459)
> at
> org.apache.logging.log4j.core.appender.AbstractManager.getManager(AbstractManager.java:113)
> at
> org.apache.logging.log4j.core.appender.OutputStreamManager.getManager(OutputStreamManager.java:100)
> at
> org.apache.logging.log4j.core.net.TcpSocketManager.getSocketManager(TcpSocketManager.java:202)
> at
> org.apache.logging.log4j.core.appender.SocketAppender.createSocketManager(SocketAppender.java:443)
> at
> org.apache.logging.log4j.core.appender.SocketAppender$Builder.build(SocketAppender.java:221)
> at
> org.apache.log4j.builders.appender.SyslogAppenderBuilder.createAppender(SyslogAppenderBuilder.java:150)
> at
> org.apache.log4j.builders.appender.SyslogAppenderBuilder.parseAppender(SyslogAppenderBuilder.java:121)
> at
> org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:76)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:427)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:405)
> at
> org.apache.log4j.config.PropertiesConfiguration.configureRoot(PropertiesConfiguration.java:325)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:302)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:92)
> at
> org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:59)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:289)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:626)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:699)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:716)
> at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:270)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:309)
> at org.apache.log4j.Logger$PrivateManager.getContext(Logger.java:59)
> at org.apache.log4j.Logger.getLogger(Logger.java:37)
> at test.logger.Example.(Example.java:12)
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.DualStackPlainSocketImpl.connect0(Native Method)
> at
> java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at
[jira] [Resolved] (LOG4J2-3249) Log4j 1.2 bridge for Syslog Appender defaults to port 512 instead of 514
[ https://issues.apache.org/jira/browse/LOG4J2-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved LOG4J2-3249. - Fix Version/s: 2.16.1 Resolution: Fixed > Log4j 1.2 bridge for Syslog Appender defaults to port 512 instead of 514 > > > Key: LOG4J2-3249 > URL: https://issues.apache.org/jira/browse/LOG4J2-3249 > Project: Log4j 2 > Issue Type: Bug > Components: log4j 1.2 emulation >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory >Priority: Major > Fix For: 2.16.1 > > > Log4j 1.2 bridge for Syslog Appender defaults to port 512 instead of 514, > which only happens when the port is missing from the configuration file. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (LOG4J2-3249) Log4j 1.2 bridge for Syslog Appender defaults to port 512 instead of 514
Gary D. Gregory created LOG4J2-3249: --- Summary: Log4j 1.2 bridge for Syslog Appender defaults to port 512 instead of 514 Key: LOG4J2-3249 URL: https://issues.apache.org/jira/browse/LOG4J2-3249 Project: Log4j 2 Issue Type: Bug Components: log4j 1.2 emulation Reporter: Gary D. Gregory Assignee: Gary D. Gregory Log4j 1.2 bridge for Syslog Appender defaults to port 512 instead of 514, which only happens when the port is missing from the configuration file. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3247) PropertiesConfiguration.parseAppenderFilters NPE when parsing properties file filters
[
https://issues.apache.org/jira/browse/LOG4J2-3247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LOG4J2-3247.
-
Fix Version/s: 2.16.1
Resolution: Fixed
Fixed in git {{release-2.x}} branch.
> PropertiesConfiguration.parseAppenderFilters NPE when parsing properties file
> filters
> -
>
> Key: LOG4J2-3247
> URL: https://issues.apache.org/jira/browse/LOG4J2-3247
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
>Affects Versions: 2.16.0
>Reporter: Fábio Constantino
>Priority: Blocker
> Fix For: 2.16.1
>
>
> When parsing appender filters configured in the properties file for example:
> {code:java}
> log4j.appender.LOG_REQUEST_START_DB=my.appender.class
> log4j.appender.LOG_REQUEST_START_DB.filter.ID=my.filter.class{code}
> a NullPointerException is thrown on line 564 of
> org.apache.log4j.config.PropertiesConfiguration. The _next_ variable is
> always _null_ at that point, from what appears to be a bug in the _if_
> condition above (looks like it should be _head == null_ instead of {_}head !=
> null{_}).
>
> Note: this is using the log4j1.compatibility=true property
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3247) PropertiesConfiguration.parseAppenderFilters NPE when parsing properties file filters
[
https://issues.apache.org/jira/browse/LOG4J2-3247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461049#comment-17461049
]
Gary D. Gregory edited comment on LOG4J2-3247 at 12/16/21, 9:28 PM:
May you please post your stack trace?
I also need something I can reproduce the NPE. Do you have an example file?
was (Author: garydgregory):
May you please post your stack trace?
> PropertiesConfiguration.parseAppenderFilters NPE when parsing properties file
> filters
> -
>
> Key: LOG4J2-3247
> URL: https://issues.apache.org/jira/browse/LOG4J2-3247
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
>Affects Versions: 2.16.0
>Reporter: Fábio Constantino
>Priority: Blocker
>
> When parsing appender filters configured in the properties file for example:
> {code:java}
> log4j.appender.LOG_REQUEST_START_DB=my.appender.class
> log4j.appender.LOG_REQUEST_START_DB.filter.ID=my.filter.class{code}
> a NullPointerException is thrown on line 564 of
> org.apache.log4j.config.PropertiesConfiguration. The _next_ variable is
> always _null_ at that point, from what appears to be a bug in the _if_
> condition above (looks like it should be _head == null_ instead of {_}head !=
> null{_}).
>
> Note: this is using the log4j1.compatibility=true property
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3247) PropertiesConfiguration.parseAppenderFilters NPE when parsing properties file filters
[
https://issues.apache.org/jira/browse/LOG4J2-3247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461049#comment-17461049
]
Gary D. Gregory commented on LOG4J2-3247:
-
May you please post your stack trace?
> PropertiesConfiguration.parseAppenderFilters NPE when parsing properties file
> filters
> -
>
> Key: LOG4J2-3247
> URL: https://issues.apache.org/jira/browse/LOG4J2-3247
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
>Affects Versions: 2.16.0
>Reporter: Fábio Constantino
>Priority: Blocker
>
> When parsing appender filters configured in the properties file for example:
> {code:java}
> log4j.appender.LOG_REQUEST_START_DB=my.appender.class
> log4j.appender.LOG_REQUEST_START_DB.filter.ID=my.filter.class{code}
> a NullPointerException is thrown on line 564 of
> org.apache.log4j.config.PropertiesConfiguration. The _next_ variable is
> always _null_ at that point, from what appears to be a bug in the _if_
> condition above (looks like it should be _head == null_ instead of {_}head !=
> null{_}).
>
> Note: this is using the log4j1.compatibility=true property
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (LOG4J2-3245) log4j-core-2.0-beta9.jar CVE-2021-44228 vulnerability
[
https://issues.apache.org/jira/browse/LOG4J2-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed LOG4J2-3245.
---
Fix Version/s: 2.16.0
Resolution: Fixed
> log4j-core-2.0-beta9.jar CVE-2021-44228 vulnerability
> --
>
> Key: LOG4J2-3245
> URL: https://issues.apache.org/jira/browse/LOG4J2-3245
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-beta9
>Reporter: Chaitanya
>Priority: Major
> Fix For: 2.16.0
>
>
> log4j-core-2.0-beta9.jar CVE-2021-44228 vulnerability is not resolved by
> removing *org/apache/logging/log4j/core/lookup/JndiLookup.class* as this
> version of ** depends on JndiLookup. Request to suggest how to remediate
> this.{*}{*}{*}{*}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3243) Property log4j.configurationFile incorrectly documented, log4j.configuration missing
[ https://issues.apache.org/jira/browse/LOG4J2-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461020#comment-17461020 ] Gary D. Gregory commented on LOG4J2-3243: - Hi [~lordjaxom] A) We do not support the 1.2 code base. We provide a compatibility layer in 2.x for existing apps that have not updated to 2.x. B) DO NOT USE 2.14! Use 2.16.0 > Property log4j.configurationFile incorrectly documented, log4j.configuration > missing > > > Key: LOG4J2-3243 > URL: https://issues.apache.org/jira/browse/LOG4J2-3243 > Project: Log4j 2 > Issue Type: Documentation > Components: Configuration >Affects Versions: 2.16.0 >Reporter: Sascha Volkenandt >Priority: Minor > > According to [1], Log4j looks for the system property > log4j2.configurationFile. According to the sources of log4j-core-2.16.0 > (ConfigurationFactory.java), the searched property is > log4j.configurationFile. The other property does not seem to have any effect > in recent versions. > [1] [https://logging.apache.org/log4j/2.x/manual/configuration.html] > Additionally, since 2.14.0 it looks for the property log4j.configuration (no > "File"), which was also the property used by Log4j 1.x. As a consequence, > logging stopped working in some of our systems after upgrading to 2.16.0 due > to Log4Shell. Those systems are using both 1.x and 2.x so they have the > property log4j.configuration set but not log4j.configurationFile, because we > relied on the previous behaviour that if log4j.configurationFile is not set > it looks in the classpath. I had to use a debugger to find out why it stopped > working. > It would be nice if that second property would also be mentioned in [1]. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3234) NoClassDefFoundError: org/apache/logging/log4j/core/lookup/JndiLookup when upgrading to 2.16.0
[
https://issues.apache.org/jira/browse/LOG4J2-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460274#comment-17460274
]
Gary D. Gregory commented on LOG4J2-3234:
-
[~jakedern-msft]
You're welcome, I am glad you figured it out!
> NoClassDefFoundError: org/apache/logging/log4j/core/lookup/JndiLookup when
> upgrading to 2.16.0
> ---
>
> Key: LOG4J2-3234
> URL: https://issues.apache.org/jira/browse/LOG4J2-3234
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
>Affects Versions: 2.16.0
> Environment: OS: Ubuntu 20.04
> {{Java --version:}}
> {quote}{{openjdk 11.0.9.1 2020-11-04 LTS}}
> {{OpenJDK Runtime Environment Zulu11.43+56-SA (build 11.0.9.1+1-LTS)}}
> {{OpenJDK 64-Bit Server VM Zulu11.43+56-SA (build 11.0.9.1+1-LTS, mixed
> mode)}}
> {quote}
> {{JVM Arguments:}}
> {quote}{{[-Xshare:auto, -Des.networkaddress.cache.ttl=60,
> -Des.networkaddress.cache.negative.ttl=10, -XX:+AlwaysPreTouch, -Xss1m,
> -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true,
> -XX:-OmitStackTraceInFastThrow, -Dio.netty.noUnsafe=true,
> -Dio.netty.noKeySetOptimization=true,
> -Dio.netty.recycler.maxCapacityPerThread=0,
> -Dio.netty.allocator.numDirectArenas=0, -Dlog4j.shutdownHookEnabled=false,
> -Dlog4j2.disable.jmx=true, -Djava.locale.providers=SPI,COMPAT, -Xms1g,
> -Xmx1g, -XX:+UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction=75,
> -XX:+UseCMSInitiatingOccupancyOnly,
> -Djava.io.tmpdir=/tmp/elasticsearch-4157234198199718700,
> -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=data,
> -XX:ErrorFile=logs/hs_err_pid%p.log,
> -Xlog:gc*,gc+age=trace,safepoint:file=logs/gc.log:utctime,pid,tags:filecount=32,filesize=64m,
> -Des.cgroups.hierarchy.override=/, -Dlog4j2.formatMsgNoLookups=true,
> -Xms1024m, -Xmx1024m, -XX:MaxDirectMemorySize=536870912,
> -Des.path.home=/opt/elasticsearch, -Des.path.conf=/opt/elasticsearch/config,
> -Des.distribution.flavor=oss, -Des.distribution.type=tar,
> -Des.bundled_jdk=true]}}
> {quote}
>
>Reporter: Jake Dern
>Priority: Minor
> Attachments: logs.txt
>
>
> After upgrading log4j2 dependencies to 2.16.0 on a from source build of
> ElasticSearch 7.9.1 we're running into errors like the following:
> {color:#7a869a}2021-12-15 00:24:58,904 main ERROR Unable to create Lookup for
> ctx java.lang.NoClassDefFoundError:
> org/apache/logging/log4j/core/lookup/JndiLookup{color}
> {quote} at
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:81)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:631)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:243)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:289)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:626)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:302)
> at
> org.elasticsearch.common.logging.LogConfigurator.configure(LogConfigurator.java:236)
> at
> org.elasticsearch.common.logging.LogConfigurator.configure(LogConfigurator.java:129)
> at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:354)
> at
> org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:170)
> at
> org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:161)
> at
> org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:86)
> at
> org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:127)
> at org.elasticsearch.cli.Command.main(Command.java:90)
> at
> org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:126)
> at
> org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:92)
> {quote}
> Full logs are attached, any advice is appreciated. We do not see these errors
> with log4j2 version 2.15.0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3234) NoClassDefFoundError: org/apache/logging/log4j/core/lookup/JndiLookup when upgrading to 2.16.0
[
https://issues.apache.org/jira/browse/LOG4J2-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460143#comment-17460143
]
Gary D. Gregory edited comment on LOG4J2-3234 at 12/15/21, 5:58 PM:
[~jakedern-msft]
If you open the jar file in a Zip GUI like 7-zip, do you see the
JndiLookup.class file? If not, then is it possible that someone edited the
log4j-core-2.16.0.jar file?
You can list the contents on the command line if you're comfortable wth that:
{{unzip -l log4j-core-2.17.0.jar | grep JndiLookup.class}}
{{2937 12-15-2021 10:12
org/apache/logging/log4j/core/lookup/JndiLookup.class}}
was (Author: garydgregory):
[~jakedern-msft]
If you open the jar file in a Zip GUI like 7-zip, do you see the
JndiLookup.class file? If not, then is it possible that someone edited the
log4j-core-2.16.0.jar file?
You can list the contents on the command line if you're comfortable wth that:
{{unzip -l log4j-core-2.17.0-SNAPSHOT.jar | grep JndiLookup.class}}
{{2937 12-15-2021 10:12
org/apache/logging/log4j/core/lookup/JndiLookup.class}}
> NoClassDefFoundError: org/apache/logging/log4j/core/lookup/JndiLookup when
> upgrading to 2.16.0
> ---
>
> Key: LOG4J2-3234
> URL: https://issues.apache.org/jira/browse/LOG4J2-3234
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
>Affects Versions: 2.16.0
> Environment: OS: Ubuntu 20.04
> {{Java --version:}}
> {quote}{{openjdk 11.0.9.1 2020-11-04 LTS}}
> {{OpenJDK Runtime Environment Zulu11.43+56-SA (build 11.0.9.1+1-LTS)}}
> {{OpenJDK 64-Bit Server VM Zulu11.43+56-SA (build 11.0.9.1+1-LTS, mixed
> mode)}}
> {quote}
> {{JVM Arguments:}}
> {quote}{{[-Xshare:auto, -Des.networkaddress.cache.ttl=60,
> -Des.networkaddress.cache.negative.ttl=10, -XX:+AlwaysPreTouch, -Xss1m,
> -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true,
> -XX:-OmitStackTraceInFastThrow, -Dio.netty.noUnsafe=true,
> -Dio.netty.noKeySetOptimization=true,
> -Dio.netty.recycler.maxCapacityPerThread=0,
> -Dio.netty.allocator.numDirectArenas=0, -Dlog4j.shutdownHookEnabled=false,
> -Dlog4j2.disable.jmx=true, -Djava.locale.providers=SPI,COMPAT, -Xms1g,
> -Xmx1g, -XX:+UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction=75,
> -XX:+UseCMSInitiatingOccupancyOnly,
> -Djava.io.tmpdir=/tmp/elasticsearch-4157234198199718700,
> -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=data,
> -XX:ErrorFile=logs/hs_err_pid%p.log,
> -Xlog:gc*,gc+age=trace,safepoint:file=logs/gc.log:utctime,pid,tags:filecount=32,filesize=64m,
> -Des.cgroups.hierarchy.override=/, -Dlog4j2.formatMsgNoLookups=true,
> -Xms1024m, -Xmx1024m, -XX:MaxDirectMemorySize=536870912,
> -Des.path.home=/opt/elasticsearch, -Des.path.conf=/opt/elasticsearch/config,
> -Des.distribution.flavor=oss, -Des.distribution.type=tar,
> -Des.bundled_jdk=true]}}
> {quote}
>
>Reporter: Jake Dern
>Priority: Minor
> Attachments: logs.txt
>
>
> After upgrading log4j2 dependencies to 2.16.0 on a from source build of
> ElasticSearch 7.9.1 we're running into errors like the following:
> {color:#7a869a}2021-12-15 00:24:58,904 main ERROR Unable to create Lookup for
> ctx java.lang.NoClassDefFoundError:
> org/apache/logging/log4j/core/lookup/JndiLookup{color}
> {quote} at
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:81)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:631)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:243)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:289)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:626)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:302)
> at
> org.elasticsearch.common.logging.LogConfigurator.configure(LogConfigurator.java:236)
> at
> org.elasticsearch.common.logging.LogConfigurator.configure(LogConfigurator.java:129)
> at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:354)
> at
> org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:170)
> at
> org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:161)
> at
> org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:86)
> at
> org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:127)
> at org.elasticsearch.cli.Command.main(Command.java:90)
> at
> org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:126)
> at
>
[jira] [Comment Edited] (LOG4J2-3234) NoClassDefFoundError: org/apache/logging/log4j/core/lookup/JndiLookup when upgrading to 2.16.0
[
https://issues.apache.org/jira/browse/LOG4J2-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460143#comment-17460143
]
Gary D. Gregory edited comment on LOG4J2-3234 at 12/15/21, 5:58 PM:
[~jakedern-msft]
If you open the jar file in a Zip GUI like 7-zip, do you see the
JndiLookup.class file? If not, then is it possible that someone edited the
log4j-core-2.16.0.jar file?
You can list the contents on the command line if you're comfortable wth that:
{{unzip -l log4j-core-2.16.0.jar | grep JndiLookup.class}}
{{2937 12-15-2021 10:12
org/apache/logging/log4j/core/lookup/JndiLookup.class}}
was (Author: garydgregory):
[~jakedern-msft]
If you open the jar file in a Zip GUI like 7-zip, do you see the
JndiLookup.class file? If not, then is it possible that someone edited the
log4j-core-2.16.0.jar file?
You can list the contents on the command line if you're comfortable wth that:
{{unzip -l log4j-core-2.17.0.jar | grep JndiLookup.class}}
{{2937 12-15-2021 10:12
org/apache/logging/log4j/core/lookup/JndiLookup.class}}
> NoClassDefFoundError: org/apache/logging/log4j/core/lookup/JndiLookup when
> upgrading to 2.16.0
> ---
>
> Key: LOG4J2-3234
> URL: https://issues.apache.org/jira/browse/LOG4J2-3234
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
>Affects Versions: 2.16.0
> Environment: OS: Ubuntu 20.04
> {{Java --version:}}
> {quote}{{openjdk 11.0.9.1 2020-11-04 LTS}}
> {{OpenJDK Runtime Environment Zulu11.43+56-SA (build 11.0.9.1+1-LTS)}}
> {{OpenJDK 64-Bit Server VM Zulu11.43+56-SA (build 11.0.9.1+1-LTS, mixed
> mode)}}
> {quote}
> {{JVM Arguments:}}
> {quote}{{[-Xshare:auto, -Des.networkaddress.cache.ttl=60,
> -Des.networkaddress.cache.negative.ttl=10, -XX:+AlwaysPreTouch, -Xss1m,
> -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true,
> -XX:-OmitStackTraceInFastThrow, -Dio.netty.noUnsafe=true,
> -Dio.netty.noKeySetOptimization=true,
> -Dio.netty.recycler.maxCapacityPerThread=0,
> -Dio.netty.allocator.numDirectArenas=0, -Dlog4j.shutdownHookEnabled=false,
> -Dlog4j2.disable.jmx=true, -Djava.locale.providers=SPI,COMPAT, -Xms1g,
> -Xmx1g, -XX:+UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction=75,
> -XX:+UseCMSInitiatingOccupancyOnly,
> -Djava.io.tmpdir=/tmp/elasticsearch-4157234198199718700,
> -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=data,
> -XX:ErrorFile=logs/hs_err_pid%p.log,
> -Xlog:gc*,gc+age=trace,safepoint:file=logs/gc.log:utctime,pid,tags:filecount=32,filesize=64m,
> -Des.cgroups.hierarchy.override=/, -Dlog4j2.formatMsgNoLookups=true,
> -Xms1024m, -Xmx1024m, -XX:MaxDirectMemorySize=536870912,
> -Des.path.home=/opt/elasticsearch, -Des.path.conf=/opt/elasticsearch/config,
> -Des.distribution.flavor=oss, -Des.distribution.type=tar,
> -Des.bundled_jdk=true]}}
> {quote}
>
>Reporter: Jake Dern
>Priority: Minor
> Attachments: logs.txt
>
>
> After upgrading log4j2 dependencies to 2.16.0 on a from source build of
> ElasticSearch 7.9.1 we're running into errors like the following:
> {color:#7a869a}2021-12-15 00:24:58,904 main ERROR Unable to create Lookup for
> ctx java.lang.NoClassDefFoundError:
> org/apache/logging/log4j/core/lookup/JndiLookup{color}
> {quote} at
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:81)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:631)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:243)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:289)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:626)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:302)
> at
> org.elasticsearch.common.logging.LogConfigurator.configure(LogConfigurator.java:236)
> at
> org.elasticsearch.common.logging.LogConfigurator.configure(LogConfigurator.java:129)
> at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:354)
> at
> org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:170)
> at
> org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:161)
> at
> org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:86)
> at
> org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:127)
> at org.elasticsearch.cli.Command.main(Command.java:90)
> at
> org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:126)
> at
>
[jira] [Commented] (LOG4J2-3234) NoClassDefFoundError: org/apache/logging/log4j/core/lookup/JndiLookup when upgrading to 2.16.0
[
https://issues.apache.org/jira/browse/LOG4J2-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460143#comment-17460143
]
Gary D. Gregory commented on LOG4J2-3234:
-
[~jakedern-msft]
If you open the jar file in a Zip GUI like 7-zip, do you see the
JndiLookup.class file? If not, then is it possible that someone edited the
log4j-core-2.16.0.jar file?
You can list the contents on the command line if you're comfortable wth that:
{{unzip -l log4j-core-2.17.0-SNAPSHOT.jar | grep JndiLookup.class}}
{{2937 12-15-2021 10:12
org/apache/logging/log4j/core/lookup/JndiLookup.class}}
> NoClassDefFoundError: org/apache/logging/log4j/core/lookup/JndiLookup when
> upgrading to 2.16.0
> ---
>
> Key: LOG4J2-3234
> URL: https://issues.apache.org/jira/browse/LOG4J2-3234
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
>Affects Versions: 2.16.0
> Environment: OS: Ubuntu 20.04
> {{Java --version:}}
> {quote}{{openjdk 11.0.9.1 2020-11-04 LTS}}
> {{OpenJDK Runtime Environment Zulu11.43+56-SA (build 11.0.9.1+1-LTS)}}
> {{OpenJDK 64-Bit Server VM Zulu11.43+56-SA (build 11.0.9.1+1-LTS, mixed
> mode)}}
> {quote}
> {{JVM Arguments:}}
> {quote}{{[-Xshare:auto, -Des.networkaddress.cache.ttl=60,
> -Des.networkaddress.cache.negative.ttl=10, -XX:+AlwaysPreTouch, -Xss1m,
> -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true,
> -XX:-OmitStackTraceInFastThrow, -Dio.netty.noUnsafe=true,
> -Dio.netty.noKeySetOptimization=true,
> -Dio.netty.recycler.maxCapacityPerThread=0,
> -Dio.netty.allocator.numDirectArenas=0, -Dlog4j.shutdownHookEnabled=false,
> -Dlog4j2.disable.jmx=true, -Djava.locale.providers=SPI,COMPAT, -Xms1g,
> -Xmx1g, -XX:+UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction=75,
> -XX:+UseCMSInitiatingOccupancyOnly,
> -Djava.io.tmpdir=/tmp/elasticsearch-4157234198199718700,
> -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=data,
> -XX:ErrorFile=logs/hs_err_pid%p.log,
> -Xlog:gc*,gc+age=trace,safepoint:file=logs/gc.log:utctime,pid,tags:filecount=32,filesize=64m,
> -Des.cgroups.hierarchy.override=/, -Dlog4j2.formatMsgNoLookups=true,
> -Xms1024m, -Xmx1024m, -XX:MaxDirectMemorySize=536870912,
> -Des.path.home=/opt/elasticsearch, -Des.path.conf=/opt/elasticsearch/config,
> -Des.distribution.flavor=oss, -Des.distribution.type=tar,
> -Des.bundled_jdk=true]}}
> {quote}
>
>Reporter: Jake Dern
>Priority: Minor
> Attachments: logs.txt
>
>
> After upgrading log4j2 dependencies to 2.16.0 on a from source build of
> ElasticSearch 7.9.1 we're running into errors like the following:
> {color:#7a869a}2021-12-15 00:24:58,904 main ERROR Unable to create Lookup for
> ctx java.lang.NoClassDefFoundError:
> org/apache/logging/log4j/core/lookup/JndiLookup{color}
> {quote} at
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:81)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:631)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:243)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:289)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:626)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:302)
> at
> org.elasticsearch.common.logging.LogConfigurator.configure(LogConfigurator.java:236)
> at
> org.elasticsearch.common.logging.LogConfigurator.configure(LogConfigurator.java:129)
> at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:354)
> at
> org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:170)
> at
> org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:161)
> at
> org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:86)
> at
> org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:127)
> at org.elasticsearch.cli.Command.main(Command.java:90)
> at
> org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:126)
> at
> org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:92)
> {quote}
> Full logs are attached, any advice is appreciated. We do not see these errors
> with log4j2 version 2.15.0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3231) JndiManager.isJndiEnabled generates a call to NetUtils.getLocalIps
[
https://issues.apache.org/jira/browse/LOG4J2-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459942#comment-17459942
]
Gary D. Gregory commented on LOG4J2-3231:
-
And why can't I edit my own comments in Jira?
> JndiManager.isJndiEnabled generates a call to NetUtils.getLocalIps
> --
>
> Key: LOG4J2-3231
> URL: https://issues.apache.org/jira/browse/LOG4J2-3231
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.16.0
>Reporter: Phong X. Nguyen
>Priority: Major
>
> While trying to upgrade from 2.15.0 to 2.16.0, we discovered some of our unit
> tests were failing. On further investigation, we realized that the new
> {{JndiManager.isJndiEnabled()}} method, on first call, causes initialization
> of all static members of {{{}JndiManager{}}}, including a call to
> {{{}NetUtils.getLocalIps{}}}. In at least one of our unit test frameworks,
> this generates a NullPointerException.
> Could some of the {{permanentAllowed}} lists initialization be deferred to
> avoid this issue?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3231) JndiManager.isJndiEnabled generates a call to NetUtils.getLocalIps
[
https://issues.apache.org/jira/browse/LOG4J2-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459941#comment-17459941
]
Gary D. Gregory commented on LOG4J2-3231:
-
Hi [~rgoers]
Take care of it how? This is caused by mocking in a test in an effectively
random place in the JRE. We can't start catching NPEs every time we call a JRE
method. What am I missing?
> JndiManager.isJndiEnabled generates a call to NetUtils.getLocalIps
> --
>
> Key: LOG4J2-3231
> URL: https://issues.apache.org/jira/browse/LOG4J2-3231
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.16.0
>Reporter: Phong X. Nguyen
>Priority: Major
>
> While trying to upgrade from 2.15.0 to 2.16.0, we discovered some of our unit
> tests were failing. On further investigation, we realized that the new
> {{JndiManager.isJndiEnabled()}} method, on first call, causes initialization
> of all static members of {{{}JndiManager{}}}, including a call to
> {{{}NetUtils.getLocalIps{}}}. In at least one of our unit test frameworks,
> this generates a NullPointerException.
> Could some of the {{permanentAllowed}} lists initialization be deferred to
> avoid this issue?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3235) Exception: Invalid byte tag in constant pool: 19 for module-info.class Java 7
[
https://issues.apache.org/jira/browse/LOG4J2-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459915#comment-17459915
]
Gary D. Gregory commented on LOG4J2-3235:
-
It looks to me like there are two issues here:
* I do not think we should have put a {{module-info.class}} into a jar file
meant for Java 7.
* This might not BCEL's fault. It just parses the class file you give it, or a
zip file you give it, or an input stream; there is no way to tell without
knowing the version of Tomcat and BCEL.
As a workaround, you can remove this class file from the jar file.
Gary
> Exception: Invalid byte tag in constant pool: 19 for module-info.class Java 7
> -
>
> Key: LOG4J2-3235
> URL: https://issues.apache.org/jira/browse/LOG4J2-3235
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Reporter: Saptarshi De
>Priority: Critical
> Fix For: 2.12.1
>
>
> Due to the recent vulnerability CVE-2021-44228 and CVE-2021-45046, We are
> updating to Log4j 2.12.2 on our Java 7 environment.
> Log4j 2.12.2 is supposed to be compatible with Java 7.
> We face the below exception on startup.
> Please suggest a solution for the same.
>
> {code:java}
> 15-Dec-2021 12:55:32.722 SEVERE [localhost-startStop-1]
> org.apache.catalina.startup.ContextConfig.processAnnotationsJar Unable to
> process Jar entry [META-INF/versions/9/module-info.class] from Jar
> [jar:file:/--/log4j-api-2.12.2.jar!/] for annotations
> org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte tag
> in constant pool: 19
> at
> org.apache.tomcat.util.bcel.classfile.Constant.readConstant(Constant.java:97)
> at
> org.apache.tomcat.util.bcel.classfile.ConstantPool.(ConstantPool.java:55)
> at
> org.apache.tomcat.util.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:177)
> at
> org.apache.tomcat.util.bcel.classfile.ClassParser.parse(ClassParser.java:85)
> at
> org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2011)
> at
> org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:1961)
> at
> org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1936)
> at
> org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1897)
> at
> org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1149)
> at
> org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:771)
> at
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:305)
> at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5066)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
> at
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1101)
> at
> org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1786)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3231) JndiManager.isJndiEnabled generates a call to NetUtils.getLocalIps
[
https://issues.apache.org/jira/browse/LOG4J2-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459644#comment-17459644
]
Gary D. Gregory commented on LOG4J2-3231:
-
[~phongn]
Thank you for your update.
It would appear from looking at the stack trace that your test is causing the
NPE _inside_ the JRE by using mocking. I am not sure the Log4j code should
guard against this kind of completely unexpected behavior from the Java runtime
itself.
> JndiManager.isJndiEnabled generates a call to NetUtils.getLocalIps
> --
>
> Key: LOG4J2-3231
> URL: https://issues.apache.org/jira/browse/LOG4J2-3231
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.16.0
>Reporter: Phong X. Nguyen
>Priority: Major
>
> While trying to upgrade from 2.15.0 to 2.16.0, we discovered some of our unit
> tests were failing. On further investigation, we realized that the new
> {{JndiManager.isJndiEnabled()}} method, on first call, causes initialization
> of all static members of {{{}JndiManager{}}}, including a call to
> {{{}NetUtils.getLocalIps{}}}. In at least one of our unit test frameworks,
> this generates a NullPointerException.
> Could some of the {{permanentAllowed}} lists initialization be deferred to
> avoid this issue?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3234) NoClassDefFoundError: org/apache/logging/log4j/core/lookup/JndiLookup when upgrading to 2.16.0
[
https://issues.apache.org/jira/browse/LOG4J2-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459642#comment-17459642
]
Gary D. Gregory commented on LOG4J2-3234:
-
Might you still have old log4j jars on your class path or somehow accessible?
> NoClassDefFoundError: org/apache/logging/log4j/core/lookup/JndiLookup when
> upgrading to 2.16.0
> ---
>
> Key: LOG4J2-3234
> URL: https://issues.apache.org/jira/browse/LOG4J2-3234
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
>Affects Versions: 2.16.0
> Environment: OS: Ubuntu 20.04
> {{Java --version:}}
> {quote}{{openjdk 11.0.9.1 2020-11-04 LTS}}
> {{OpenJDK Runtime Environment Zulu11.43+56-SA (build 11.0.9.1+1-LTS)}}
> {{OpenJDK 64-Bit Server VM Zulu11.43+56-SA (build 11.0.9.1+1-LTS, mixed
> mode)}}
> {quote}
> {{JVM Arguments:}}
> {quote}{{[-Xshare:auto, -Des.networkaddress.cache.ttl=60,
> -Des.networkaddress.cache.negative.ttl=10, -XX:+AlwaysPreTouch, -Xss1m,
> -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true,
> -XX:-OmitStackTraceInFastThrow, -Dio.netty.noUnsafe=true,
> -Dio.netty.noKeySetOptimization=true,
> -Dio.netty.recycler.maxCapacityPerThread=0,
> -Dio.netty.allocator.numDirectArenas=0, -Dlog4j.shutdownHookEnabled=false,
> -Dlog4j2.disable.jmx=true, -Djava.locale.providers=SPI,COMPAT, -Xms1g,
> -Xmx1g, -XX:+UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction=75,
> -XX:+UseCMSInitiatingOccupancyOnly,
> -Djava.io.tmpdir=/tmp/elasticsearch-4157234198199718700,
> -XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath=data,
> -XX:ErrorFile=logs/hs_err_pid%p.log,
> -Xlog:gc*,gc+age=trace,safepoint:file=logs/gc.log:utctime,pid,tags:filecount=32,filesize=64m,
> -Des.cgroups.hierarchy.override=/, -Dlog4j2.formatMsgNoLookups=true,
> -Xms1024m, -Xmx1024m, -XX:MaxDirectMemorySize=536870912,
> -Des.path.home=/opt/elasticsearch, -Des.path.conf=/opt/elasticsearch/config,
> -Des.distribution.flavor=oss, -Des.distribution.type=tar,
> -Des.bundled_jdk=true]}}
> {quote}
>
>Reporter: Jake Dern
>Priority: Minor
> Attachments: logs.txt
>
>
> After upgrading log4j2 dependencies to 2.16.0 on a from source build of
> ElasticSearch 7.9.1 we're running into errors like the following:
> {color:#7a869a}2021-12-15 00:24:58,904 main ERROR Unable to create Lookup for
> ctx java.lang.NoClassDefFoundError:
> org/apache/logging/log4j/core/lookup/JndiLookup{color}
> {quote} at
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:81)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:631)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:243)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:289)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:626)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:302)
> at
> org.elasticsearch.common.logging.LogConfigurator.configure(LogConfigurator.java:236)
> at
> org.elasticsearch.common.logging.LogConfigurator.configure(LogConfigurator.java:129)
> at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:354)
> at
> org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:170)
> at
> org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:161)
> at
> org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:86)
> at
> org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:127)
> at org.elasticsearch.cli.Command.main(Command.java:90)
> at
> org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:126)
> at
> org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:92)
> {quote}
> Full logs are attached, any advice is appreciated. We do not see these errors
> with log4j2 version 2.15.0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3233) Log4j 1.x.xx vulnerability assessment
[ https://issues.apache.org/jira/browse/LOG4J2-3233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459640#comment-17459640 ] Gary D. Gregory commented on LOG4J2-3233: - I am wondering what you are really using because there are no 1.3 or 1.4 versions. Please verify which jar files you are using and list their names. > Log4j 1.x.xx vulnerability assessment > - > > Key: LOG4J2-3233 > URL: https://issues.apache.org/jira/browse/LOG4J2-3233 > Project: Log4j 2 > Issue Type: Bug > Components: log4j 1.2 emulation, Log4j-to-SLF4J > Environment: PRODUCTION >Reporter: Ram Subramanian >Priority: Major > > Hi Team, > > We are running legacy decade old applications using log4j 1.2.13 and log4j > 1.2.17 , log4j 1.3.xx and 1.4.xx > > Question: > are the above older log4j 1.xx versions been impacted by the security > vulnerability for log4j2 > > Any help and clarity is much appreciated -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3233) Log4j 1.x.xx vulnerability assessment
[ https://issues.apache.org/jira/browse/LOG4J2-3233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated LOG4J2-3233: Affects Version/s: (was: 1.5) > Log4j 1.x.xx vulnerability assessment > - > > Key: LOG4J2-3233 > URL: https://issues.apache.org/jira/browse/LOG4J2-3233 > Project: Log4j 2 > Issue Type: Bug > Components: log4j 1.2 emulation, Log4j-to-SLF4J > Environment: PRODUCTION >Reporter: Ram Subramanian >Priority: Major > > Hi Team, > > We are running legacy decade old applications using log4j 1.2.13 and log4j > 1.2.17 , log4j 1.3.xx and 1.4.xx > > Question: > are the above older log4j 1.xx versions been impacted by the security > vulnerability for log4j2 > > Any help and clarity is much appreciated -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (LOG4J2-3201) Limit the protocols jNDI can use and restrict LDAP.
[ https://issues.apache.org/jira/browse/LOG4J2-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory reopened LOG4J2-3201: - > Limit the protocols jNDI can use and restrict LDAP. > --- > > Key: LOG4J2-3201 > URL: https://issues.apache.org/jira/browse/LOG4J2-3201 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Reporter: Ralph Goers >Priority: Major > Fix For: 2.15.0 > > > LDAP needs to be limited in the servers and classes it can access. JNDI > should only support the java, ldap, and ldaps protocols by default. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3201) Limit the protocols JNDI can use and restrict LDAP.
[ https://issues.apache.org/jira/browse/LOG4J2-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated LOG4J2-3201: Summary: Limit the protocols JNDI can use and restrict LDAP. (was: Limit the protocols jNDI can use and restrict LDAP.) > Limit the protocols JNDI can use and restrict LDAP. > --- > > Key: LOG4J2-3201 > URL: https://issues.apache.org/jira/browse/LOG4J2-3201 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Reporter: Ralph Goers >Priority: Major > Fix For: 2.15.0 > > > LDAP needs to be limited in the servers and classes it can access. JNDI > should only support the java, ldap, and ldaps protocols by default. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (LOG4J2-3201) Limit the protocols JNDI can use and restrict LDAP.
[ https://issues.apache.org/jira/browse/LOG4J2-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed LOG4J2-3201. --- Resolution: Fixed Fix Jira title. > Limit the protocols JNDI can use and restrict LDAP. > --- > > Key: LOG4J2-3201 > URL: https://issues.apache.org/jira/browse/LOG4J2-3201 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Reporter: Ralph Goers >Priority: Major > Fix For: 2.15.0 > > > LDAP needs to be limited in the servers and classes it can access. JNDI > should only support the java, ldap, and ldaps protocols by default. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3231) JndiManager.isJndiEnabled generates a call to NetUtils.getLocalIps
[
https://issues.apache.org/jira/browse/LOG4J2-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459587#comment-17459587
]
Gary D. Gregory edited comment on LOG4J2-3231 at 12/15/21, 1:18 AM:
Hello [~phongn]
Thank you for your report. May you please provide a simple unit test to
reproduce this issue?
Also, please post the NullPointerException's stack trace.
This simple test passes:
{code:java}
package org.apache.logging.log4j.core.net;
import org.junit.jupiter.api.Test;
public class JndiManagerTest {
@Test
public void testIsJndiEnabled() {
assertFalse(JndiManager.isJndiEnabled());
}
} {code}
was (Author: garydgregory):
Hello [~phongn]
Thank you for your report. May you please provide a simple unit test to
reproduce this issue?
Also, please post the NPE.
This simple test passes:
{code:java}
package org.apache.logging.log4j.core.net;
import org.junit.jupiter.api.Test;
public class JndiManagerTest {
@Test
public void testIsJndiEnabled() {
assertFalse(JndiManager.isJndiEnabled());
}
} {code}
> JndiManager.isJndiEnabled generates a call to NetUtils.getLocalIps
> --
>
> Key: LOG4J2-3231
> URL: https://issues.apache.org/jira/browse/LOG4J2-3231
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.16.0
>Reporter: Phong X. Nguyen
>Priority: Major
>
> While trying to upgrade from 2.15.0 to 2.16.0, we discovered some of our unit
> tests were failing. On further investigation, we realized that the new
> {{JndiManager.isJndiEnabled()}} method, on first call, causes initialization
> of all static members of {{{}JndiManager{}}}, including a call to
> {{{}NetUtils.getLocalIps{}}}. In at least one of our unit test frameworks,
> this generates a NullPointerException.
> Could some of the {{permanentAllowed}} lists initialization be deferred to
> avoid this issue?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3231) JndiManager.isJndiEnabled generates a call to NetUtils.getLocalIps
[
https://issues.apache.org/jira/browse/LOG4J2-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459587#comment-17459587
]
Gary D. Gregory edited comment on LOG4J2-3231 at 12/15/21, 1:17 AM:
Hello [~phongn]
Thank you for your report. May you please provide a simple unit test to
reproduce this issue?
Also, please post the NPE.
This simple test passes:
{code:java}
package org.apache.logging.log4j.core.net;
import org.junit.jupiter.api.Test;
public class JndiManagerTest {
@Test
public void testIsJndiEnabled() {
assertFalse(JndiManager.isJndiEnabled());
}
} {code}
was (Author: garydgregory):
Hello [~phongn]
Thank you for your report. May you please provide a simple unit test to
reproduce this issue?
This simple test passes:
{code:java}
package org.apache.logging.log4j.core.net;
import org.junit.jupiter.api.Test;
public class JndiManagerTest {
@Test
public void testIsJndiEnabled() {
assertFalse(JndiManager.isJndiEnabled());
}
} {code}
> JndiManager.isJndiEnabled generates a call to NetUtils.getLocalIps
> --
>
> Key: LOG4J2-3231
> URL: https://issues.apache.org/jira/browse/LOG4J2-3231
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.16.0
>Reporter: Phong X. Nguyen
>Priority: Major
>
> While trying to upgrade from 2.15.0 to 2.16.0, we discovered some of our unit
> tests were failing. On further investigation, we realized that the new
> {{JndiManager.isJndiEnabled()}} method, on first call, causes initialization
> of all static members of {{{}JndiManager{}}}, including a call to
> {{{}NetUtils.getLocalIps{}}}. In at least one of our unit test frameworks,
> this generates a NullPointerException.
> Could some of the {{permanentAllowed}} lists initialization be deferred to
> avoid this issue?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3231) JndiManager.isJndiEnabled generates a call to NetUtils.getLocalIps
[
https://issues.apache.org/jira/browse/LOG4J2-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459587#comment-17459587
]
Gary D. Gregory edited comment on LOG4J2-3231 at 12/15/21, 1:16 AM:
Hello [~phongn]
Thank you for your report. May you please provide a simple unit test to
reproduce this issue?
This simple test passes:
{code:java}
package org.apache.logging.log4j.core.net;
import org.junit.jupiter.api.Test;
public class JndiManagerTest {
@Test
public void testIsJndiEnabled() {
assertFalse(JndiManager.isJndiEnabled());
}
} {code}
was (Author: garydgregory):
Hello [~phongn]
Thank you for your report. May you please provide a simple unit test to
reproduce this issue?
This simple test passes:
{code:java}
package org.apache.logging.log4j.core.net;
import org.junit.jupiter.api.Test;
public class JndiManagerTest {
@Test
public void testIsJndiEnabled() {
JndiManager.isJndiEnabled();
}
} {code}
> JndiManager.isJndiEnabled generates a call to NetUtils.getLocalIps
> --
>
> Key: LOG4J2-3231
> URL: https://issues.apache.org/jira/browse/LOG4J2-3231
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.16.0
>Reporter: Phong X. Nguyen
>Priority: Major
>
> While trying to upgrade from 2.15.0 to 2.16.0, we discovered some of our unit
> tests were failing. On further investigation, we realized that the new
> {{JndiManager.isJndiEnabled()}} method, on first call, causes initialization
> of all static members of {{{}JndiManager{}}}, including a call to
> {{{}NetUtils.getLocalIps{}}}. In at least one of our unit test frameworks,
> this generates a NullPointerException.
> Could some of the {{permanentAllowed}} lists initialization be deferred to
> avoid this issue?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3231) JndiManager.isJndiEnabled generates a call to NetUtils.getLocalIps
[
https://issues.apache.org/jira/browse/LOG4J2-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459587#comment-17459587
]
Gary D. Gregory edited comment on LOG4J2-3231 at 12/15/21, 1:15 AM:
Hello [~phongn]
Thank you for your report. May you please provide a simple unit test to
reproduce this issue?
This simple test passes:
{code:java}
package org.apache.logging.log4j.core.net;
import org.junit.jupiter.api.Test;
public class JndiManagerTest {
@Test
public void testIsJndiEnabled() {
JndiManager.isJndiEnabled();
}
} {code}
was (Author: garydgregory):
Hello [~phongn]
Thank you for your report. May you please provide a simple unit test to
reproduce this issue?
This simple test passes:
{code:java}
package org.apache.logging.log4j.core.net;
import org.junit.jupiter.api.Test;
public class JndiManagerTest {
@Test
public void test() {
JndiManager.isJndiEnabled();
}
} {code}
> JndiManager.isJndiEnabled generates a call to NetUtils.getLocalIps
> --
>
> Key: LOG4J2-3231
> URL: https://issues.apache.org/jira/browse/LOG4J2-3231
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.16.0
>Reporter: Phong X. Nguyen
>Priority: Major
>
> While trying to upgrade from 2.15.0 to 2.16.0, we discovered some of our unit
> tests were failing. On further investigation, we realized that the new
> {{JndiManager.isJndiEnabled()}} method, on first call, causes initialization
> of all static members of {{{}JndiManager{}}}, including a call to
> {{{}NetUtils.getLocalIps{}}}. In at least one of our unit test frameworks,
> this generates a NullPointerException.
> Could some of the {{permanentAllowed}} lists initialization be deferred to
> avoid this issue?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
