[jira] [Updated] (LOG4J2-2438) Using log4j-core as a module and usage in JLink
[ https://issues.apache.org/jira/browse/LOG4J2-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers updated LOG4J2-2438: Fix Version/s: 3.0.0 > Using log4j-core as a module and usage in JLink > --- > > Key: LOG4J2-2438 > URL: https://issues.apache.org/jira/browse/LOG4J2-2438 > Project: Log4j 2 > Issue Type: Improvement > Components: Core >Affects Versions: 2.11.1 >Reporter: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.0.0 > > > Currently based on the given automatic modules you can't use log4j-core in a > project where you like to use jlink to produce a runtime image.. > Related to LOG4J2-2226 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (LOG4J2-1973) FailoverAppenders fail to start
[
https://issues.apache.org/jira/browse/LOG4J2-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers reassigned LOG4J2-1973:
---
Assignee: Ralph Goers
> FailoverAppenders fail to start
> ---
>
> Key: LOG4J2-1973
> URL: https://issues.apache.org/jira/browse/LOG4J2-1973
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.8.2
>Reporter: Vina Martin
>Assignee: Ralph Goers
>Priority: Critical
>
> I created a simple Hello World program with Log4j2 2.8.2 following the
> documentation.
> {code}
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
> public class HelloWorld {
> private static final Logger logger =
> LogManager.getLogger(HelloWorld.class);
> public static void main(final String... args) {
> logger.error("A test error- hello world!");
> }
> }
> {code}
> with the following configuration in {{log4j2.xml}}
> {code}
>
>
>
>
>
>
> filePattern="logs/app-%d{MM-dd-}.log.gz"
> ignoreExceptions="false">
>
> %d %p %c{1.} [%t] %m%n
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I get this error when starting up my program: {{ERROR appender Failover has
> no parameter that matches element Failovers}}. I observed that the hello
> world message appeared in the log file and was properly appended each time I
> ran my hello world program.
> Then, I tried to simulate a scenario where a failover would happen to verify
> that the failover appender is not starting properly. I locked the log file to
> be read-only. After locking the file I ran the program and saw the following
> output:
> {code}
> 2017-07-10 08:52:25,802 main ERROR RollingFileManager (logs/app.log)
> java.io.FileNotFoundException: logs/app.log (Permission denied)
> java.io.FileNotFoundException: logs/app.log (Permission denied)
> at java.io.FileOutputStream.open0(Native Method)
> at java.io.FileOutputStream.open(FileOutputStream.java:270)
> at java.io.FileOutputStream.(FileOutputStream.java:213)
> at java.io.FileOutputStream.(FileOutputStream.java:133)
> at
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager$RollingFileManagerFactory.createManager(RollingFileManager.java:587)
> at
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager$RollingFileManagerFactory.createManager(RollingFileManager.java:554)
> at
> org.apache.logging.log4j.core.appender.AbstractManager.getManager(AbstractManager.java:112)
> at
> org.apache.logging.log4j.core.appender.OutputStreamManager.getManager(OutputStreamManager.java:114)
> at
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.getFileManager(RollingFileManager.java:155)
> at
> org.apache.logging.log4j.core.appender.RollingFileAppender$Builder.build(RollingFileAppender.java:131)
> at
> org.apache.logging.log4j.core.appender.RollingFileAppender$Builder.build(RollingFileAppender.java:60)
> at
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:952)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:892)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:884)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:508)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:232)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:244)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:545)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
> at HelloWorld.(HelloWorld.java:10)
>
[jira] [Closed] (LOG4J2-3294) Default to having placeholders off in log4j and remove JDNI lookups
[
https://issues.apache.org/jira/browse/LOG4J2-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers closed LOG4J2-3294.
---
Resolution: Not A Problem
JNDI is in the library because it is still used by JEE applications as well as
JMS and JDBC in some circumstances. I would guess well over 80% of Log4j users
use property substitution (although Matt's guess is probably closer).
Log4j 2.17.2 has fixed property substitution so that Lookup recursion is no
longer necessary or allowed.
I am closing this since a) it covers multiple topics and b) everything
mentioned has been covered to the degree it needs to be.
> Default to having placeholders off in log4j and remove JDNI lookups
> ---
>
> Key: LOG4J2-3294
> URL: https://issues.apache.org/jira/browse/LOG4J2-3294
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
>Affects Versions: 2.13.0, 2.14.0, 2.15.0, 2.16.0, 2.17.0
> Environment: Java 17
>Reporter: jamie fisher
>Priority: Critical
>
> Log4j keeps having RCE bugs and security issues relating to placeholders
> ${like:this}
> Normally when a product has multiple severe security problems we would just
> use something else, but for many people they cannot change to another less
> bloated logger.
> My proposal is to {*}completely remove JDNI{*}, which leads to arbitrary code
> execution ({+}why is this in a logging library?{+}). This feature is used by
> less than 0.001% of log4j users (in my measurements).
> My second proposal is to have features such as placeholders +disabled by
> default+ (it is rare that these are needed under normal circumstances, their
> parsing is slow and has posed several security issues in the past)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3390) AppenderSkeleton missing from log4j-1.2-api-2.3.2 bridge
[ https://issues.apache.org/jira/browse/LOG4J2-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers resolved LOG4J2-3390. - Resolution: Won't Fix Marking as resolved since we will not be enhancing our Java 6 & 7 support. > AppenderSkeleton missing from log4j-1.2-api-2.3.2 bridge > > > Key: LOG4J2-3390 > URL: https://issues.apache.org/jira/browse/LOG4J2-3390 > Project: Log4j 2 > Issue Type: Improvement > Components: Log4j 1.2 bridge >Affects Versions: 2.3.2 >Reporter: Vivek >Priority: Critical > > Currently log4j1 is being used in our application with Java1.6 but due to > vulnerabilities and EOL we are now trying to implement Log4j1.2 bridge in our > application. We have use Log4j2.3.2 api with Log4j1.2 bridge(For Java6) but > while running the application getting below ClassNotFoundException exception: > --- > at com.rbsfm.wssservices.argon.MessageReader.run(MessageReader.java:150) > Caused by: *java.lang.ClassNotFoundException: > org.apache.log4j.AppenderSkeleton* > at java.net.URLClassLoader$1.run(URLClassLoader.java:202) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:190) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > ... 17 more > 2022-02-03 15:25:09,564 DEBUG Stopping LoggerContext[name=3526198, > org.apache.logging.log4j.core.LoggerContext@162dbb6] > --- > Its looking like ApenderSkeleton class is missing from Log4j-1.2-api-2.3.2 > bridge jar. Could you please suggest if there is any other bridge which can > be used and compatible with java6 or we can enhance 2.3.2 bridge API. > Jars used in application : > log4j-api-2.3.2.jar > log4j-core-2.3.2.jar > log4j-1.2-api-2.3.2.jar -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3238) Log4j 1.2 bridge API doesn't write the messages to rsyslog in proper "PatternLayout" mentioned in log4j.properties file when SysLogAppender is used
[
https://issues.apache.org/jira/browse/LOG4J2-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers reassigned LOG4J2-3238:
---
Assignee: Ralph Goers
> Log4j 1.2 bridge API doesn't write the messages to rsyslog in proper
> "PatternLayout" mentioned in log4j.properties file when SysLogAppender is
> used
> -
>
> Key: LOG4J2-3238
> URL: https://issues.apache.org/jira/browse/LOG4J2-3238
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Appenders, Core, Pattern Converters
>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 used :-*
> log4j-1.2-api-2.16.0.jar
> log4j-api-2.16.0.jar
> log4j-core-2.16.0.jar
>Reporter: Tukesh
>Assignee: Ralph Goers
>Priority: Blocker
> Attachments: log4j2.tar.gz
>
>
> Log4j 1.2 bridge API doesn't write the messages to rsyslog in proper
> "PatternLayout" mentioned in log4j.properties file when SysLogAppender is
> used .
> You can see log messages are missing Conversion Patterns effect like string
> "MyMain" , Data, ClassName etc.
>
> log4j.properties file :-
>
> {code:java}
> log4j.rootLogger=DEBUG,SYSLOG
> log4j.appender.SYSLOG=org.apache.log4j.net.SyslogAppender
> log4j.appender.SYSLOG.Threshold=DEBUG
> log4j.appender.SYSLOG.syslogHost=localhost
> log4j.appender.SYSLOG.port=514
> log4j.appender.SYSLOG.header=true
> log4j.appender.SYSLOG.Facility=LOCAL3
> log4j.appender.SYSLOG.layout=org.apache.log4j.PatternLayout
> log4j.appender.SYSLOG.layout.conversionPattern=MyMain[%pid] :%t: %c %-4p %m%n
> {code}
>
>
> *Source code ( LoggerExample.java ) :-*
>
>
> {code:java}
> package test.logger;
> import org.apache.log4j.Logger;
> import java.io.*;
> import java.sql.SQLException;
> import java.util.concurrent.TimeUnit;
> public class LoggerExample{
> static Logger log = Logger.getLogger(LoggerExample.class.getName());
> public static void main(String[] args)throws IOException,SQLException{
> log.debug("log4j-shell Starting...");
> while(true){
> System.out.println("I'm running...");
> log.debug("Test Log4j-shell this is a debug message");
> try {
> TimeUnit.SECONDS.sleep(1);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> }
> }
> }
> {code}
>
>
> *Sample message created :-*
>
> {code:java}
>
> log4j-shell Starting...
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
> Test Log4j-shell this is a debug message
>
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-2697) Priority of the Event is not calculated correctly
[
https://issues.apache.org/jira/browse/LOG4J2-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers reassigned LOG4J2-2697:
---
Assignee: Ralph Goers
> Priority of the Event is not calculated correctly
> -
>
> Key: LOG4J2-2697
> URL: https://issues.apache.org/jira/browse/LOG4J2-2697
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Layouts
>Affects Versions: 2.11.1
> Environment: RedHat 7.6
> OpenJDK 11
>Reporter: Jose Luis
>Assignee: Ralph Goers
>Priority: Blocker
> Attachments: 02-logEvent_customLevel.jpg,
> 03-TCPStream_All184Values.jpg, CSFLogConfigData.xml
>
>
> We are having a problem with the Priority of the event created by the log4j2
> API.
> * According to the [RFC 5424|https://tools.ietf.org/html/rfc5424]
> specification, the priority is calculated as:
> *{{PRIORITY = ( FACILITY x 8) + SEVERITY}}*
> * In our configuration file (CSFLogConfigData.xml attached) we set the
> *Facility = LOCAL7 (value = 23)* and several Custom Levels:
> *{{}}*
> *{{}}{{ }}*
> *{{}}{{ }}*
> *{{}}{{ }}*
> *{{}}{{ }}*
> *{{}}{{ }}*
> *{{}}{{ }}*
> *{{}}{{ }}*
> *{{}}{{ }}*
> {{**}}
> * In our testing, we are provoking an Emergency Level event, as you can see
> in the screenshot attached (02-logEvent_customLevel)
> * The priority expected in the event after log4j2 management should be
> {{ *PRIORITY = (23 x 8) + 2 = 186*}}
> * But in the TCP Stream, all the events have *PRIORITY = 184* (screenshot
> attached 03-TCPStream_All184Values). In the screenshot the priority of some
> events can be seen, all of them with *PRIORITY = 184*, no matter the Severity
> Level of the event.
> We are seeing the Severity is not being added when calculating the priority.
> We have test with another facility, and the multiplication is ok, but in
> every case the Severity is not added.
>
> Is this a known problem?
> There is something wrong with our configuration?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-2733) the initial logs were flushed away while file rolling at the second time
[
https://issues.apache.org/jira/browse/LOG4J2-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers reassigned LOG4J2-2733:
---
Assignee: Ralph Goers
> the initial logs were flushed away while file rolling at the second time
>
>
> Key: LOG4J2-2733
> URL: https://issues.apache.org/jira/browse/LOG4J2-2733
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.12.1
> Environment: Linux RHEL 6
> oracle jdk 1.8.0_151l64
> Linux login session's timezone: EST
> slf4j api 1.7.9
>Reporter: ma jun
>Assignee: Ralph Goers
>Priority: Blocker
> Attachments: Main.java, log4j2_utc_test.xml
>
>
> observed a bug that the initial logs were flushed away while file rolling at
> the second time. if jvm is set a timezone which is different the log config's
> timezone, the issue happens and the log file will be rolling at different
> time points between the first day and the next days.
> please see below details
> 1. in java code the default timezone was set to UTC (project requirement).
> see below testing code piece .
> {code:java}
> static final Logger log = LoggerFactory.getLogger(Main.class);
>
> public static void main(String[] args) {
> java.util.TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
> log.info("set timezone to UTC");
> while (true) {
> log.info("echo current timing-{}",
> System.currentTimeMillis());
> try {
> Thread.sleep(3 * 60 * 1000);
> } catch (InterruptedException e) {
> Thread.currentThread().interrupt();
> }
> }
> }
> {code}
> 2. and in log4j2 configuration , the time zone was still configured to
> America/New_York. see below configs.
> {noformat}
>
>
>
>
>fileName="${sys:logDir}/log4j_rolling_test_utc.log"
>
> filePattern="${sys:logDir}/log4j_rolling_test_utc.log.%d{MMdd}{America/New_York}">
>
>
>
>
>
>
>
>
>
>
>
>
> {noformat}
> 3. java cmd --
> /opt/jdk/1.8.0_151l64/bin/java
> -Dlog4j.configurationFile=/var/tmp/log4j2test/log4j2_utc_test.xml
> -DlogLevel=info -DlogDir=/var/tmp/log4j2test -jar
> /var/tmp/log4j2test/log4j2rolling_UTC.jar &
> and the linux session was in timezone EST
> 4. observed issue
> #1. the first day the logs were looking good. and the file rolling was also
> good for the first time
> 19-12-05 04:54:27.373 [INFO ] main l.Main:12 - echo current
> timing-1575539667366
> 19-12-05 04:57:27.378 [INFO ] main l.Main:12 - echo current
> timing-1575539847378
> 19-12-05 05:00:27.378 [INFO ] main l.Main:12 - echo current
> timing-1575540027378
> it generated a log file log4j_rolling_test_utc.log.20191205 with above logs.
> and meanwhile
> log4j_rolling_test_utc.log was still there to receive the new logs. and it
> was rolling at EST time midnight, that's what i expected.
> #2. when the next day time moved to *UTC* midnight (EST time 19:00), file
> rolling happened which was not expected. the initial logs(at timing 19-12-05
> 04:54 EST) in log4j_rolling_test_utc.log.20191205 were flushed away.
> actually all the logs before 19-12-06 EST were flushed away.
> bash-4.1$ head log4j_rolling_test_utc.log.20191205
> 19-12-06 00:00:34.271 [INFO ] main l.Main:16 - echo current
> timing-1575608434270
> 19-12-06 00:03:34.277 [INFO ] main l.Main:16 - echo current
> timing-1575608614277
> 19-12-06 00:06:34.278 [INFO ] main l.Main:16 - echo current
> timing-1575608794277
> 19-12-06 00:09:34.278 [INFO ] main l.Main:16 - echo current
> timing-1575608974278
> Please let me know if you need more details.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3329) OOM Issue: RollingFile with custom layout and timebased rolling policy
[ https://issues.apache.org/jira/browse/LOG4J2-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers reassigned LOG4J2-3329: --- Assignee: Ralph Goers > OOM Issue: RollingFile with custom layout and timebased rolling policy > -- > > Key: LOG4J2-3329 > URL: https://issues.apache.org/jira/browse/LOG4J2-3329 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders, Layouts >Affects Versions: 2.17.1 > Environment: CERTIFICATION >Reporter: Geet S >Assignee: Ralph Goers >Priority: Blocker > > I have used Java log4j2 programmatically and created custom appender of type > RollingFile with custom layout and TimeBasedTriggeringPolicy (interval 1800) > . We see below issue for one component and this does not happen for all. > We are using OpenJDK 1.8 with Embedded Jetty server 9. > *Error: java.lang.OutOfMemoryError: GC overhead limit exceeded* > +*Exception Trace 1:*+ > 2022-01-11 22:14:53,338 JobPublishingTask - 25 of 30 ERROR An exception > occurred processing Appender CustomAppender > org.apache.logging.log4j.core.appender.AppenderLoggingException: > java.lang.OutOfMemoryError: GC overhead limit exceeded > at > org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:165) > 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.log(LoggerConfig.java:417) > at > org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:82) > at org.apache.logging.log4j.core.Logger.log(Logger.java:161) > at > org.apache.logging.log4j.spi.AbstractLogger.tryLogMessage(AbstractLogger.java:2205) > at > org.apache.logging.log4j.spi.AbstractLogger.logMessageTrackRecursion(AbstractLogger.java:2159) > at > org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(AbstractLogger.java:2142) > at > org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:1994) > at > org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1852) > at org.apache.logging.log4j.spi.AbstractLogger.log(AbstractLogger.java:1642) > +*Exception Trace 2:*+ > 2022-01-01 09:00:51,554 JobPublishingTaskDLSQS - 15 of 30 ERROR An exception > occurred processing Appender CustomAppender > org.apache.logging.log4j.core.appender.AppenderLoggingException: > java.lang.OutOfMemoryError: GC overhead limit exceeded at > org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:165) > 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.log(LoggerConfig.java:417) > at > org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:82) > at org.apache.logging.log4j.core.Logger.log(Logger.java:161) at > org.apache.logging.log4j.spi.AbstractLogger.tryLogMessage(AbstractLogger.java:2205) > at > org.apache.logging.log4j.spi.AbstractLogger.logMessageTrackRecursion(AbstractLogger.java:2159) > at > org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(AbstractLogger.java:2142) > at > org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:1994) > at > org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1852) > at org.apache.logging.log4j.spi.AbstractLogger.log(AbstractLogger.java:1642) > at -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [logging-log4j2] ppkarwasz commented on a change in pull request #761: LOG4J2-3407 Check for non-existent appender when parsing properties
ppkarwasz commented on a change in pull request #761:
URL: https://github.com/apache/logging-log4j2/pull/761#discussion_r810286544
##
File path:
log4j-1.2-api/src/main/java/org/apache/log4j/config/PropertiesConfiguration.java
##
@@ -436,6 +436,10 @@ public Appender parseAppender(final Properties props,
final String appenderName)
final String layoutPrefix = prefix + ".layout";
final String filterPrefix = APPENDER_PREFIX + appenderName +
".filter.";
final String className = OptionConverter.findAndSubst(prefix, props);
+if (className == null) {
+LOGGER.debug("Appender \"" + appenderName + "\" does not exist.");
+return null;
+}
Review comment:
Remark also that Log4j 1.x behaves differently
- whenever **any** component has an empty property the error "Could not find
value for key ..." is logged (cf. [source
code](https://github.com/apache/logging-log4j1/blob/v1_2_17/src/main/java/org/apache/log4j/helpers/OptionConverter.java#L120).
- then there is a message "Could not instantiate appender named ..." (cf.
[source
code](https://github.com/apache/logging-log4j1/blob/de9f0ea504db9d1178db2cf45323d8e182a5df0a/src/main/java/org/apache/log4j/PropertyConfigurator.java#L790)).
This should probably be checked just before the return statement. Remark that
appender instantiation can also fail if some other properties are missing (e.g.
`File` for the file appender).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] ppkarwasz commented on a change in pull request #761: LOG4J2-3407 Check for non-existent appender when parsing properties
ppkarwasz commented on a change in pull request #761:
URL: https://github.com/apache/logging-log4j2/pull/761#discussion_r810286544
##
File path:
log4j-1.2-api/src/main/java/org/apache/log4j/config/PropertiesConfiguration.java
##
@@ -436,6 +436,10 @@ public Appender parseAppender(final Properties props,
final String appenderName)
final String layoutPrefix = prefix + ".layout";
final String filterPrefix = APPENDER_PREFIX + appenderName +
".filter.";
final String className = OptionConverter.findAndSubst(prefix, props);
+if (className == null) {
+LOGGER.debug("Appender \"" + appenderName + "\" does not exist.");
+return null;
+}
Review comment:
I would move this behavior to the `BuilderManager` (so we solve the
problem at the source). The `BuilderManager` should return `new
AppenderWrapper(null)` so that line 445 does not throw.
Remark also that Log4j 1.x behaves differently
- whenever **any** component has an empty property the error "Could not find
value for key ..." is logged (cf. [source
code](https://github.com/apache/logging-log4j1/blob/v1_2_17/src/main/java/org/apache/log4j/helpers/OptionConverter.java#L120).
- then there is a message "Could not instantiate appender named ..." (cf.
[source
code](https://github.com/apache/logging-log4j1/blob/de9f0ea504db9d1178db2cf45323d8e182a5df0a/src/main/java/org/apache/log4j/PropertyConfigurator.java#L790)).
This should probably be checked just before the return statement. Remark that
appender instantiation can also fail if some other properties are missing (e.g.
`File` for the file appender).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] kerysgang937 commented on a change in pull request #761: LOG4J2-3407 Check for non-existent appender when parsing properties
kerysgang937 commented on a change in pull request #761:
URL: https://github.com/apache/logging-log4j2/pull/761#discussion_r810068934
##
File path: log4j-1.2-api/src/test/resources/LOG4J2-3407.properties
##
@@ -0,0 +1,26 @@
+#
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements. See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership.
+# The ASF licenses this file to You under the Apache License, Version 2.0
+# (the "License"); you may not use this file except in compliance with
+# the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+
+log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
+log4j.appender.CONSOLE.filter.1=org.apache.log4j.config.NeutralFilterFixture
+log4j.appender.CONSOLE.filter.1.onMatch=neutral
+log4j.appender.CONSOLE.Target=System.out
+log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
+log4j.appender.CONSOLE.layout.ConversionPattern=%d{-MM-dd HH:mm:ss} %-5p
%c{1}:%L - %m%n
+
+log4j.logger.org.apache.log4j.xml=trace, A1
+log4j.rootLogger=trace, CONSOLE
Review comment:
Kerstintdurden:release-2.2Ftownship.onelink.me
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Work started] (LOG4J2-3404) Leak of DefaultConfiguration instances
[
https://issues.apache.org/jira/browse/LOG4J2-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on LOG4J2-3404 started by Carter Kozak.
> Leak of DefaultConfiguration instances
> --
>
> Key: LOG4J2-3404
> URL: https://issues.apache.org/jira/browse/LOG4J2-3404
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.17.1
>Reporter: Piotr P. Karwasz
>Assignee: Carter Kozak
>Priority: Major
>
> If an appender does not specify a layout a default {{PatternLayout}} is
> created *together* with a {{{}DefaultConfiguration{}}}, which is never
> stopped nor attached to a {{{}LoggerContext{}}}.
> For example, if we using a simple file appender:
> {code:java}
> appenders:
> File:
> name: FILE
> fileName: logs/myfile.log {code}
> and running:
> {code:java}
> LogManager.getLogger("test");{code}
> will result in the following (redacted and commented) status logger output:
> {code:java}
> # DefaultConfiguration from LoggerContext constructor
> DEBUG StatusLogger Starting OutputStreamManager SYSTEM_OUT.false.false-1
> DEBUG StatusLogger Starting LoggerContext[name=2437c6dc,
> org.apache.logging.log4j.core.LoggerContext@45752059]...
> DEBUG StatusLogger Reconfiguration started for context[name=2437c6dc] at URI
> null (org.apache.logging.log4j.core.LoggerContext@45752059) with optional
> ClassLoader: null
> # Spurious DefaultConfiguration used to create default PatternLayout
> # This manager will **never** stop
> DEBUG StatusLogger Starting OutputStreamManager SYSTEM_OUT.false.false-2
> # My appender
> DEBUG StatusLogger Starting FileManager logs/myfile.log
> DEBUG StatusLogger Starting configuration
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]
> DEBUG StatusLogger Started configuration
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml] OK.
> # The first DefaultConfiguration stops
> #
> TRACE StatusLogger Stopping
> org.apache.logging.log4j.core.config.DefaultConfiguration@145f66e3...
> DEBUG StatusLogger Shutting down OutputStreamManager SYSTEM_OUT.false.false-1
> DEBUG StatusLogger OutputStream closed
> DEBUG StatusLogger Shut down OutputStreamManager SYSTEM_OUT.false.false-1,
> all resources released: true
> DEBUG StatusLogger Appender DefaultConsole-1 stopped with status true
> TRACE StatusLogger DefaultConfiguration stopped 1 remaining Appenders.
> TRACE StatusLogger DefaultConfiguration cleaning Appenders from 1
> LoggerConfigs.
> DEBUG StatusLogger Stopped
> org.apache.logging.log4j.core.config.DefaultConfiguration@145f66e3 OK
> # At JVM shutdown
> TRACE StatusLogger Stopping
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]...
> TRACE StatusLogger YamlConfiguration notified 2 ReliabilityStrategies that
> config will be stopped.
> TRACE StatusLogger YamlConfiguration stopping 1 LoggerConfigs.
> TRACE StatusLogger YamlConfiguration stopping root LoggerConfig.
> TRACE StatusLogger YamlConfiguration notifying ReliabilityStrategies that
> appenders will be stopped.
> TRACE StatusLogger YamlConfiguration stopping remaining Appenders.
> DEBUG StatusLogger Appender CONSOLE stopped with status true
> TRACE StatusLogger YamlConfiguration stopped 1 remaining Appenders.
> TRACE StatusLogger YamlConfiguration cleaning Appenders from 2 LoggerConfigs.
> DEBUG StatusLogger Stopped
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]
> OK{code}
> I can provide a PR to prevent the leaking of {{DefaultConfiguration}} s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3404) Leak of DefaultConfiguration instances
[
https://issues.apache.org/jira/browse/LOG4J2-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak reassigned LOG4J2-3404:
Assignee: Carter Kozak
> Leak of DefaultConfiguration instances
> --
>
> Key: LOG4J2-3404
> URL: https://issues.apache.org/jira/browse/LOG4J2-3404
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.17.1
>Reporter: Piotr P. Karwasz
>Assignee: Carter Kozak
>Priority: Major
>
> If an appender does not specify a layout a default {{PatternLayout}} is
> created *together* with a {{{}DefaultConfiguration{}}}, which is never
> stopped nor attached to a {{{}LoggerContext{}}}.
> For example, if we using a simple file appender:
> {code:java}
> appenders:
> File:
> name: FILE
> fileName: logs/myfile.log {code}
> and running:
> {code:java}
> LogManager.getLogger("test");{code}
> will result in the following (redacted and commented) status logger output:
> {code:java}
> # DefaultConfiguration from LoggerContext constructor
> DEBUG StatusLogger Starting OutputStreamManager SYSTEM_OUT.false.false-1
> DEBUG StatusLogger Starting LoggerContext[name=2437c6dc,
> org.apache.logging.log4j.core.LoggerContext@45752059]...
> DEBUG StatusLogger Reconfiguration started for context[name=2437c6dc] at URI
> null (org.apache.logging.log4j.core.LoggerContext@45752059) with optional
> ClassLoader: null
> # Spurious DefaultConfiguration used to create default PatternLayout
> # This manager will **never** stop
> DEBUG StatusLogger Starting OutputStreamManager SYSTEM_OUT.false.false-2
> # My appender
> DEBUG StatusLogger Starting FileManager logs/myfile.log
> DEBUG StatusLogger Starting configuration
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]
> DEBUG StatusLogger Started configuration
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml] OK.
> # The first DefaultConfiguration stops
> #
> TRACE StatusLogger Stopping
> org.apache.logging.log4j.core.config.DefaultConfiguration@145f66e3...
> DEBUG StatusLogger Shutting down OutputStreamManager SYSTEM_OUT.false.false-1
> DEBUG StatusLogger OutputStream closed
> DEBUG StatusLogger Shut down OutputStreamManager SYSTEM_OUT.false.false-1,
> all resources released: true
> DEBUG StatusLogger Appender DefaultConsole-1 stopped with status true
> TRACE StatusLogger DefaultConfiguration stopped 1 remaining Appenders.
> TRACE StatusLogger DefaultConfiguration cleaning Appenders from 1
> LoggerConfigs.
> DEBUG StatusLogger Stopped
> org.apache.logging.log4j.core.config.DefaultConfiguration@145f66e3 OK
> # At JVM shutdown
> TRACE StatusLogger Stopping
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]...
> TRACE StatusLogger YamlConfiguration notified 2 ReliabilityStrategies that
> config will be stopped.
> TRACE StatusLogger YamlConfiguration stopping 1 LoggerConfigs.
> TRACE StatusLogger YamlConfiguration stopping root LoggerConfig.
> TRACE StatusLogger YamlConfiguration notifying ReliabilityStrategies that
> appenders will be stopped.
> TRACE StatusLogger YamlConfiguration stopping remaining Appenders.
> DEBUG StatusLogger Appender CONSOLE stopped with status true
> TRACE StatusLogger YamlConfiguration stopped 1 remaining Appenders.
> TRACE StatusLogger YamlConfiguration cleaning Appenders from 2 LoggerConfigs.
> DEBUG StatusLogger Stopped
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]
> OK{code}
> I can provide a PR to prevent the leaking of {{DefaultConfiguration}} s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3404) Leak of DefaultConfiguration instances
[
https://issues.apache.org/jira/browse/LOG4J2-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak resolved LOG4J2-3404.
--
Resolution: Fixed
> Leak of DefaultConfiguration instances
> --
>
> Key: LOG4J2-3404
> URL: https://issues.apache.org/jira/browse/LOG4J2-3404
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.17.1
>Reporter: Piotr P. Karwasz
>Assignee: Carter Kozak
>Priority: Major
>
> If an appender does not specify a layout a default {{PatternLayout}} is
> created *together* with a {{{}DefaultConfiguration{}}}, which is never
> stopped nor attached to a {{{}LoggerContext{}}}.
> For example, if we using a simple file appender:
> {code:java}
> appenders:
> File:
> name: FILE
> fileName: logs/myfile.log {code}
> and running:
> {code:java}
> LogManager.getLogger("test");{code}
> will result in the following (redacted and commented) status logger output:
> {code:java}
> # DefaultConfiguration from LoggerContext constructor
> DEBUG StatusLogger Starting OutputStreamManager SYSTEM_OUT.false.false-1
> DEBUG StatusLogger Starting LoggerContext[name=2437c6dc,
> org.apache.logging.log4j.core.LoggerContext@45752059]...
> DEBUG StatusLogger Reconfiguration started for context[name=2437c6dc] at URI
> null (org.apache.logging.log4j.core.LoggerContext@45752059) with optional
> ClassLoader: null
> # Spurious DefaultConfiguration used to create default PatternLayout
> # This manager will **never** stop
> DEBUG StatusLogger Starting OutputStreamManager SYSTEM_OUT.false.false-2
> # My appender
> DEBUG StatusLogger Starting FileManager logs/myfile.log
> DEBUG StatusLogger Starting configuration
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]
> DEBUG StatusLogger Started configuration
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml] OK.
> # The first DefaultConfiguration stops
> #
> TRACE StatusLogger Stopping
> org.apache.logging.log4j.core.config.DefaultConfiguration@145f66e3...
> DEBUG StatusLogger Shutting down OutputStreamManager SYSTEM_OUT.false.false-1
> DEBUG StatusLogger OutputStream closed
> DEBUG StatusLogger Shut down OutputStreamManager SYSTEM_OUT.false.false-1,
> all resources released: true
> DEBUG StatusLogger Appender DefaultConsole-1 stopped with status true
> TRACE StatusLogger DefaultConfiguration stopped 1 remaining Appenders.
> TRACE StatusLogger DefaultConfiguration cleaning Appenders from 1
> LoggerConfigs.
> DEBUG StatusLogger Stopped
> org.apache.logging.log4j.core.config.DefaultConfiguration@145f66e3 OK
> # At JVM shutdown
> TRACE StatusLogger Stopping
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]...
> TRACE StatusLogger YamlConfiguration notified 2 ReliabilityStrategies that
> config will be stopped.
> TRACE StatusLogger YamlConfiguration stopping 1 LoggerConfigs.
> TRACE StatusLogger YamlConfiguration stopping root LoggerConfig.
> TRACE StatusLogger YamlConfiguration notifying ReliabilityStrategies that
> appenders will be stopped.
> TRACE StatusLogger YamlConfiguration stopping remaining Appenders.
> DEBUG StatusLogger Appender CONSOLE stopped with status true
> TRACE StatusLogger YamlConfiguration stopped 1 remaining Appenders.
> TRACE StatusLogger YamlConfiguration cleaning Appenders from 2 LoggerConfigs.
> DEBUG StatusLogger Stopped
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]
> OK{code}
> I can provide a PR to prevent the leaking of {{DefaultConfiguration}} s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3404) Leak of DefaultConfiguration instances
[
https://issues.apache.org/jira/browse/LOG4J2-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494743#comment-17494743
]
ASF subversion and git services commented on LOG4J2-3404:
-
Commit 77f04501f73b5255e9993b1da8c57db54372a4aa in logging-log4j2's branch
refs/heads/release-2.x from Carter Kozak
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=77f0450 ]
LOG4J2-3404 changelog
> Leak of DefaultConfiguration instances
> --
>
> Key: LOG4J2-3404
> URL: https://issues.apache.org/jira/browse/LOG4J2-3404
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.17.1
>Reporter: Piotr P. Karwasz
>Priority: Major
>
> If an appender does not specify a layout a default {{PatternLayout}} is
> created *together* with a {{{}DefaultConfiguration{}}}, which is never
> stopped nor attached to a {{{}LoggerContext{}}}.
> For example, if we using a simple file appender:
> {code:java}
> appenders:
> File:
> name: FILE
> fileName: logs/myfile.log {code}
> and running:
> {code:java}
> LogManager.getLogger("test");{code}
> will result in the following (redacted and commented) status logger output:
> {code:java}
> # DefaultConfiguration from LoggerContext constructor
> DEBUG StatusLogger Starting OutputStreamManager SYSTEM_OUT.false.false-1
> DEBUG StatusLogger Starting LoggerContext[name=2437c6dc,
> org.apache.logging.log4j.core.LoggerContext@45752059]...
> DEBUG StatusLogger Reconfiguration started for context[name=2437c6dc] at URI
> null (org.apache.logging.log4j.core.LoggerContext@45752059) with optional
> ClassLoader: null
> # Spurious DefaultConfiguration used to create default PatternLayout
> # This manager will **never** stop
> DEBUG StatusLogger Starting OutputStreamManager SYSTEM_OUT.false.false-2
> # My appender
> DEBUG StatusLogger Starting FileManager logs/myfile.log
> DEBUG StatusLogger Starting configuration
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]
> DEBUG StatusLogger Started configuration
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml] OK.
> # The first DefaultConfiguration stops
> #
> TRACE StatusLogger Stopping
> org.apache.logging.log4j.core.config.DefaultConfiguration@145f66e3...
> DEBUG StatusLogger Shutting down OutputStreamManager SYSTEM_OUT.false.false-1
> DEBUG StatusLogger OutputStream closed
> DEBUG StatusLogger Shut down OutputStreamManager SYSTEM_OUT.false.false-1,
> all resources released: true
> DEBUG StatusLogger Appender DefaultConsole-1 stopped with status true
> TRACE StatusLogger DefaultConfiguration stopped 1 remaining Appenders.
> TRACE StatusLogger DefaultConfiguration cleaning Appenders from 1
> LoggerConfigs.
> DEBUG StatusLogger Stopped
> org.apache.logging.log4j.core.config.DefaultConfiguration@145f66e3 OK
> # At JVM shutdown
> TRACE StatusLogger Stopping
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]...
> TRACE StatusLogger YamlConfiguration notified 2 ReliabilityStrategies that
> config will be stopped.
> TRACE StatusLogger YamlConfiguration stopping 1 LoggerConfigs.
> TRACE StatusLogger YamlConfiguration stopping root LoggerConfig.
> TRACE StatusLogger YamlConfiguration notifying ReliabilityStrategies that
> appenders will be stopped.
> TRACE StatusLogger YamlConfiguration stopping remaining Appenders.
> DEBUG StatusLogger Appender CONSOLE stopped with status true
> TRACE StatusLogger YamlConfiguration stopped 1 remaining Appenders.
> TRACE StatusLogger YamlConfiguration cleaning Appenders from 2 LoggerConfigs.
> DEBUG StatusLogger Stopped
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]
> OK{code}
> I can provide a PR to prevent the leaking of {{DefaultConfiguration}} s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3404) Leak of DefaultConfiguration instances
[
https://issues.apache.org/jira/browse/LOG4J2-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494741#comment-17494741
]
ASF subversion and git services commented on LOG4J2-3404:
-
Commit 9ffa643d69cdca4764bc2c4c0fe529379d17db2b in logging-log4j2's branch
refs/heads/release-2.x from ppkarwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=9ffa643 ]
[LOG4J2-3404] Create default layouts using the available Configuration (#756)
This PR provides a `Configuration` argument whenever possible.
`PatternLayout` no longer creates (and leaks) DefaultConfiguration instances
> Leak of DefaultConfiguration instances
> --
>
> Key: LOG4J2-3404
> URL: https://issues.apache.org/jira/browse/LOG4J2-3404
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 2.17.1
>Reporter: Piotr P. Karwasz
>Priority: Major
>
> If an appender does not specify a layout a default {{PatternLayout}} is
> created *together* with a {{{}DefaultConfiguration{}}}, which is never
> stopped nor attached to a {{{}LoggerContext{}}}.
> For example, if we using a simple file appender:
> {code:java}
> appenders:
> File:
> name: FILE
> fileName: logs/myfile.log {code}
> and running:
> {code:java}
> LogManager.getLogger("test");{code}
> will result in the following (redacted and commented) status logger output:
> {code:java}
> # DefaultConfiguration from LoggerContext constructor
> DEBUG StatusLogger Starting OutputStreamManager SYSTEM_OUT.false.false-1
> DEBUG StatusLogger Starting LoggerContext[name=2437c6dc,
> org.apache.logging.log4j.core.LoggerContext@45752059]...
> DEBUG StatusLogger Reconfiguration started for context[name=2437c6dc] at URI
> null (org.apache.logging.log4j.core.LoggerContext@45752059) with optional
> ClassLoader: null
> # Spurious DefaultConfiguration used to create default PatternLayout
> # This manager will **never** stop
> DEBUG StatusLogger Starting OutputStreamManager SYSTEM_OUT.false.false-2
> # My appender
> DEBUG StatusLogger Starting FileManager logs/myfile.log
> DEBUG StatusLogger Starting configuration
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]
> DEBUG StatusLogger Started configuration
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml] OK.
> # The first DefaultConfiguration stops
> #
> TRACE StatusLogger Stopping
> org.apache.logging.log4j.core.config.DefaultConfiguration@145f66e3...
> DEBUG StatusLogger Shutting down OutputStreamManager SYSTEM_OUT.false.false-1
> DEBUG StatusLogger OutputStream closed
> DEBUG StatusLogger Shut down OutputStreamManager SYSTEM_OUT.false.false-1,
> all resources released: true
> DEBUG StatusLogger Appender DefaultConsole-1 stopped with status true
> TRACE StatusLogger DefaultConfiguration stopped 1 remaining Appenders.
> TRACE StatusLogger DefaultConfiguration cleaning Appenders from 1
> LoggerConfigs.
> DEBUG StatusLogger Stopped
> org.apache.logging.log4j.core.config.DefaultConfiguration@145f66e3 OK
> # At JVM shutdown
> TRACE StatusLogger Stopping
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]...
> TRACE StatusLogger YamlConfiguration notified 2 ReliabilityStrategies that
> config will be stopped.
> TRACE StatusLogger YamlConfiguration stopping 1 LoggerConfigs.
> TRACE StatusLogger YamlConfiguration stopping root LoggerConfig.
> TRACE StatusLogger YamlConfiguration notifying ReliabilityStrategies that
> appenders will be stopped.
> TRACE StatusLogger YamlConfiguration stopping remaining Appenders.
> DEBUG StatusLogger Appender CONSOLE stopped with status true
> TRACE StatusLogger YamlConfiguration stopped 1 remaining Appenders.
> TRACE StatusLogger YamlConfiguration cleaning Appenders from 2 LoggerConfigs.
> DEBUG StatusLogger Stopped
> YamlConfiguration[location=D:\Examples\log4j\target\classes\log4j2.yml]
> OK{code}
> I can provide a PR to prevent the leaking of {{DefaultConfiguration}} s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] carterkozak merged pull request #756: [LOG4J2-3404] Creates default layouts using the available Configuration
carterkozak merged pull request #756: URL: https://github.com/apache/logging-log4j2/pull/756 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LOG4J2-3370) Typo-Bug in current SLF4J Bridge
[
https://issues.apache.org/jira/browse/LOG4J2-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494738#comment-17494738
]
Ralph Goers commented on LOG4J2-3370:
-
I am thinking it requires a separate log4j-slf4j20-impl because we will have to
use classes that are not available in prior versions and the Logger interface
has methods not in 1.8. But you may be correct.
> Typo-Bug in current SLF4J Bridge
>
>
> Key: LOG4J2-3370
> URL: https://issues.apache.org/jira/browse/LOG4J2-3370
> Project: Log4j 2
> Issue Type: Bug
> Components: SLF4J Bridge
>Affects Versions: 2.17.1
>Reporter: Timon H.
>Assignee: Ralph Goers
>Priority: Major
> Fix For: 2.18.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The SLF4J Bridge (log4j-slf4j18-impl:2.17.1) is currently broken as it
> contains the same typo bug of SLF4J-API which was fixed in SLF4J-API
> 2.0.0-alpha3 and therefore leads to an API mismatch error. In the
> {_}org.apache.logging.slf4j.SLF4JServiceProvider{_}, the
> {_}getRequesteApiVersion{_}-Method need to be refactored to
> {_}getRequeste{*}d{*}ApiVersion{_}.
> h3. See the Changelog of SLF4J-API 2.0.0-alpha3:
> * The {{getRequesteApiVersion}} method in {{SLF4JServiceProvider}} was
> renamed as getRequeste{*}d{*}ApiVersion. This fixes
> [SLF4J-516|https://jira.qos.ch/browse/SLF4J-516].
> This leads to the following exception during the use of
> log4j-slf4j18-impl:2.17.1 with the current SLF4J-API:
> {{Unexpected problem occured during version sanity check}}
> {{Reported exception:}}
> {{java.lang.AbstractMethodError: Receiver class
> org.apache.logging.slf4j.SLF4JServiceProvider does not define or inherit an
> implementation of the resolved method 'abstract java.lang.String
> getRequestedApiVersion()' of interface org.slf4j.spi.SLF4JServiceProvider.}}
> {{ at org.slf4j.LoggerFactory.versionSanityCheck(LoggerFactory.java:297)}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3407) PropertiesConfiguration.parseAppender NPE when logger refers to non-existent appender
[
https://issues.apache.org/jira/browse/LOG4J2-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494737#comment-17494737
]
Ralph Goers commented on LOG4J2-3407:
-
My vote is to emulate the V1 behavior.
> PropertiesConfiguration.parseAppender NPE when logger refers to non-existent
> appender
> -
>
> Key: LOG4J2-3407
> URL: https://issues.apache.org/jira/browse/LOG4J2-3407
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
>Reporter: Kenny MacLeod
>Priority: Minor
> Attachments: LOG4J2-3407.patch
>
>
> When parsing a {{log4j.proprties}} file that contains a logger that refers to
> a non-existent appender, you get a NPE.
> While this is clearly a malformed configuration, Log4j 1.2.x silently ignored
> this, and the log4j2 bridge should be as tolerant.
> Note that {{PropertiesConfiguration#parseLogger}} is already tolerant of the
> appender being missing (it does a null check on the result of
> {{{}parseAppender{}}}), but {{parseAppender}} itself is not tolerant.
> An example config would be:
> {noformat}
> log4j.logger.mylogger=INFO, myappender
> # log4j.appender.myappender=org.apache.log4j.ConsoleAppender
> {noformat}
> The appender has been commented out, to illustrate the bug.
> Stack trace from log4j 2.17.1:
> {noformat}
> Caused by: java.lang.NullPointerException
> at
> org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:72)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:428)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:406)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLoggers(PropertiesConfiguration.java:351)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:304)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:93)
> at
> org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:60)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:293)
> 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:196)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:137)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:55)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:47)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:33)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:363)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:388)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] ppkarwasz commented on a change in pull request #762: Trim property values
ppkarwasz commented on a change in pull request #762:
URL: https://github.com/apache/logging-log4j2/pull/762#discussion_r810181303
##
File path:
log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1ConfigurationParser.java
##
@@ -159,7 +159,7 @@ private void warn(final String string) {
}
private void buildAppender(final String appenderName, final String
appenderClass) {
-switch (appenderClass) {
+switch (appenderClass.trim()) {
Review comment:
@garydgregory: I double checked that this private method is never called
with a null `appenderClass`, but can you check again?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] ppkarwasz commented on a change in pull request #762: Trim property values
ppkarwasz commented on a change in pull request #762:
URL: https://github.com/apache/logging-log4j2/pull/762#discussion_r810179530
##
File path:
log4j-1.2-api/src/main/java/org/apache/log4j/builders/BuilderManager.java
##
@@ -71,7 +71,7 @@ public Appender parseAppender(String name, String className,
String prefix, Stri
String filterPrefix, Properties props, PropertiesConfiguration
config) {
Objects.requireNonNull(plugins, "plugins");
Objects.requireNonNull(className, "className");
-PluginType plugin = plugins.get(className.toLowerCase());
+PluginType plugin = plugins.get(className.toLowerCase().trim());
Review comment:
AFAIK `toLowerCase()` does not return nulls. :-) Besides, `className` is
protected by an `Objects.requireNonNull`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (LOG4J2-3370) Typo-Bug in current SLF4J Bridge
[
https://issues.apache.org/jira/browse/LOG4J2-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494722#comment-17494722
]
Piotr P. Karwasz commented on LOG4J2-3370:
--
Fixing this one actually does not require a separate {{log4j-slf4j20-impl}}
module: the {{SLF4JServiceProvider}} just needs to implement both
{{getRequesteApiVersion}} (returning 1.8.99) and {{getRequestedApiVersion}}
(returning 2.0.99}.
A separate module, Maven profile or something similar would however be required
to test the {{log4j-slf4j18-impl}} against to different versions of the
{{slf4j-api}}.
On the other hand solving LOG4J2-2975 in the same way (just adding a
{{LoggingEventBuilder makeLoggingEventBuilder(Level)}} method) might give a
{{NoClassDefFoundError}} in theory. In practice HotSpot verifies public methods
lazily when they are actually called.
> Typo-Bug in current SLF4J Bridge
>
>
> Key: LOG4J2-3370
> URL: https://issues.apache.org/jira/browse/LOG4J2-3370
> Project: Log4j 2
> Issue Type: Bug
> Components: SLF4J Bridge
>Affects Versions: 2.17.1
>Reporter: Timon H.
>Assignee: Ralph Goers
>Priority: Major
> Fix For: 2.18.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The SLF4J Bridge (log4j-slf4j18-impl:2.17.1) is currently broken as it
> contains the same typo bug of SLF4J-API which was fixed in SLF4J-API
> 2.0.0-alpha3 and therefore leads to an API mismatch error. In the
> {_}org.apache.logging.slf4j.SLF4JServiceProvider{_}, the
> {_}getRequesteApiVersion{_}-Method need to be refactored to
> {_}getRequeste{*}d{*}ApiVersion{_}.
> h3. See the Changelog of SLF4J-API 2.0.0-alpha3:
> * The {{getRequesteApiVersion}} method in {{SLF4JServiceProvider}} was
> renamed as getRequeste{*}d{*}ApiVersion. This fixes
> [SLF4J-516|https://jira.qos.ch/browse/SLF4J-516].
> This leads to the following exception during the use of
> log4j-slf4j18-impl:2.17.1 with the current SLF4J-API:
> {{Unexpected problem occured during version sanity check}}
> {{Reported exception:}}
> {{java.lang.AbstractMethodError: Receiver class
> org.apache.logging.slf4j.SLF4JServiceProvider does not define or inherit an
> implementation of the resolved method 'abstract java.lang.String
> getRequestedApiVersion()' of interface org.slf4j.spi.SLF4JServiceProvider.}}
> {{ at org.slf4j.LoggerFactory.versionSanityCheck(LoggerFactory.java:297)}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] garydgregory commented on a change in pull request #762: Trim property values
garydgregory commented on a change in pull request #762:
URL: https://github.com/apache/logging-log4j2/pull/762#discussion_r810156858
##
File path:
log4j-1.2-api/src/main/java/org/apache/log4j/builders/BuilderManager.java
##
@@ -95,7 +95,8 @@ public Filter parseFilter(String className, Element
filterElement, XmlConfigurat
}
public Filter parseFilter(String className, String filterPrefix,
Properties props, PropertiesConfiguration config) {
-PluginType plugin = plugins.get(className.toLowerCase());
+Objects.requireNonNull(className, "className");
+PluginType plugin = plugins.get(className.toLowerCase().trim());
Review comment:
NPE
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on a change in pull request #762: Trim property values
garydgregory commented on a change in pull request #762:
URL: https://github.com/apache/logging-log4j2/pull/762#discussion_r810157109
##
File path:
log4j-1.2-api/src/main/java/org/apache/log4j/builders/BuilderManager.java
##
@@ -118,7 +119,8 @@ public Layout parseLayout(String className, Element
layoutElement, XmlConfigurat
return null;
}
public Layout parseLayout(String className, String layoutPrefix,
Properties props, PropertiesConfiguration config) {
-PluginType plugin = plugins.get(className.toLowerCase());
+Objects.requireNonNull(className, "className");
+PluginType plugin = plugins.get(className.toLowerCase().trim());
Review comment:
NPE
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on a change in pull request #762: Trim property values
garydgregory commented on a change in pull request #762:
URL: https://github.com/apache/logging-log4j2/pull/762#discussion_r810156532
##
File path:
log4j-1.2-api/src/main/java/org/apache/log4j/builders/BuilderManager.java
##
@@ -71,7 +71,7 @@ public Appender parseAppender(String name, String className,
String prefix, Stri
String filterPrefix, Properties props, PropertiesConfiguration
config) {
Objects.requireNonNull(plugins, "plugins");
Objects.requireNonNull(className, "className");
-PluginType plugin = plugins.get(className.toLowerCase());
+PluginType plugin = plugins.get(className.toLowerCase().trim());
Review comment:
This could cause an NPE, see the bull check on the line below.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] ppkarwasz opened a new pull request #762: Trim property values
ppkarwasz opened a new pull request #762: URL: https://github.com/apache/logging-log4j2/pull/762 Log4j 1.x almost always trimmed the values found in the configuration, the Log4j 1.x bridge should do the same. Since `OptionConverter` already does most of the trimming, only class name trimming must be added. The (obsolete?) `Log4j1ConfigurationFactory` also fails to trim spaces in the _"level and appenders"_ specification. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LOG4J2-3393) JSON template layout performance regression
[
https://issues.apache.org/jira/browse/LOG4J2-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494685#comment-17494685
]
ASF subversion and git services commented on LOG4J2-3393:
-
Commit dd25a31504b803034e5591c1e17ea87898fbe952 in logging-log4j2's branch
refs/heads/LOG4J2-3393 from Volkan Yazici
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=dd25a31 ]
LOG4J2-3393 Bump JMH from 1.21 to 1.34.
> JSON template layout performance regression
> ---
>
> Key: LOG4J2-3393
> URL: https://issues.apache.org/jira/browse/LOG4J2-3393
> Project: Log4j 2
> Issue Type: Improvement
> Components: JsonTemplateLayout
>Affects Versions: 2.17.1
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> JTL performance is used to be on par with \{{log4j2-ecs-layout}}, though this
> is not the case anymore, there is a slight degradation. This story aims to
> investigate what is going on and fix it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3393) JSON template layout performance regression
[
https://issues.apache.org/jira/browse/LOG4J2-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494686#comment-17494686
]
ASF subversion and git services commented on LOG4J2-3393:
-
Commit 8a85c0316c69da580effe33305bbdc7c452f32a6 in logging-log4j2's branch
refs/heads/LOG4J2-3393 from Volkan Yazici
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=8a85c03 ]
LOG4J2-3393 Use a single LogEvent in JMH benchmarks.
> JSON template layout performance regression
> ---
>
> Key: LOG4J2-3393
> URL: https://issues.apache.org/jira/browse/LOG4J2-3393
> Project: Log4j 2
> Issue Type: Improvement
> Components: JsonTemplateLayout
>Affects Versions: 2.17.1
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> JTL performance is used to be on par with \{{log4j2-ecs-layout}}, though this
> is not the case anymore, there is a slight degradation. This story aims to
> investigate what is going on and fix it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-2368) Outputs wrong message when used within overridden Throwable method
[
https://issues.apache.org/jira/browse/LOG4J2-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494684#comment-17494684
]
ASF subversion and git services commented on LOG4J2-2368:
-
Commit 8d55e01dccca05fd14df9a08b8da2795209b3625 in logging-log4j2's branch
refs/heads/LOG4J2-3393 from Volkan Yazici
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=8d55e01 ]
LOG4J2-2368 Test JsonTemplateLayout's ThreadLocalRecycler against nested
logging.
> Outputs wrong message when used within overridden Throwable method
> --
>
> Key: LOG4J2-2368
> URL: https://issues.apache.org/jira/browse/LOG4J2-2368
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.8.1, 2.11.0
>Reporter: Taisuke Tashiro
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.11.1, 3.0.0
>
>
> When a message A is logged with Throwable object and if message B is logged
> within the Throwable object's method, message A is lost and message B is
> logged instead.
> Following is a code example to recreate the issue:
> {{Logger loggerA = LogManager.getLogger("A");}}
> {{Logger loggerB = LogManager.getLogger("B");}}
> {{Throwable throwable =}}
> {{ new Throwable() {}}
> {{ public String getMessage() {}}
> {{ loggerB.debug("MESSAGE B");}}
> {{ return "message";}}
> {{ }}}
> {{ };}}
> {{loggerA.debug("MESSEGE A", throwable);}}
> "MESSAGE A" should be logged to loggerA but "MESSAGE B" is logged instead.
> Cause of this problem is reuse of StringBuilder instance within the execution
> thread in org.apache.logging.log4j.core.layout.AbstractStringLayout class.
> While processing loggerA, getMessage() is called by
> org.apache.logging.log4j.core.impl.ThrowableProxy to obtain throwable object
> information and the content of StringBuilder is changed by loggerB.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] kerysgang937 commented on a change in pull request #761: LOG4J2-3407 Check for non-existent appender when parsing properties
kerysgang937 commented on a change in pull request #761:
URL: https://github.com/apache/logging-log4j2/pull/761#discussion_r810069282
##
File path: log4j-1.2-api/src/test/resources/LOG4J2-3407.properties
##
@@ -0,0 +1,26 @@
+#
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements. See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership.
+# The ASF licenses this file to You under the Apache License, Version 2.0
+# (the "License"); you may not use this file except in compliance with
+# the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+
+log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
+log4j.appender.CONSOLE.filter.1=org.apache.log4j.config.NeutralFilterFixture
+log4j.appender.CONSOLE.filter.1.onMatch=neutral
+log4j.appender.CONSOLE.Target=System.out
+log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
+log4j.appender.CONSOLE.layout.ConversionPattern=%d{-MM-dd HH:mm:ss} %-5p
%c{1}:%L - %m%n
+
+log4j.logger.org.apache.log4j.xml=trace, A1
+log4j.rootLogger=trace, CONSOLE
Review comment:
log4j-1.2-api/src/test/resources/LOG4J2-3407.properties
##
File path: log4j-1.2-api/src/test/resources/LOG4J2-3407.properties
##
@@ -0,0 +1,26 @@
+#
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements. See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership.
+# The ASF licenses this file to You under the Apache License, Version 2.0
+# (the "License"); you may not use this file except in compliance with
+# the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+
+log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
+log4j.appender.CONSOLE.filter.1=org.apache.log4j.config.NeutralFilterFixture
+log4j.appender.CONSOLE.filter.1.onMatch=neutral
+log4j.appender.CONSOLE.Target=System.out
+log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
+log4j.appender.CONSOLE.layout.ConversionPattern=%d{-MM-dd HH:mm:ss} %-5p
%c{1}:%L - %m%n
+
+log4j.logger.org.apache.log4j.xml=trace, A1
+log4j.rootLogger=trace, CONSOLE
Review comment:
Kerstintdurden:release-2.2Ftownship.onelink.me
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (LOG4J2-3407) PropertiesConfiguration.parseAppender NPE when logger refers to non-existent appender
[
https://issues.apache.org/jira/browse/LOG4J2-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494640#comment-17494640
]
Gary D. Gregory commented on LOG4J2-3407:
-
Yikes. I see 2 issues: give a better exception message and do we want to
emulate the v1 behavior. [~rgoers] any thoughts?
> PropertiesConfiguration.parseAppender NPE when logger refers to non-existent
> appender
> -
>
> Key: LOG4J2-3407
> URL: https://issues.apache.org/jira/browse/LOG4J2-3407
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
>Reporter: Kenny MacLeod
>Priority: Minor
> Attachments: LOG4J2-3407.patch
>
>
> When parsing a {{log4j.proprties}} file that contains a logger that refers to
> a non-existent appender, you get a NPE.
> While this is clearly a malformed configuration, Log4j 1.2.x silently ignored
> this, and the log4j2 bridge should be as tolerant.
> Note that {{PropertiesConfiguration#parseLogger}} is already tolerant of the
> appender being missing (it does a null check on the result of
> {{{}parseAppender{}}}), but {{parseAppender}} itself is not tolerant.
> An example config would be:
> {noformat}
> log4j.logger.mylogger=INFO, myappender
> # log4j.appender.myappender=org.apache.log4j.ConsoleAppender
> {noformat}
> The appender has been commented out, to illustrate the bug.
> Stack trace from log4j 2.17.1:
> {noformat}
> Caused by: java.lang.NullPointerException
> at
> org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:72)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:428)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:406)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLoggers(PropertiesConfiguration.java:351)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:304)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:93)
> at
> org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:60)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:293)
> 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:196)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:137)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:55)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:47)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:33)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:363)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:388)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] vy merged pull request #760: Bump log4j2-ecs-layout from 1.0.1 to 1.3.2
vy merged pull request #760: URL: https://github.com/apache/logging-log4j2/pull/760 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [logging-log4j2] vy merged pull request #759: Bump HdrHistogram from 2.1.9 to 2.1.12
vy merged pull request #759: URL: https://github.com/apache/logging-log4j2/pull/759 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LOG4J2-3407) PropertiesConfiguration.parseAppender NPE when logger refers to non-existent appender
[
https://issues.apache.org/jira/browse/LOG4J2-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494576#comment-17494576
]
Kenny MacLeod commented on LOG4J2-3407:
---
Normally, I'd 100% agree with you, but the point of the log4j 1.2 compat layer
is to match the legacy behaviour as much as is practical, and this is what the
legacy behaviour is.
> PropertiesConfiguration.parseAppender NPE when logger refers to non-existent
> appender
> -
>
> Key: LOG4J2-3407
> URL: https://issues.apache.org/jira/browse/LOG4J2-3407
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
>Reporter: Kenny MacLeod
>Priority: Minor
> Attachments: LOG4J2-3407.patch
>
>
> When parsing a {{log4j.proprties}} file that contains a logger that refers to
> a non-existent appender, you get a NPE.
> While this is clearly a malformed configuration, Log4j 1.2.x silently ignored
> this, and the log4j2 bridge should be as tolerant.
> Note that {{PropertiesConfiguration#parseLogger}} is already tolerant of the
> appender being missing (it does a null check on the result of
> {{{}parseAppender{}}}), but {{parseAppender}} itself is not tolerant.
> An example config would be:
> {noformat}
> log4j.logger.mylogger=INFO, myappender
> # log4j.appender.myappender=org.apache.log4j.ConsoleAppender
> {noformat}
> The appender has been commented out, to illustrate the bug.
> Stack trace from log4j 2.17.1:
> {noformat}
> Caused by: java.lang.NullPointerException
> at
> org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:72)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:428)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:406)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLoggers(PropertiesConfiguration.java:351)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:304)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:93)
> at
> org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:60)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:293)
> 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:196)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:137)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:55)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:47)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:33)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:363)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:388)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3407) PropertiesConfiguration.parseAppender NPE when logger refers to non-existent appender
[
https://issues.apache.org/jira/browse/LOG4J2-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494575#comment-17494575
]
Gary D. Gregory commented on LOG4J2-3407:
-
Changing the default behavior is a bad idea IMO. Not only that, but it would be
inconsistent between formats. I never want to have to deal with this: a user
edits a configuration file to reproduce some issue, runs their app for a day or
two, then comes back and finds that some log is missing, by design. Not good.
Configurations can be large and complex, they should work for not, we should
not create half-baked configurations IMO.
> PropertiesConfiguration.parseAppender NPE when logger refers to non-existent
> appender
> -
>
> Key: LOG4J2-3407
> URL: https://issues.apache.org/jira/browse/LOG4J2-3407
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
>Reporter: Kenny MacLeod
>Priority: Minor
> Attachments: LOG4J2-3407.patch
>
>
> When parsing a {{log4j.proprties}} file that contains a logger that refers to
> a non-existent appender, you get a NPE.
> While this is clearly a malformed configuration, Log4j 1.2.x silently ignored
> this, and the log4j2 bridge should be as tolerant.
> Note that {{PropertiesConfiguration#parseLogger}} is already tolerant of the
> appender being missing (it does a null check on the result of
> {{{}parseAppender{}}}), but {{parseAppender}} itself is not tolerant.
> An example config would be:
> {noformat}
> log4j.logger.mylogger=INFO, myappender
> # log4j.appender.myappender=org.apache.log4j.ConsoleAppender
> {noformat}
> The appender has been commented out, to illustrate the bug.
> Stack trace from log4j 2.17.1:
> {noformat}
> Caused by: java.lang.NullPointerException
> at
> org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:72)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:428)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:406)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLoggers(PropertiesConfiguration.java:351)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:304)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:93)
> at
> org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:60)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:293)
> 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:196)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:137)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:55)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:47)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:33)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:363)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:388)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] kennymacleod commented on a change in pull request #761: LOG4J2-3407 Check for non-existent appender when parsing properties
kennymacleod commented on a change in pull request #761:
URL: https://github.com/apache/logging-log4j2/pull/761#discussion_r809919901
##
File path:
log4j-1.2-api/src/test/java/org/apache/log4j/config/PropertiesConfigurationTest.java
##
@@ -125,6 +125,15 @@ public void testConsoleAppenderLevelRangeFilter() throws
Exception {
}
}
+@Test
+public void testConfigureAppenderDoesNotExist() throws Exception {
+// Verify that we tolerate a logger which specifies an appender that
does not exist.
+try (LoggerContext loggerContext =
TestConfigurator.configure("target/test-classes/LOG4J2-3407.properties")) {
+final Configuration configuration =
loggerContext.getConfiguration();
+assertNotNull(configuration);
+}
Review comment:
This test fails with an NPE without the fix
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] kennymacleod commented on a change in pull request #761: LOG4J2-3407 Check for non-existent appender when parsing properties
kennymacleod commented on a change in pull request #761:
URL: https://github.com/apache/logging-log4j2/pull/761#discussion_r809919607
##
File path: log4j-1.2-api/src/test/resources/LOG4J2-3407.properties
##
@@ -0,0 +1,26 @@
+#
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements. See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership.
+# The ASF licenses this file to You under the Apache License, Version 2.0
+# (the "License"); you may not use this file except in compliance with
+# the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+
+log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
+log4j.appender.CONSOLE.filter.1=org.apache.log4j.config.NeutralFilterFixture
+log4j.appender.CONSOLE.filter.1.onMatch=neutral
+log4j.appender.CONSOLE.Target=System.out
+log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
+log4j.appender.CONSOLE.layout.ConversionPattern=%d{-MM-dd HH:mm:ss} %-5p
%c{1}:%L - %m%n
+
+log4j.logger.org.apache.log4j.xml=trace, A1
Review comment:
Here we have a logger referring to an appender (A1) that does not exist
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [logging-log4j2] kennymacleod commented on a change in pull request #761: LOG4J2-3407 Check for non-existent appender when parsing properties
kennymacleod commented on a change in pull request #761:
URL: https://github.com/apache/logging-log4j2/pull/761#discussion_r809919399
##
File path:
log4j-1.2-api/src/main/java/org/apache/log4j/config/PropertiesConfiguration.java
##
@@ -436,6 +436,10 @@ public Appender parseAppender(final Properties props,
final String appenderName)
final String layoutPrefix = prefix + ".layout";
final String filterPrefix = APPENDER_PREFIX + appenderName +
".filter.";
final String className = OptionConverter.findAndSubst(prefix, props);
+if (className == null) {
+LOGGER.debug("Appender \"" + appenderName + "\" does not exist.");
+return null;
+}
Review comment:
Without this null-check, there will be a NPE from the next line down.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Comment Edited] (LOG4J2-3407) PropertiesConfiguration.parseAppender NPE when logger refers to non-existent appender
[
https://issues.apache.org/jira/browse/LOG4J2-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494547#comment-17494547
]
Kenny MacLeod edited comment on LOG4J2-3407 at 2/18/22, 11:33 AM:
--
See attached patch file, and PR
https://github.com/apache/logging-log4j2/pull/761
was (Author: kennymacleod.atl):
See attached patch file, apply to the tip of the {{release-2.x}} branch.
Includes fix and unit test.
> PropertiesConfiguration.parseAppender NPE when logger refers to non-existent
> appender
> -
>
> Key: LOG4J2-3407
> URL: https://issues.apache.org/jira/browse/LOG4J2-3407
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
>Reporter: Kenny MacLeod
>Priority: Minor
> Attachments: LOG4J2-3407.patch
>
>
> When parsing a {{log4j.proprties}} file that contains a logger that refers to
> a non-existent appender, you get a NPE.
> While this is clearly a malformed configuration, Log4j 1.2.x silently ignored
> this, and the log4j2 bridge should be as tolerant.
> Note that {{PropertiesConfiguration#parseLogger}} is already tolerant of the
> appender being missing (it does a null check on the result of
> {{{}parseAppender{}}}), but {{parseAppender}} itself is not tolerant.
> An example config would be:
> {noformat}
> log4j.logger.mylogger=INFO, myappender
> # log4j.appender.myappender=org.apache.log4j.ConsoleAppender
> {noformat}
> The appender has been commented out, to illustrate the bug.
> Stack trace from log4j 2.17.1:
> {noformat}
> Caused by: java.lang.NullPointerException
> at
> org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:72)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:428)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:406)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLoggers(PropertiesConfiguration.java:351)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:304)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:93)
> at
> org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:60)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:293)
> 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:196)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:137)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:55)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:47)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:33)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:363)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:388)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] kennymacleod opened a new pull request #761: LOG4J2-3407 Check for non-existent appender when parsing properties
kennymacleod opened a new pull request #761: URL: https://github.com/apache/logging-log4j2/pull/761 This change will make `PropertiesConfiguration` tolerant of attempts to resolve a non-existent Appender. See JIRA ticket for details. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LOG4J2-3407) PropertiesConfiguration.parseAppender NPE when logger refers to non-existent appender
[
https://issues.apache.org/jira/browse/LOG4J2-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494547#comment-17494547
]
Kenny MacLeod commented on LOG4J2-3407:
---
See attached patch file, apply to the tip of the {{release-2.x}} branch.
Includes fix and unit test.
> PropertiesConfiguration.parseAppender NPE when logger refers to non-existent
> appender
> -
>
> Key: LOG4J2-3407
> URL: https://issues.apache.org/jira/browse/LOG4J2-3407
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
>Reporter: Kenny MacLeod
>Priority: Minor
> Attachments: LOG4J2-3407.patch
>
>
> When parsing a {{log4j.proprties}} file that contains a logger that refers to
> a non-existent appender, you get a NPE.
> While this is clearly a malformed configuration, Log4j 1.2.x silently ignored
> this, and the log4j2 bridge should be as tolerant.
> Note that {{PropertiesConfiguration#parseLogger}} is already tolerant of the
> appender being missing (it does a null check on the result of
> {{{}parseAppender{}}}), but {{parseAppender}} itself is not tolerant.
> An example config would be:
> {noformat}
> log4j.logger.mylogger=INFO, myappender
> # log4j.appender.myappender=org.apache.log4j.ConsoleAppender
> {noformat}
> The appender has been commented out, to illustrate the bug.
> Stack trace from log4j 2.17.1:
> {noformat}
> Caused by: java.lang.NullPointerException
> at
> org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:72)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:428)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:406)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLoggers(PropertiesConfiguration.java:351)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:304)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:93)
> at
> org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:60)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:293)
> 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:196)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:137)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:55)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:47)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:33)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:363)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:388)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3407) PropertiesConfiguration.parseAppender NPE when logger refers to non-existent appender
[
https://issues.apache.org/jira/browse/LOG4J2-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenny MacLeod updated LOG4J2-3407:
--
Attachment: LOG4J2-3407.patch
> PropertiesConfiguration.parseAppender NPE when logger refers to non-existent
> appender
> -
>
> Key: LOG4J2-3407
> URL: https://issues.apache.org/jira/browse/LOG4J2-3407
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
>Reporter: Kenny MacLeod
>Priority: Minor
> Attachments: LOG4J2-3407.patch
>
>
> When parsing a {{log4j.proprties}} file that contains a logger that refers to
> a non-existent appender, you get a NPE.
> While this is clearly a malformed configuration, Log4j 1.2.x silently ignored
> this, and the log4j2 bridge should be as tolerant.
> Note that {{PropertiesConfiguration#parseLogger}} is already tolerant of the
> appender being missing (it does a null check on the result of
> {{{}parseAppender{}}}), but {{parseAppender}} itself is not tolerant.
> An example config would be:
> {noformat}
> log4j.logger.mylogger=INFO, myappender
> # log4j.appender.myappender=org.apache.log4j.ConsoleAppender
> {noformat}
> The appender has been commented out, to illustrate the bug.
> Stack trace from log4j 2.17.1:
> {noformat}
> Caused by: java.lang.NullPointerException
> at
> org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:72)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:428)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:406)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLoggers(PropertiesConfiguration.java:351)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:304)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:93)
> at
> org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:60)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:293)
> 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:196)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:137)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:55)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:47)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:33)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:363)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:388)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3393) JSON template layout performance regression
[
https://issues.apache.org/jira/browse/LOG4J2-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494534#comment-17494534
]
ASF subversion and git services commented on LOG4J2-3393:
-
Commit 34bac580c90f4864c264b15998da5f4c0e139ad7 in logging-log4j2's branch
refs/heads/master from Volkan Yazici
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=34bac58 ]
LOG4J2-3393 Fix StringBuilder sizing code typo in
JsonWriter#trimStringBuilder().
> JSON template layout performance regression
> ---
>
> Key: LOG4J2-3393
> URL: https://issues.apache.org/jira/browse/LOG4J2-3393
> Project: Log4j 2
> Issue Type: Improvement
> Components: JsonTemplateLayout
>Affects Versions: 2.17.1
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> JTL performance is used to be on par with \{{log4j2-ecs-layout}}, though this
> is not the case anymore, there is a slight degradation. This story aims to
> investigate what is going on and fix it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-2368) Outputs wrong message when used within overridden Throwable method
[
https://issues.apache.org/jira/browse/LOG4J2-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494535#comment-17494535
]
ASF subversion and git services commented on LOG4J2-2368:
-
Commit ca4e572d25aa944073fbc65bc04dc8fa2d9574b1 in logging-log4j2's branch
refs/heads/master from Volkan Yazici
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=ca4e572 ]
LOG4J2-2368 Test JsonTemplateLayout's ThreadLocalRecycler against nested
logging.
> Outputs wrong message when used within overridden Throwable method
> --
>
> Key: LOG4J2-2368
> URL: https://issues.apache.org/jira/browse/LOG4J2-2368
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.8.1, 2.11.0
>Reporter: Taisuke Tashiro
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.11.1, 3.0.0
>
>
> When a message A is logged with Throwable object and if message B is logged
> within the Throwable object's method, message A is lost and message B is
> logged instead.
> Following is a code example to recreate the issue:
> {{Logger loggerA = LogManager.getLogger("A");}}
> {{Logger loggerB = LogManager.getLogger("B");}}
> {{Throwable throwable =}}
> {{ new Throwable() {}}
> {{ public String getMessage() {}}
> {{ loggerB.debug("MESSAGE B");}}
> {{ return "message";}}
> {{ }}}
> {{ };}}
> {{loggerA.debug("MESSEGE A", throwable);}}
> "MESSAGE A" should be logged to loggerA but "MESSAGE B" is logged instead.
> Cause of this problem is reuse of StringBuilder instance within the execution
> thread in org.apache.logging.log4j.core.layout.AbstractStringLayout class.
> While processing loggerA, getMessage() is called by
> org.apache.logging.log4j.core.impl.ThrowableProxy to obtain throwable object
> information and the content of StringBuilder is changed by loggerB.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3393) JSON template layout performance regression
[
https://issues.apache.org/jira/browse/LOG4J2-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494518#comment-17494518
]
ASF subversion and git services commented on LOG4J2-3393:
-
Commit 3913f59148eae79d9475f5a798cb8c837d10a35a in logging-log4j2's branch
refs/heads/release-2.x from Volkan Yazici
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=3913f59 ]
LOG4J2-3393 Fix StringBuilder sizing code typo in
JsonWriter#trimStringBuilder().
> JSON template layout performance regression
> ---
>
> Key: LOG4J2-3393
> URL: https://issues.apache.org/jira/browse/LOG4J2-3393
> Project: Log4j 2
> Issue Type: Improvement
> Components: JsonTemplateLayout
>Affects Versions: 2.17.1
>Reporter: Volkan Yazici
>Assignee: Volkan Yazici
>Priority: Major
>
> JTL performance is used to be on par with \{{log4j2-ecs-layout}}, though this
> is not the case anymore, there is a slight degradation. This story aims to
> investigate what is going on and fix it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-2368) Outputs wrong message when used within overridden Throwable method
[
https://issues.apache.org/jira/browse/LOG4J2-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494519#comment-17494519
]
ASF subversion and git services commented on LOG4J2-2368:
-
Commit 5410ff51ba9556e7e8d200f255be0ff2d44a6fba in logging-log4j2's branch
refs/heads/release-2.x from Volkan Yazici
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5410ff5 ]
LOG4J2-2368 Test JsonTemplateLayout's ThreadLocalRecycler against nested
logging.
> Outputs wrong message when used within overridden Throwable method
> --
>
> Key: LOG4J2-2368
> URL: https://issues.apache.org/jira/browse/LOG4J2-2368
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.8.1, 2.11.0
>Reporter: Taisuke Tashiro
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 2.11.1, 3.0.0
>
>
> When a message A is logged with Throwable object and if message B is logged
> within the Throwable object's method, message A is lost and message B is
> logged instead.
> Following is a code example to recreate the issue:
> {{Logger loggerA = LogManager.getLogger("A");}}
> {{Logger loggerB = LogManager.getLogger("B");}}
> {{Throwable throwable =}}
> {{ new Throwable() {}}
> {{ public String getMessage() {}}
> {{ loggerB.debug("MESSAGE B");}}
> {{ return "message";}}
> {{ }}}
> {{ };}}
> {{loggerA.debug("MESSEGE A", throwable);}}
> "MESSAGE A" should be logged to loggerA but "MESSAGE B" is logged instead.
> Cause of this problem is reuse of StringBuilder instance within the execution
> thread in org.apache.logging.log4j.core.layout.AbstractStringLayout class.
> While processing loggerA, getMessage() is called by
> org.apache.logging.log4j.core.impl.ThrowableProxy to obtain throwable object
> information and the content of StringBuilder is changed by loggerB.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3407) PropertiesConfiguration.parseAppender NPE when logger refers to non-existent appender
[
https://issues.apache.org/jira/browse/LOG4J2-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenny MacLeod updated LOG4J2-3407:
--
Priority: Minor (was: Major)
> PropertiesConfiguration.parseAppender NPE when logger refers to non-existent
> appender
> -
>
> Key: LOG4J2-3407
> URL: https://issues.apache.org/jira/browse/LOG4J2-3407
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
>Reporter: Kenny MacLeod
>Priority: Minor
>
> When parsing a {{log4j.proprties}} file that contains a logger that refers to
> a non-existent appender, you get a NPE.
> While this is clearly a malformed configuration, Log4j 1.2.x silently ignored
> this, and the log4j2 bridge should be as tolerant.
> Note that {{PropertiesConfiguration#parseLogger}} is already tolerant of the
> appender being missing (it does a null check on the result of
> {{{}parseAppender{}}}), but {{parseAppender}} itself is not tolerant.
> An example config would be:
> {noformat}
> log4j.logger.mylogger=INFO, myappender
> # log4j.appender.myappender=org.apache.log4j.ConsoleAppender
> {noformat}
> The appender has been commented out, to illustrate the bug.
> Stack trace from log4j 2.17.1:
> {noformat}
> Caused by: java.lang.NullPointerException
> at
> org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:72)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:428)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:406)
> at
> org.apache.log4j.config.PropertiesConfiguration.parseLoggers(PropertiesConfiguration.java:351)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:304)
> at
> org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:93)
> at
> org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:60)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:293)
> 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:196)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:137)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:55)
> at
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:47)
> at
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:33)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:363)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:388)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3407) PropertiesConfiguration.parseAppender NPE when logger refers to non-existent appender
[
https://issues.apache.org/jira/browse/LOG4J2-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenny MacLeod updated LOG4J2-3407:
--
Description:
When parsing a {{log4j.proprties}} file that contains a logger that refers to a
non-existent appender, you get a NPE.
While this is clearly a malformed configuration, Log4j 1.2.x silently ignored
this, and the log4j2 bridge should be as tolerant.
Note that {{PropertiesConfiguration#parseLogger}} is already tolerant of the
appender being missing (it does a null check on the result of
{{{}parseAppender{}}}), but {{parseAppender}} itself is not tolerant.
An example config would be:
{noformat}
log4j.logger.mylogger=INFO, myappender
# log4j.appender.myappender=org.apache.log4j.ConsoleAppender
{noformat}
The appender has been commented out, to illustrate the bug.
Stack trace from log4j 2.17.1:
{noformat}
Caused by: java.lang.NullPointerException
at
org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:72)
at
org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:428)
at
org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:406)
at
org.apache.log4j.config.PropertiesConfiguration.parseLoggers(PropertiesConfiguration.java:351)
at
org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:304)
at
org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:93)
at
org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:60)
at
org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:293)
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:196)
at
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:137)
at
org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:55)
at
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:47)
at
org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:33)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:363)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:388)
{noformat}
was:
When parsing a `log4j.proprties` file that contains a logger that refers to a
non-existent appender, you get a NPE.
While this is clearly a malformed configuration, Log4j 1.2.x silently ignored
this, and the log4j2 bridge should be as tolerant.
Note that {{PropertiesConfiguration#parseLogger}} is already tolerant of the
appender being missing (it does a null check on the result of
{{parseAppender}}), but {{parseAppender}} itself is not tolerant.
An example config would be:
{noformat}
log4j.logger.mylogger=INFO, myappender
# log4j.appender.myappender=org.apache.log4j.ConsoleAppender
{noformat}
The appender has been commented out, to illustrate the bug.
Stack trace from log4j 2.17.1:
{noformat}
Caused by: java.lang.NullPointerException
at
org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:72)
at
org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:428)
at
org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:406)
at
org.apache.log4j.config.PropertiesConfiguration.parseLoggers(PropertiesConfiguration.java:351)
at
org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:304)
at
org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:93)
at
org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:60)
at
org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:293)
at
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:626)
at
org.apache.logging.log4j.core.LoggerC
[jira] [Created] (LOG4J2-3407) PropertiesConfiguration.parseAppender NPE when logger refers to non-existent appender
Kenny MacLeod created LOG4J2-3407:
-
Summary: PropertiesConfiguration.parseAppender NPE when logger
refers to non-existent appender
Key: LOG4J2-3407
URL: https://issues.apache.org/jira/browse/LOG4J2-3407
Project: Log4j 2
Issue Type: Bug
Components: Log4j 1.2 bridge
Affects Versions: 2.17.1
Reporter: Kenny MacLeod
When parsing a `log4j.proprties` file that contains a logger that refers to a
non-existent appender, you get a NPE.
While this is clearly a malformed configuration, Log4j 1.2.x silently ignored
this, and the log4j2 bridge should be as tolerant.
Note that {{PropertiesConfiguration#parseLogger}} is already tolerant of the
appender being missing (it does a null check on the result of
{{parseAppender}}), but {{parseAppender}} itself is not tolerant.
An example config would be:
{noformat}
log4j.logger.mylogger=INFO, myappender
# log4j.appender.myappender=org.apache.log4j.ConsoleAppender
{noformat}
The appender has been commented out, to illustrate the bug.
Stack trace from log4j 2.17.1:
{noformat}
Caused by: java.lang.NullPointerException
at
org.apache.log4j.builders.BuilderManager.parseAppender(BuilderManager.java:72)
at
org.apache.log4j.config.PropertiesConfiguration.parseAppender(PropertiesConfiguration.java:428)
at
org.apache.log4j.config.PropertiesConfiguration.parseLogger(PropertiesConfiguration.java:406)
at
org.apache.log4j.config.PropertiesConfiguration.parseLoggers(PropertiesConfiguration.java:351)
at
org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:304)
at
org.apache.log4j.config.PropertiesConfiguration.doConfigure(PropertiesConfiguration.java:93)
at
org.apache.log4j.config.Log4j1Configuration.initialize(Log4j1Configuration.java:60)
at
org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:293)
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:196)
at
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:137)
at
org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:55)
at
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:47)
at
org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:33)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:363)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:388)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
