[jira] [Commented] (LOGCXX-576) Logging DOAP file has an error

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOGCXX-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816430#comment-17816430
 ] 

Gary D. Gregory commented on LOGCXX-576:


Moving this issue to the LOGCXX Jira project.

> Logging DOAP file has an error
> --
>
> Key: LOGCXX-576
> URL: https://issues.apache.org/jira/browse/LOGCXX-576
> Project: Log4cxx
>  Issue Type: Bug
>Reporter: Claude Warren
>Priority: Minor
>
> The DOAP file [1] as listed in [2] has the error:
> [line: 26, col: 4 ] \{E201} The attributes on this property element, are not 
> permitted with any content; expecting end element tag.
> [1] 
> https://gitbox.apache.org/repos/asf?p=logging-log4cxx.git;a=blob_plain;f=doap_log4cxx.rdf;hb=HEAD
> [2] 
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Moved] (LOGCXX-576) Logging DOAP file has an error

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOGCXX-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory moved LOGGING-184 to LOGCXX-576:


  Key: LOGCXX-576  (was: LOGGING-184)
Affects Version/s: (was: 1.2)
  Project: Log4cxx  (was: Commons Logging)

> Logging DOAP file has an error
> --
>
> Key: LOGCXX-576
> URL: https://issues.apache.org/jira/browse/LOGCXX-576
> Project: Log4cxx
>  Issue Type: Bug
>Reporter: Claude Warren
>Priority: Minor
>
> The DOAP file [1] as listed in [2] has the error:
> [line: 26, col: 4 ] \{E201} The attributes on this property element, are not 
> permitted with any content; expecting end element tag.
> [1] 
> https://gitbox.apache.org/repos/asf?p=logging-log4cxx.git;a=blob_plain;f=doap_log4cxx.rdf;hb=HEAD
> [2] 
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (LOG4J2-3666) traceEntry() and traceExit() - Similar methods not there with INFO/DEBUG level?

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17750429#comment-17750429
 ] 

Gary D. Gregory commented on LOG4J2-3666:
-

Because this is designed to "trace" coming in and out of method calls and 
nothing else. I only makes sense to allow this at the lowest priority level IMO.

> traceEntry() and traceExit() - Similar methods not there with INFO/DEBUG 
> level?
> ---
>
> Key: LOG4J2-3666
> URL: https://issues.apache.org/jira/browse/LOG4J2-3666
> Project: Log4j 2
>  Issue Type: Question
>Reporter: Sreenivas K
>Priority: Minor
>
> Came to know that *traceEntry()* and *traceExit()*  will log method 
> entry/exits only when TRACE enabled.
> Why there are no methods with INFO/DEBUG level to log entry/exit?
> or 
> Why there is no option given to callers under which Log Level those need to 
> be printed?
> Because i want to use those methods with DEBUG/INFO mode. I cannot enable 
> *TRACE* for my package.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (LOG4J2-3662) Don't register JMX beans by default

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723141#comment-17723141
 ] 

Gary D. Gregory commented on LOG4J2-3662:
-

Sounds reasonable to me.

> Don't register JMX beans by default
> ---
>
> Key: LOG4J2-3662
> URL: https://issues.apache.org/jira/browse/LOG4J2-3662
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: JMX
>Reporter: Arnout Engelen
>Priority: Minor
>
> Since modern java services tend not to use JMX as heavily as they did in 
> previous decades, we should probably not register JMX beans by default.
> Note that we previously disabled JMX in LOG4J2-1119 and implemented it in 
> 608406122883eb5f4b84c7b2b7a51c04aef07842, but back then the motivation turned 
> out to be invalid.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (LOG4J2-2092) Extended Throwable produces unnecessary long stack traces compared to standard stack trace

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610089#comment-17610089
 ] 

Gary D. Gregory commented on LOG4J2-2092:
-

That's the point of "extended" ;) 

Perhaps we should have another strategy called "medium" or somesuch name that 
conveys that you don't want to the shortest nor the longest but something in 
between. But we should definitely keep the current extended option so I can see 
everything when debugging. As usual PRs are welcomed on GitHub :)

> Extended Throwable produces unnecessary long stack traces compared to 
> standard stack trace
> --
>
> Key: LOG4J2-2092
> URL: https://issues.apache.org/jira/browse/LOG4J2-2092
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Pattern Converters
>Affects Versions: 2.9.1
>Reporter: AppleFreak
>Priority: Minor
> Attachments: Example.java
>
>
> Let's consider the following exception stack trace, printed using the 
> standard {{%throwable}} converter (43 lines):
> {noformat}
> java.lang.RuntimeException: Failed to parse JavaBean
>   at com.example.test.Main$JavaBean.parse(Main.java:16)
>   at com.example.test.Main.main(Main.java:23)
> Caused by: Cannot create property=test for 
> JavaBean=com.example.test.Main$JavaBean@2957fcb0
>  in 'string', line 1, column 1:
> test: !test Hello World!
> ^
> Can't construct a java object for !test; exception=Invalid tag: !test
>  in 'string', line 1, column 7:
> test: !test Hello World!
>   ^
>  in 'string', line 1, column 7:
> test: !test Hello World!
>   ^
>   at 
> org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.constructJavaBean2ndStep(Constructor.java:268)
>   at 
> org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.construct(Constructor.java:149)
>   at 
> org.yaml.snakeyaml.constructor.Constructor$ConstructYamlObject.construct(Constructor.java:308)
>   at 
> org.yaml.snakeyaml.constructor.BaseConstructor.constructObjectNoCheck(BaseConstructor.java:207)
>   at 
> org.yaml.snakeyaml.constructor.BaseConstructor.constructObject(BaseConstructor.java:196)
>   at 
> org.yaml.snakeyaml.constructor.BaseConstructor.constructDocument(BaseConstructor.java:161)
>   at 
> org.yaml.snakeyaml.constructor.BaseConstructor.getSingleData(BaseConstructor.java:147)
>   at org.yaml.snakeyaml.Yaml.loadFromReader(Yaml.java:524)
>   at org.yaml.snakeyaml.Yaml.loadAs(Yaml.java:501)
>   at com.example.test.Main$JavaBean.parse(Main.java:14)
>   ... 1 more
> Caused by: Can't construct a java object for !test; exception=Invalid tag: 
> !test
>  in 'string', line 1, column 7:
> test: !test Hello World!
>   ^
>   at 
> org.yaml.snakeyaml.constructor.Constructor$ConstructYamlObject.construct(Constructor.java:313)
>   at 
> org.yaml.snakeyaml.constructor.BaseConstructor.constructObjectNoCheck(BaseConstructor.java:207)
>   at 
> org.yaml.snakeyaml.constructor.BaseConstructor.constructObject(BaseConstructor.java:196)
>   at 
> org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.constructJavaBean2ndStep(Constructor.java:247)
>   ... 10 more
> Caused by: org.yaml.snakeyaml.error.YAMLException: Invalid tag: !test
>   at org.yaml.snakeyaml.nodes.Tag.getClassName(Tag.java:112)
>   at 
> org.yaml.snakeyaml.constructor.Constructor.getClassForNode(Constructor.java:637)
>   at 
> org.yaml.snakeyaml.constructor.Constructor$ConstructYamlObject.getConstructor(Constructor.java:298)
>   at 
> org.yaml.snakeyaml.constructor.Constructor$ConstructYamlObject.construct(Constructor.java:308)
>   ... 13 more
> {noformat}
> The same exception, printed using the extended throwable ({{%xThrowable}}) 
> converter, takes 64 lines:
> {noformat}
> java.lang.RuntimeException: Failed to parse JavaBean
>   at com.example.test.Main$JavaBean.parse(Main.java:16) ~[test/:?]
>   at com.example.test.Main.main(Main.java:23) [test/:?]
> Caused by: org.yaml.snakeyaml.constructor.ConstructorException: Cannot create 
> property=test for JavaBean=com.example.test.Main$JavaBean@2957fcb0
>  in 'string', line 1, column 1:
> test: !test Hello World!
> ^
> Can't construct a java object for !test; exception=Invalid tag: !test
>  in 'string', line 1, column 7:
> test: !test Hello World!
>   ^
>  in 'string', line 1, column 7:
> test: !test Hello World!
>   ^
>   at 
> org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.constructJavaBean2ndStep(Constructor.java:268)
>  ~[snakeyaml-1.19.jar:?]
>   at 
> org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.construct(Constructor.java:149)
>  ~[snakeyaml-1.19.jar:?]
>   at 
> 

[jira] [Created] (LOG4J2-3599) Random failure in LoggerTest.flowTracingString_ObjectArray2

[Gary D. Gregory (Jira)]

Gary D. Gregory created LOG4J2-3599:
---

 Summary: Random failure in 
LoggerTest.flowTracingString_ObjectArray2
 Key: LOG4J2-3599
 URL: https://issues.apache.org/jira/browse/LOG4J2-3599
 Project: Log4j 2
  Issue Type: Bug
  Components: API
Affects Versions: 2.19.0
Reporter: Gary D. Gregory


Building from the src zip on Windows 10 with 'mvn -V clean install', I get this 
failure:

{{Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) Maven home: 
C:\Java\apache-maven-3.8.6 Java version: 1.8.0_342, vendor: Temurin, runtime: 
C:\Program Files\Eclipse Adoptium\jdk-8.0.342.7-hotspot\jre Default locale: 
en_US, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: 
"amd64", family: "windows" ... [INFO] Running 
org.apache.logging.log4j.NoopThreadContextTest [ERROR] Tests run: 6, Failures: 
1, Errors: 0, Skipped: 0, Time elapsed: 2.984 s <<< FAILURE! - in 
org.apache.logging.log4j.message.StructuredDataMessageTest [ERROR] 
org.apache.logging.log4j.LoggerTest.flowTracingString_ObjectArray2 Time 
elapsed: 0.011 s <<< FAILURE! org.opentest4j.AssertionFailedError: expected: 
<2> but was: <1> at 
org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
 at 
org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
 at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197) at 
org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150) at 
org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145) at 
org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:527) at 
org.apache.logging.log4j.LoggerTest.flowTracingString_ObjectArray2(LoggerTest.java:125)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498) at 
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
 at 
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
 at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
 at 
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
 at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
 at 
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
 at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
 at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
 at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
 at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
 at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
 at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
 at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
 at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
 at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
 at 
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
 at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
 at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
 at 
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
 at 
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
 at 
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
 at 
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
 at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137) 
at 
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
 at 
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
 at 

[jira] [Resolved] (LOG4J2-3594) ERROR Could not create plugin of type class org.apache.logging.log4j.core.appender.ConsoleAppender for element Console:java.nio.charset.IllegalCharsetNameException: "fi

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory resolved LOG4J2-3594.
-
Fix Version/s: 2.19.0
   Resolution: Duplicate

> ERROR Could not create plugin of type class 
> org.apache.logging.log4j.core.appender.ConsoleAppender for element 
> Console:java.nio.charset.IllegalCharsetNameException: 
> "file:/C:\test\log4j2.xml"
> ---
>
> Key: LOG4J2-3594
> URL: https://issues.apache.org/jira/browse/LOG4J2-3594
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.18.0
> Environment: windows 
>Reporter: Bhavani Sheri
>Priority: Major
> Fix For: 2.19.0
>
>
> I have a test.bat file where I set -Dlog4j2.configurationFile to point to a 
> valid log4j2.xml.
> This log4j2.xml has a console appender which is resulting in below exception.
> java.nio.charset.IllegalCharsetNameException:file:/C:\test\log4j2.xml
> at java.base/java.nio.charset.Charset.checkName(Charset.java:308)
> at java.base/java.nio.charset.Charset.lookup2(Charset.java:482)
> at java.base/java.nio.charset.Charset.lookup(Charset.java:462)
> at java.base/java.nio.charset.Charset.isSupported(Charset.java:503)
> at 
> org.apache.logging.log4j.util.PropertiesUtil.getCharsetProperty(PropertiesUtil.java:215)
> Please note that same script file works fine in linux machine and I see this 
> issue just in windows. If I replace log4j 2.18.0 with log4j 2.17.1 then I 
> dont see any errors.
> After some basic debugging I got to know that normalized map under 
> PropertiesUtil is not getting populated properly. All the properties in the 
> map have log4j2.xml file path as value and thus the encoding property value 
> in that map is set to log4j2.xml file path which is resulting in above 
> exception.
> Below is my configuration for log4j2.xml.
> 
> 
>     
>         
>             
>         
>     
>     
>                      level="WARN" additivity="false">
>                 
>         
>         
>             
>         
>     
> 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (LOG4J2-2148) CronTriggeringPolicy renaming behavior

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17577975#comment-17577975
 ] 

Gary D. Gregory commented on LOG4J2-2148:
-

Hi [~wlfbck] 

Are you using 2.18.0?

 

> CronTriggeringPolicy renaming behavior
> --
>
> Key: LOG4J2-2148
> URL: https://issues.apache.org/jira/browse/LOG4J2-2148
> Project: Log4j 2
>  Issue Type: Question
>  Components: Appenders
>Affects Versions: 2.8
>Reporter: Petr Valenta
>Priority: Major
>
> Hi.
> I tried CronTriggeringPolicy(version 2.8) for save daily log files at 
> midnight.
> My requirementare as follows:
> 1) Log file should be of max size 30MB, beyond which new log file should be 
> generated.
> 2) Every midnight log file should be rolled over (to "bck" subfolder).
> 3) The following filePattern for the rollovered log files: 
> "l4j2_cpm-javascript-%d{MMdd-HHmmssSSS}.log.gz2"
> I have the followig Log4j2 configuration to achieve these requirements:
> {noformat}
> 
> 
>   
>   logs/l4j2_
>   logs/bck/l4j2_
>   log.bz2
>   MMdd-HHmmssSSS
>   %d %-5p [%t] - 
> %m%n  
>   
>
>   
>fileName="${filePath}cpm-javascript.log"
>   
> filePattern="${fileBackupPath}cpm-javascript-%d{${fileDatePattern}}.${fileSuffix}"
>   createOnDemand="true">
>   
>   
>   
>   
>   
>   
>   
>   
>glob="l4j2_cpm-javascript*.${fileSuffix}">
>   
>exceeds="200 MB" />
>exceeds="25" />
>   
>   
>   
>   
> 
>   
>  
>additivity="false">
>   
>  
>   
> 
> {noformat}
> But I have problem with file name in case that "_CronTriggeringPolicy_" is 
> used. For example today is 2017/11/11:
> - 2017/11/11 23:52:15 Rollover for the file using "SizeBasedTriggeringPolicy" 
> -> creates new file: l4j2_cpm-javascript-2017-235215000.log.gz2.
> - 2017/11/12 00:00:00 Rollover for the file using "CronTriggeringPolicy" -> 
> creates new file: l4j2_cpm-javascript-2017-0.log.gz2.
> And this is the problem, because you have the file named "2017-0" 
> and it contains log records from the interval from 2017-235215000 to 
> 2017-23595. It looks like the first non-fixed value from "shedule" 
> settings (for CronTriggeringPolicy) is decreased by 1. You can observe the 
> same behaviour for rollover per minute -> schedule="0 0/1 * * * ?". In this 
> case the log file generated for example at 2017/11/11 10:10:00 will be named 
> ...2017-100900..., etc.
> I have tried various combinations of filePattern values, policies and 
> schedule parameter (for CronTriggeringPolicy) but have not been able to 
> achieve correct file name. Please let me know where I am going wrong. Thanks 
> for your help, I'm very appreciated it.
> Regards
> Petr



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (LOG4J2-3568) ResolverUtil fails to extractPath for custom plugins in jar, if there are blanks in the path

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575800#comment-17575800
 ] 

Gary D. Gregory commented on LOG4J2-3568:
-

A special case for space is not good enough because it ignores other characters 
that need to be URL encoded :-(

> ResolverUtil fails to extractPath for custom plugins in jar, if there are 
> blanks in the path
> 
>
> Key: LOG4J2-3568
> URL: https://issues.apache.org/jira/browse/LOG4J2-3568
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 2.17.2
> Environment: Windows 10
> Windows Server 2019
>Reporter: Sven Seelig
>Priority: Major
>
> We are using plugins in our config, e.g.:
> {noformat}
> "configuration": {
>   "name": "MyAppLog4JConfig",
>   "packages": "de.mycompany.myapp.adapter.log4j.plugin",
>   "properties": {
> ...
>   "appenders": {
> ...
> "MyAppConsole": {
>   "name": "MyApp-Console-Appender",
>   "PatternLayout": {
> "pattern": "${sysPatternlayout}",
> "charset": "UTF-8"
>   }
>  {noformat}
> Everything works fine until the installation path of our application contains 
> one or more blanks, e.g. "C:\Program Files\MyApp_13.0.1". 
>  
> The plugin classes and the log4j2.json are delivered within jar files 
> (different jar files, same folder). The config-file itself is found and read. 
> We are accessing the context in a standard way:
>  
> {code:java}
> LoggerContext log4j2LoggerContext = 
> (org.apache.logging.log4j.core.LoggerContext) 
> org.apache.logging.log4j.LogManager.getContext(true);
> {code}
>  
> While trying to extract the path to our custom plugins, the PluginManager 
> lands here: 
> org.apache.logging.log4j.core.config.plugins.util.ResolverUtil#extractPath 
> {code:java}
> String extractPath(final URL url) throws UnsupportedEncodingException, 
> URISyntaxException {
> String urlPath = url.getPath(); // same as getFile but without the Query 
> portion
> [...]
> // For jar: URLs, the path part starts with "file:"
> if (urlPath.startsWith("file:")) {
> urlPath = urlPath.substring(5);
> }
> // If it was in a JAR, grab the path to the jar
> final int bangIndex = urlPath.indexOf('!');
> if (bangIndex > 0) {
> urlPath = urlPath.substring(0, bangIndex);
> }  
>  [...]     
> final String cleanPath = new URI(urlPath).getPath(); {code}
> Problem is, if the urlPath contains blank(s), the new URI(...) call will 
> throw an URISyntaxException and the plugins are not loaded.
> Simple solution would be an additional check and replacement of the blanks 
> with "%20".
> {code:java}
> if(urlPath.contains(" ")){
> urlPath = urlPath.replace(" ", "%20");
> }
> final String cleanPath = new URI(urlPath).getPath(); {code}
> or
> {code:java}
> final String cleanPath = new URI(urlPath.replace(" ", "%20")).getPath(); 
> {code}
> We built the current release-2,x from the repo 
> ([https://gitbox.apache.org/repos/asf/logging-log4j2.git]), had the same 
> issue as before (2.17.2) but with this check added it works.
> As we can't run the maven build with tests (there seems to be a proxy issue 
> for the MongoDB Tests), we decided not to open a pull-request. Please let us 
> know, if you prefer a pull-request or if you need further information.
> (i) We are using the log4j-bridge at the moment, maybe this issue only shows 
> up when using this besides log4j2 core and api (i) 
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (LOG4J2-3533) Desired Log4j 2.17.x files not available

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552205#comment-17552205
 ] 

Gary D. Gregory commented on LOG4J2-3533:
-

Log4j 2 files are here: [https://logging.apache.org/log4j/2.x/download.html]

You'll have to ask Ivy about theirs.

> Desired Log4j 2.17.x files not available
> 
>
> Key: LOG4J2-3533
> URL: https://issues.apache.org/jira/browse/LOG4J2-3533
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.17.2
>Reporter: Harshit
>Priority: Blocker
>
> We are actually migrating from the log4j 1.x version to the 2.17.x version, 
> for which we are looking for the below set of files with 2.17.x version :
> _ivy-log4j-1.2.17.xml_
> _log4j-1.2.17.jar_
> _log4j-1.2.17.src.jar_
> _apache-log4j-extras-1.2.17.jar_
> _apache-log4j-extras-1.2.17.src.jar_
> _ivy-apache-log4j-extras-1.2.17.xml_
> _log4j-1.2.17-foss.txt_
> _log4j-extras-1.2.17-foss.txt_
>  
> Can anyone please point us to where we can find them or if they have been 
> updated with their names.
>  
> Thanks.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (LOG4J2-3500) Deadlock in Log4j

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532762#comment-17532762
 ] 

Gary D. Gregory commented on LOG4J2-3500:
-

Hello [~G1G4] 

2.12.1 is a pretty old version. Would you be able to test on the current 
version 2.17.2?

> Deadlock in Log4j
> -
>
> Key: LOG4J2-3500
> URL: https://issues.apache.org/jira/browse/LOG4J2-3500
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.12.1
>Reporter: Gianfranco Amatore
>Priority: Major
> Attachments: tdump.2022-03-31 13_10_15.out
>
>
> I encountered a problem on our ESB (Red Hat Fuse 7.6), it seems that the 
> log4j dead locked while writing the log file. The whole jvm remains blocked 
> for about 10 mins, then it starts again executing. Attached the thread-dump 
> that shows the deadlock.
>  
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (LOG4J2-3498) Timestamp lacks micro and nano second precision on linux

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532219#comment-17532219
 ] 

Gary D. Gregory commented on LOG4J2-3498:
-

It looks like your project uses Java 11 so the JRE should pickup nanos for 
Instant instances. This could be some weird combination of OS/JVM.

> Timestamp lacks micro and nano second precision on linux
> 
>
> Key: LOG4J2-3498
> URL: https://issues.apache.org/jira/browse/LOG4J2-3498
> Project: Log4j 2
>  Issue Type: Bug
>Reporter: Benjamin Tanguay
>Priority: Minor
>
> Generating a timestamp with micro and nano seconds defined fails when the 
> operating system is linux. Instead of having the required precision, the log 
> pads the micro and nano seconds with zeros. Testing it between some 
> developpers, the code works properly on Windows and Mac and only fails on 
> Linux machines.
> Our team has tested this internally and it seems that the problem is linked 
> to a bad interaction between Linux and the library. We've tested with 
> different JDK versions and vendors and the problem remained the same. The 
> problem also works in the same way whether we use a JsonLayout or a 
> PatternLayout to output the timestamp in the log.
>  
> {*}Expected{*}:
> A timestamp with the form: "timestamp":"2022-05-04T17:53:43.914{*}123456{*}Z"
> {*}Actual{*}:
> A timestamp with the form: "timestamp":"2022-05-04T17:53:43.914{*}00{*}Z"
>  
> I created a small project to reproduce the issue. Notice the script demo.sh 
> that allows you to build an alpine image, execute the code in docker and 
> output the log in the console.
> [https://github.com/BenjaminTanguay/log4j-low-timestamp-precision-linux-demo]
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (LOG4J2-3498) Timestamp lacks micro and nano second precision on linux

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532217#comment-17532217
 ] 

Gary D. Gregory commented on LOG4J2-3498:
-

You should update your test to Log4j 2.17.2 to make it closer to our git 
release-2.x branch (might not matter for actual results but its simpler IMO)

> Timestamp lacks micro and nano second precision on linux
> 
>
> Key: LOG4J2-3498
> URL: https://issues.apache.org/jira/browse/LOG4J2-3498
> Project: Log4j 2
>  Issue Type: Bug
>Reporter: Benjamin Tanguay
>Priority: Minor
>
> Generating a timestamp with micro and nano seconds defined fails when the 
> operating system is linux. Instead of having the required precision, the log 
> pads the micro and nano seconds with zeros. Testing it between some 
> developpers, the code works properly on Windows and Mac and only fails on 
> Linux machines.
> Our team has tested this internally and it seems that the problem is linked 
> to a bad interaction between Linux and the library. We've tested with 
> different JDK versions and vendors and the problem remained the same. The 
> problem also works in the same way whether we use a JsonLayout or a 
> PatternLayout to output the timestamp in the log.
>  
> {*}Expected{*}:
> A timestamp with the form: "timestamp":"2022-05-04T17:53:43.914{*}123456{*}Z"
> {*}Actual{*}:
> A timestamp with the form: "timestamp":"2022-05-04T17:53:43.914{*}00{*}Z"
>  
> I created a small project to reproduce the issue. Notice the script demo.sh 
> that allows you to build an alpine image, execute the code in docker and 
> output the log in the console.
> [https://github.com/BenjaminTanguay/log4j-low-timestamp-precision-linux-demo]
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (LOG4J2-3476) Support JUL ApiLogger::setLevel

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522249#comment-17522249
 ] 

Gary D. Gregory commented on LOG4J2-3476:
-

Ah, right. So the next question is why not add a level setting method to 
log4j-api. This is one feature that all the apps I have worked on and up using.

> Support JUL ApiLogger::setLevel
> ---
>
> Key: LOG4J2-3476
> URL: https://issues.apache.org/jira/browse/LOG4J2-3476
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: JUL adapter
>Affects Versions: 2.17.2
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 2.17.3
>
>
> The current implementation of ApiLogger::setLevel is to throw an 
> UnsupportedOperation Exception.
> It turns out that Gradle's internal logging tries to call this method under 
> some configurations, and it cannot deal gracefully with that Exception, so 
> the build fails.
> -[~mattsicker] I was wondering if there is any reason why the implementation 
> could not be like this:-
> {code}
> @Override
> public void setLevel(final Level newLevel) throws SecurityException {
> doSetLevel(newLevel);
> Configurator.setLevel(logger, LevelTranslator.toLevel(newLevel));
> }
> {code}
> -I will try this in a test project.-
> (5 minutes later...) Looking at LOG4J2-1110, I understand that this can be 
> done in CoreLogger but not in ApiLogger.
> Still, would it be possible to silently ignore this call to setLevel, rather 
> than throwing an UnsupportedOperationException?



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3476) Support JUL ApiLogger::setLevel

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522238#comment-17522238
 ] 

Gary D. Gregory commented on LOG4J2-3476:
-

Since log4j-jul already has an optional dependency on log4j-core, why not 
actually implement the API using our Configurator class?

> Support JUL ApiLogger::setLevel
> ---
>
> Key: LOG4J2-3476
> URL: https://issues.apache.org/jira/browse/LOG4J2-3476
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: JUL adapter
>Affects Versions: 2.17.2
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Major
> Fix For: 2.17.3
>
>
> The current implementation of ApiLogger::setLevel is to throw an 
> UnsupportedOperation Exception.
> It turns out that Gradle's internal logging tries to call this method under 
> some configurations, and it cannot deal gracefully with that Exception, so 
> the build fails.
> -[~mattsicker] I was wondering if there is any reason why the implementation 
> could not be like this:-
> {code}
> @Override
> public void setLevel(final Level newLevel) throws SecurityException {
> doSetLevel(newLevel);
> Configurator.setLevel(logger, LevelTranslator.toLevel(newLevel));
> }
> {code}
> -I will try this in a test project.-
> (5 minutes later...) Looking at LOG4J2-1110, I understand that this can be 
> done in CoreLogger but not in ApiLogger.
> Still, would it be possible to silently ignore this call to setLevel, rather 
> than throwing an UnsupportedOperationException?



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3467) Update from Log4J 2.17.1 to 2.17.2 breaks application

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17519567#comment-17519567
 ] 

Gary D. Gregory commented on LOG4J2-3467:
-

[~pkarwasz] 

TL;DR: Please, no.

I would say that the goal for log4j-1.2-api had to change since log4shell was 
released: We need to provide as close to possible a drop in replacement with 
this support improving with each release. I really am not a fan of yet more 
system properties, especially for the 1.2 compatibility layer. It's unfortunate 
that the module is called log4j-1.2-api instead of log4j-1.2-bridge or 
somesuch. The nature of 1.2, the use cases, the apps, built over years and 
years, which mixes API and implementation, all make it impossible IMO to 
practically offer reasonable compatibility without filling in implementations 
for the configuration APIs which all the apps I work on used for example.

> Update from Log4J 2.17.1 to 2.17.2 breaks application
> -
>
> Key: LOG4J2-3467
> URL: https://issues.apache.org/jira/browse/LOG4J2-3467
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.17.2
>Reporter: Alexander Veit
>Priority: Major
>
> We have an application that uses a third-party library which seems to 
> reconfigure Log4J according to its needs. This worked for quite some years 
> with various Log4J versions.
> After upgrading from Log4J 2.17.1 to 2.17.2 a call to the library immediately 
> stops logging completely in the sense that no further logging is performed 
> until restarting the JVM.
> We've tried to identify the change that leads to the problem. Our best guess 
> is PropertyConfigurator, line 164 in
> https://github.com/apache/logging-log4j2/commit/73a2cd1cd0e94c7f4f36e4ac9dc72380d30750ef#diff-607596a6cadd10faf2dbeefc4e03092264b8e0dbe23fb89ffa6505d644602c9dR164
> Note that according to semantic versioning such breaking changes should not 
> occur when only the patch version is incremented. ;-)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (LOG4J2-3471) log4j-1.2-api 2.17.2 throws NullPointerException while removing appender with name as null

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory resolved LOG4J2-3471.
-
Fix Version/s: 2.17.3
   Resolution: Fixed

[~rajeshn] 

Thank you for your report.

Please try a 2.17.3-SNAPSHOT from 
[https://repository.apache.org/content/repositories/snapshots/]

TY!

> log4j-1.2-api 2.17.2 throws NullPointerException while removing appender with 
> name as null
> --
>
> Key: LOG4J2-3471
> URL: https://issues.apache.org/jira/browse/LOG4J2-3471
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.17.2
>Reporter: Rajesh
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.3
>
>
> The log4j 1.2 bridge for 2.17.2 throws null pointer exception while removing 
> Null appender
> viz. org.apache.log4j.varia.NullAppender 
> The class AppenderAttachableImpl adds the null appender to the 
> concurrenthashmap as "null" and on removal there is no check for null and 
> removes the nullappender with name null hence the NullPointerexception.
> Caused by: java.lang.NullPointerException
> at java.util.concurrent.ConcurrentHashMap.remove(Unknown Source)
> at 
> org.apache.log4j.helpers.AppenderAttachableImpl.removeAppender(AppenderAttachableImpl.java:93)
> at org.apache.log4j.Category.removeAppender(Category.java:618)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (LOG4J2-3471) log4j-1.2-api-2.17.2 throws NullPointerException while removing appender with name as null

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LOG4J2-3471:

Summary: log4j-1.2-api-2.17.2 throws NullPointerException while removing 
appender with name as null  (was: log4j-1.2-api-2.17.2 throws exception while 
removing appender with name as null)

> log4j-1.2-api-2.17.2 throws NullPointerException while removing appender with 
> name as null
> --
>
> Key: LOG4J2-3471
> URL: https://issues.apache.org/jira/browse/LOG4J2-3471
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.17.2
>Reporter: Rajesh
>Assignee: Gary D. Gregory
>Priority: Major
>
> The log4j 1.2 bridge for 2.17.2 throws null pointer exception while removing 
> Null appender
> viz. org.apache.log4j.varia.NullAppender 
> The class AppenderAttachableImpl adds the null appender to the 
> concurrenthashmap as "null" and on removal there is no check for null and 
> removes the nullappender with name null hence the NullPointerexception.
> Caused by: java.lang.NullPointerException
> at java.util.concurrent.ConcurrentHashMap.remove(Unknown Source)
> at 
> org.apache.log4j.helpers.AppenderAttachableImpl.removeAppender(AppenderAttachableImpl.java:93)
> at org.apache.log4j.Category.removeAppender(Category.java:618)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (LOG4J2-3471) log4j-1.2-api 2.17.2 throws NullPointerException while removing appender with name as null

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LOG4J2-3471:

Summary: log4j-1.2-api 2.17.2 throws NullPointerException while removing 
appender with name as null  (was: log4j-1.2-api-2.17.2 throws 
NullPointerException while removing appender with name as null)

> log4j-1.2-api 2.17.2 throws NullPointerException while removing appender with 
> name as null
> --
>
> Key: LOG4J2-3471
> URL: https://issues.apache.org/jira/browse/LOG4J2-3471
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.17.2
>Reporter: Rajesh
>Assignee: Gary D. Gregory
>Priority: Major
>
> The log4j 1.2 bridge for 2.17.2 throws null pointer exception while removing 
> Null appender
> viz. org.apache.log4j.varia.NullAppender 
> The class AppenderAttachableImpl adds the null appender to the 
> concurrenthashmap as "null" and on removal there is no check for null and 
> removes the nullappender with name null hence the NullPointerexception.
> Caused by: java.lang.NullPointerException
> at java.util.concurrent.ConcurrentHashMap.remove(Unknown Source)
> at 
> org.apache.log4j.helpers.AppenderAttachableImpl.removeAppender(AppenderAttachableImpl.java:93)
> at org.apache.log4j.Category.removeAppender(Category.java:618)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (LOG4J2-3471) log4j-1.2-api-2.17.2 throws exception while removing appender with name as null

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory reassigned LOG4J2-3471:
---

Assignee: Gary D. Gregory

> log4j-1.2-api-2.17.2 throws exception while removing appender with name as 
> null
> ---
>
> Key: LOG4J2-3471
> URL: https://issues.apache.org/jira/browse/LOG4J2-3471
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.17.2
>Reporter: Rajesh
>Assignee: Gary D. Gregory
>Priority: Major
>
> The log4j 1.2 bridge for 2.17.2 throws null pointer exception while removing 
> Null appender
> viz. org.apache.log4j.varia.NullAppender 
> The class AppenderAttachableImpl adds the null appender to the 
> concurrenthashmap as "null" and on removal there is no check for null and 
> removes the nullappender with name null hence the NullPointerexception.
> Caused by: java.lang.NullPointerException
> at java.util.concurrent.ConcurrentHashMap.remove(Unknown Source)
> at 
> org.apache.log4j.helpers.AppenderAttachableImpl.removeAppender(AppenderAttachableImpl.java:93)
> at org.apache.log4j.Category.removeAppender(Category.java:618)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (LOG4J2-3463) java.util.ServiceConfigurationError: org.apache.logging.log4j.spi.Provider: Provider org.apache.logging.log4j.core.impl.Log4jProvider not a subtype

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory reassigned LOG4J2-3463:
---

Assignee: (was: Gary D. Gregory)

> java.util.ServiceConfigurationError: org.apache.logging.log4j.spi.Provider: 
> Provider org.apache.logging.log4j.core.impl.Log4jProvider not a subtype
> ---
>
> Key: LOG4J2-3463
> URL: https://issues.apache.org/jira/browse/LOG4J2-3463
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API, Core, Log4j 1.2 bridge, Web/Servlet
>Affects Versions: 2.17.3
> Environment: Configuration:
> Using bridge api 2.17.3 latest snapshot. Also using log4j-web, log4j-api, 
> log4j-core (all 2.17.3 snapshot). A wrapper class is used for configuration 
> across applications running on tomcat.
>Reporter: Swapnil Markhedkar
>Priority: Blocker
> Attachments: Provider error.txt
>
>
> Came across this error while using tomcat at application level. Similar to 
> https://issues.apache.org/jira/browse/LOG4J2-2055, but error persists even 
> when added 2.10 jars.
> In depth stack trace has been attached as text file.
> NOTE: Tomcat server and it's logging is working fine.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (LOG4J2-3463) java.util.ServiceConfigurationError: org.apache.logging.log4j.spi.Provider: Provider org.apache.logging.log4j.core.impl.Log4jProvider not a subtype

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory reassigned LOG4J2-3463:
---

Assignee: Gary D. Gregory

> java.util.ServiceConfigurationError: org.apache.logging.log4j.spi.Provider: 
> Provider org.apache.logging.log4j.core.impl.Log4jProvider not a subtype
> ---
>
> Key: LOG4J2-3463
> URL: https://issues.apache.org/jira/browse/LOG4J2-3463
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API, Core, Log4j 1.2 bridge, Web/Servlet
>Affects Versions: 2.17.3
> Environment: Configuration:
> Using bridge api 2.17.3 latest snapshot. Also using log4j-web, log4j-api, 
> log4j-core (all 2.17.3 snapshot). A wrapper class is used for configuration 
> across applications running on tomcat.
>Reporter: Swapnil Markhedkar
>Assignee: Gary D. Gregory
>Priority: Blocker
> Attachments: Provider error.txt
>
>
> Came across this error while using tomcat at application level. Similar to 
> https://issues.apache.org/jira/browse/LOG4J2-2055, but error persists even 
> when added 2.10 jars.
> In depth stack trace has been attached as text file.
> NOTE: Tomcat server and it's logging is working fine.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3467) Update from Log4J 2.17.1 to 2.17.2 breaks application

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518282#comment-17518282
 ] 

Gary D. Gregory commented on LOG4J2-3467:
-

I just need something I can drop in and test, for me, I do not have issues with 
this kind of setup where I mix slf4j and log4j api's, all backed by log4j core. 
I am assuming you have log4j-slf4j-impl on your class path.

> Update from Log4J 2.17.1 to 2.17.2 breaks application
> -
>
> Key: LOG4J2-3467
> URL: https://issues.apache.org/jira/browse/LOG4J2-3467
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.17.2
>Reporter: Alexander Veit
>Priority: Major
>
> We have an application that uses a third-party library which seems to 
> reconfigure Log4J according to its needs. This worked for quite some years 
> with various Log4J versions.
> After upgrading from Log4J 2.17.1 to 2.17.2 a call to the library immediately 
> stops logging completely in the sense that no further logging is performed 
> until restarting the JVM.
> We've tried to identify the change that leads to the problem. Our best guess 
> is PropertyConfigurator, line 164 in
> https://github.com/apache/logging-log4j2/commit/73a2cd1cd0e94c7f4f36e4ac9dc72380d30750ef#diff-607596a6cadd10faf2dbeefc4e03092264b8e0dbe23fb89ffa6505d644602c9dR164
> Note that according to semantic versioning such breaking changes should not 
> occur when only the patch version is incremented. ;-)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3467) Update from Log4J 2.17.1 to 2.17.2 breaks application

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518262#comment-17518262
 ] 

Gary D. Gregory commented on LOG4J2-3467:
-

What is the class path you use to run this program? 

> Update from Log4J 2.17.1 to 2.17.2 breaks application
> -
>
> Key: LOG4J2-3467
> URL: https://issues.apache.org/jira/browse/LOG4J2-3467
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.17.2
>Reporter: Alexander Veit
>Priority: Major
>
> We have an application that uses a third-party library which seems to 
> reconfigure Log4J according to its needs. This worked for quite some years 
> with various Log4J versions.
> After upgrading from Log4J 2.17.1 to 2.17.2 a call to the library immediately 
> stops logging completely in the sense that no further logging is performed 
> until restarting the JVM.
> We've tried to identify the change that leads to the problem. Our best guess 
> is PropertyConfigurator, line 164 in
> https://github.com/apache/logging-log4j2/commit/73a2cd1cd0e94c7f4f36e4ac9dc72380d30750ef#diff-607596a6cadd10faf2dbeefc4e03092264b8e0dbe23fb89ffa6505d644602c9dR164
> Note that according to semantic versioning such breaking changes should not 
> occur when only the patch version is incremented. ;-)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3467) Update from Log4J 2.17.1 to 2.17.2 breaks application

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518130#comment-17518130
 ] 

Gary D. Gregory commented on LOG4J2-3467:
-

Thank you for your report.

We need something to reproduce this issue, a small app, a failing unit test, a 
better and detailed description. 

> Update from Log4J 2.17.1 to 2.17.2 breaks application
> -
>
> Key: LOG4J2-3467
> URL: https://issues.apache.org/jira/browse/LOG4J2-3467
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.17.2
>Reporter: Alexander Veit
>Priority: Major
>
> We have an application that uses a third-party library which seems to 
> reconfigure Log4J according to its needs. This worked for quite some years 
> with various Log4J versions.
> After upgrading from Log4J 2.17.1 to 2.17.2 a call to the library immediately 
> stops logging completely in the sense that no further logging is performed 
> until restarting the JVM.
> We've tried to identify the change that leads to the problem. Our best guess 
> is PropertyConfigurator, line 164 in
> https://github.com/apache/logging-log4j2/commit/73a2cd1cd0e94c7f4f36e4ac9dc72380d30750ef#diff-607596a6cadd10faf2dbeefc4e03092264b8e0dbe23fb89ffa6505d644602c9dR164
> Note that according to semantic versioning such breaking changes should not 
> occur when only the patch version is incremented. ;-)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (LOG4J2-3458) LocalizedMessage logs misleading errors on the console

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory resolved LOG4J2-3458.
-
Fix Version/s: 2.17.3
   Resolution: Fixed

Fixed in 
{{org.apache.logging.log4j.message.StringFormattedMessage.formatMessage(String, 
Object...)}}

> LocalizedMessage logs misleading errors on the console
> --
>
> Key: LOG4J2-3458
> URL: https://issues.apache.org/jira/browse/LOG4J2-3458
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.17.2
>Reporter: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.3
>
>
> I have an app where we log data that is percent encoded through a localized 
> message factory. We get a ton of noise on the console due to logging of 
> internal exceptions, for example:
> ERROR StatusLogger Unable to format msg: 
> C:/Program%20Files/Some%20Company/Some%20Product%20Name/
>  java.util.UnknownFormatConversionException: Conversion = 'F'
>     at java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2691)
>     at java.util.Formatter$FormatSpecifier.(Formatter.java:2720)
>     at java.util.Formatter.parse(Formatter.java:2560)
>     at java.util.Formatter.format(Formatter.java:2501)
>     at java.util.Formatter.format(Formatter.java:2455)
>     at java.lang.String.format(String.java:2981)
>     at 
> org.apache.logging.log4j.message.StringFormattedMessage.formatMessage(StringFormattedMessage.java:116)
>     at 
> org.apache.logging.log4j.message.StringFormattedMessage.getFormattedMessage(StringFormattedMessage.java:88)
>     at 
> org.apache.logging.log4j.message.FormattedMessage.getFormattedMessage(FormattedMessage.java:178)
>     at 
> org.apache.logging.log4j.message.LocalizedMessage.getFormattedMessage(LocalizedMessage.java:196)
>     at 
> org.apache.logging.log4j.message.LocalizedSimpleMessageFactoryTest.testNoMatchPercentInMessage(LocalizedSimpleMessageFactoryTest.java:79)
> I updated this test to demonstrate: 
> [https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-api/src/test/java/org/apache/logging/log4j/message/LocalizedMessageFactoryTest.java]
> In a nutshell:
> {code:java}
>     @Test
>     public void testNoMatchPercentInMessage() {
>         final LocalizedMessageFactory localizedMessageFactory = new 
> LocalizedMessageFactory(ResourceBundle.getBundle("MF", Locale.US));
>         final Message message = 
> localizedMessageFactory.newMessage("C:/Program%20Files/Some%20Company/Some%20Product%20Name/");
>         
> assertEquals("C:/Program%20Files/Some%20Company/Some%20Product%20Name/", 
> message.getFormattedMessage());
>     }
> {code}
> Options:
> - Don't log the exception (simple)
> - Log at the TRACE level instead of ERROR.
> - Provide a better simpler localized MessageFactory that does not perform % 
> substitution
> - ?
> I read the Javadoc that says that using a localized MessageFactory is not 
> preferred, but it would be a large change for our app.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (LOG4J2-3458) LocalizedMessage logs misleading errors on the console

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LOG4J2-3458:

Summary: LocalizedMessage logs misleading errors on the console  (was: 
LocalizedMessage logs misleading errors on the console\)

> LocalizedMessage logs misleading errors on the console
> --
>
> Key: LOG4J2-3458
> URL: https://issues.apache.org/jira/browse/LOG4J2-3458
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.17.2
>Reporter: Gary D. Gregory
>Priority: Major
>
> I have an app where we log data that is percent encoded through a localized 
> message factory. We get a ton of noise on the console due to logging of 
> internal exceptions, for example:
> ERROR StatusLogger Unable to format msg: 
> C:/Program%20Files/Some%20Company/Some%20Product%20Name/
>  java.util.UnknownFormatConversionException: Conversion = 'F'
>     at java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2691)
>     at java.util.Formatter$FormatSpecifier.(Formatter.java:2720)
>     at java.util.Formatter.parse(Formatter.java:2560)
>     at java.util.Formatter.format(Formatter.java:2501)
>     at java.util.Formatter.format(Formatter.java:2455)
>     at java.lang.String.format(String.java:2981)
>     at 
> org.apache.logging.log4j.message.StringFormattedMessage.formatMessage(StringFormattedMessage.java:116)
>     at 
> org.apache.logging.log4j.message.StringFormattedMessage.getFormattedMessage(StringFormattedMessage.java:88)
>     at 
> org.apache.logging.log4j.message.FormattedMessage.getFormattedMessage(FormattedMessage.java:178)
>     at 
> org.apache.logging.log4j.message.LocalizedMessage.getFormattedMessage(LocalizedMessage.java:196)
>     at 
> org.apache.logging.log4j.message.LocalizedSimpleMessageFactoryTest.testNoMatchPercentInMessage(LocalizedSimpleMessageFactoryTest.java:79)
> I updated this test to demonstrate: 
> [https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-api/src/test/java/org/apache/logging/log4j/message/LocalizedMessageFactoryTest.java]
> In a nutshell:
> {code:java}
>     @Test
>     public void testNoMatchPercentInMessage() {
>         final LocalizedMessageFactory localizedMessageFactory = new 
> LocalizedMessageFactory(ResourceBundle.getBundle("MF", Locale.US));
>         final Message message = 
> localizedMessageFactory.newMessage("C:/Program%20Files/Some%20Company/Some%20Product%20Name/");
>         
> assertEquals("C:/Program%20Files/Some%20Company/Some%20Product%20Name/", 
> message.getFormattedMessage());
>     }
> {code}
> Options:
> - Don't log the exception (simple)
> - Log at the TRACE level instead of ERROR.
> - Provide a better simpler localized MessageFactory that does not perform % 
> substitution
> - ?
> I read the Javadoc that says that using a localized MessageFactory is not 
> preferred, but it would be a large change for our app.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (LOG4J2-3458) LocalizedMessage logs misleading errors on the console.

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LOG4J2-3458:

Summary: LocalizedMessage logs misleading errors on the console.  (was: 
LocalizedMessage causes a lot of noise on the console)

> LocalizedMessage logs misleading errors on the console.
> ---
>
> Key: LOG4J2-3458
> URL: https://issues.apache.org/jira/browse/LOG4J2-3458
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.17.2
>Reporter: Gary D. Gregory
>Priority: Major
>
> I have an app where we log data that is percent encoded through a localized 
> message factory. We get a ton of noise on the console due to logging of 
> internal exceptions, for example:
> ERROR StatusLogger Unable to format msg: 
> C:/Program%20Files/Some%20Company/Some%20Product%20Name/
>  java.util.UnknownFormatConversionException: Conversion = 'F'
>     at java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2691)
>     at java.util.Formatter$FormatSpecifier.(Formatter.java:2720)
>     at java.util.Formatter.parse(Formatter.java:2560)
>     at java.util.Formatter.format(Formatter.java:2501)
>     at java.util.Formatter.format(Formatter.java:2455)
>     at java.lang.String.format(String.java:2981)
>     at 
> org.apache.logging.log4j.message.StringFormattedMessage.formatMessage(StringFormattedMessage.java:116)
>     at 
> org.apache.logging.log4j.message.StringFormattedMessage.getFormattedMessage(StringFormattedMessage.java:88)
>     at 
> org.apache.logging.log4j.message.FormattedMessage.getFormattedMessage(FormattedMessage.java:178)
>     at 
> org.apache.logging.log4j.message.LocalizedMessage.getFormattedMessage(LocalizedMessage.java:196)
>     at 
> org.apache.logging.log4j.message.LocalizedSimpleMessageFactoryTest.testNoMatchPercentInMessage(LocalizedSimpleMessageFactoryTest.java:79)
> I updated this test to demonstrate: 
> [https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-api/src/test/java/org/apache/logging/log4j/message/LocalizedMessageFactoryTest.java]
> In a nutshell:
> {code:java}
>     @Test
>     public void testNoMatchPercentInMessage() {
>         final LocalizedMessageFactory localizedMessageFactory = new 
> LocalizedMessageFactory(ResourceBundle.getBundle("MF", Locale.US));
>         final Message message = 
> localizedMessageFactory.newMessage("C:/Program%20Files/Some%20Company/Some%20Product%20Name/");
>         
> assertEquals("C:/Program%20Files/Some%20Company/Some%20Product%20Name/", 
> message.getFormattedMessage());
>     }
> {code}
> Options:
> - Don't log the exception (simple)
> - Log at the TRACE level instead of ERROR.
> - Provide a better simpler localized MessageFactory that does not perform % 
> substitution
> - ?
> I read the Javadoc that says that using a localized MessageFactory is not 
> preferred, but it would be a large change for our app.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (LOG4J2-3458) LocalizedMessage logs misleading errors on the console\

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LOG4J2-3458:

Summary: LocalizedMessage logs misleading errors on the console\  (was: 
LocalizedMessage logs misleading errors on the console.)

> LocalizedMessage logs misleading errors on the console\
> ---
>
> Key: LOG4J2-3458
> URL: https://issues.apache.org/jira/browse/LOG4J2-3458
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.17.2
>Reporter: Gary D. Gregory
>Priority: Major
>
> I have an app where we log data that is percent encoded through a localized 
> message factory. We get a ton of noise on the console due to logging of 
> internal exceptions, for example:
> ERROR StatusLogger Unable to format msg: 
> C:/Program%20Files/Some%20Company/Some%20Product%20Name/
>  java.util.UnknownFormatConversionException: Conversion = 'F'
>     at java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2691)
>     at java.util.Formatter$FormatSpecifier.(Formatter.java:2720)
>     at java.util.Formatter.parse(Formatter.java:2560)
>     at java.util.Formatter.format(Formatter.java:2501)
>     at java.util.Formatter.format(Formatter.java:2455)
>     at java.lang.String.format(String.java:2981)
>     at 
> org.apache.logging.log4j.message.StringFormattedMessage.formatMessage(StringFormattedMessage.java:116)
>     at 
> org.apache.logging.log4j.message.StringFormattedMessage.getFormattedMessage(StringFormattedMessage.java:88)
>     at 
> org.apache.logging.log4j.message.FormattedMessage.getFormattedMessage(FormattedMessage.java:178)
>     at 
> org.apache.logging.log4j.message.LocalizedMessage.getFormattedMessage(LocalizedMessage.java:196)
>     at 
> org.apache.logging.log4j.message.LocalizedSimpleMessageFactoryTest.testNoMatchPercentInMessage(LocalizedSimpleMessageFactoryTest.java:79)
> I updated this test to demonstrate: 
> [https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-api/src/test/java/org/apache/logging/log4j/message/LocalizedMessageFactoryTest.java]
> In a nutshell:
> {code:java}
>     @Test
>     public void testNoMatchPercentInMessage() {
>         final LocalizedMessageFactory localizedMessageFactory = new 
> LocalizedMessageFactory(ResourceBundle.getBundle("MF", Locale.US));
>         final Message message = 
> localizedMessageFactory.newMessage("C:/Program%20Files/Some%20Company/Some%20Product%20Name/");
>         
> assertEquals("C:/Program%20Files/Some%20Company/Some%20Product%20Name/", 
> message.getFormattedMessage());
>     }
> {code}
> Options:
> - Don't log the exception (simple)
> - Log at the TRACE level instead of ERROR.
> - Provide a better simpler localized MessageFactory that does not perform % 
> substitution
> - ?
> I read the Javadoc that says that using a localized MessageFactory is not 
> preferred, but it would be a large change for our app.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (LOG4J2-3458) LocalizedMessage causes a lot of noise on the console

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LOG4J2-3458:

Description: 
I have an app where we log data that is percent encoded through a localized 
message factory. We get a ton of noise on the console due to logging of 
internal exceptions, for example:

ERROR StatusLogger Unable to format msg: 
C:/Program%20Files/Some%20Company/Some%20Product%20Name/
 java.util.UnknownFormatConversionException: Conversion = 'F'
    at java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2691)
    at java.util.Formatter$FormatSpecifier.(Formatter.java:2720)
    at java.util.Formatter.parse(Formatter.java:2560)
    at java.util.Formatter.format(Formatter.java:2501)
    at java.util.Formatter.format(Formatter.java:2455)
    at java.lang.String.format(String.java:2981)
    at 
org.apache.logging.log4j.message.StringFormattedMessage.formatMessage(StringFormattedMessage.java:116)
    at 
org.apache.logging.log4j.message.StringFormattedMessage.getFormattedMessage(StringFormattedMessage.java:88)
    at 
org.apache.logging.log4j.message.FormattedMessage.getFormattedMessage(FormattedMessage.java:178)
    at 
org.apache.logging.log4j.message.LocalizedMessage.getFormattedMessage(LocalizedMessage.java:196)
    at 
org.apache.logging.log4j.message.LocalizedSimpleMessageFactoryTest.testNoMatchPercentInMessage(LocalizedSimpleMessageFactoryTest.java:79)

I updated this test to demonstrate: 
[https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-api/src/test/java/org/apache/logging/log4j/message/LocalizedMessageFactoryTest.java]

In a nutshell:
{code:java}
    @Test
    public void testNoMatchPercentInMessage() {
        final LocalizedMessageFactory localizedMessageFactory = new 
LocalizedMessageFactory(ResourceBundle.getBundle("MF", Locale.US));
        final Message message = 
localizedMessageFactory.newMessage("C:/Program%20Files/Some%20Company/Some%20Product%20Name/");
        
assertEquals("C:/Program%20Files/Some%20Company/Some%20Product%20Name/", 
message.getFormattedMessage());
    }
{code}

Options:
- Don't log the exception (simple)
- Log at the TRACE level instead of ERROR.
- Provide a better simpler localized MessageFactory that does not perform % 
substitution
- ?

I read the Javadoc that says that using a localized MessageFactory is not 
preferred, but it would be a large change for our app.

  was:
I have an app where we log data that is percent encoded through a localized 
message factory. We get a ton of noise on the console due to logging of 
internal exceptions, for example:

ERROR StatusLogger Unable to format msg: 
C:/Program%20Files/Some%20Company/Some%20Product%20Name/
 java.util.UnknownFormatConversionException: Conversion = 'F'
    at java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2691)
    at java.util.Formatter$FormatSpecifier.(Formatter.java:2720)
    at java.util.Formatter.parse(Formatter.java:2560)
    at java.util.Formatter.format(Formatter.java:2501)
    at java.util.Formatter.format(Formatter.java:2455)
    at java.lang.String.format(String.java:2981)
    at 
org.apache.logging.log4j.message.StringFormattedMessage.formatMessage(StringFormattedMessage.java:116)
    at 
org.apache.logging.log4j.message.StringFormattedMessage.getFormattedMessage(StringFormattedMessage.java:88)
    at 
org.apache.logging.log4j.message.FormattedMessage.getFormattedMessage(FormattedMessage.java:178)
    at 
org.apache.logging.log4j.message.LocalizedMessage.getFormattedMessage(LocalizedMessage.java:196)
    at 
org.apache.logging.log4j.message.LocalizedSimpleMessageFactoryTest.testNoMatchPercentInMessage(LocalizedSimpleMessageFactoryTest.java:79)

I added to this test to demonstrate: 
[https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-api/src/test/java/org/apache/logging/log4j/message/LocalizedMessageFactoryTest.java]

In a nutshell:
{code:java}
    @Test
    public void testNoMatchPercentInMessage() {
        final LocalizedMessageFactory localizedMessageFactory = new 
LocalizedMessageFactory(ResourceBundle.getBundle("MF", Locale.US));
        final Message message = 
localizedMessageFactory.newMessage("C:/Program%20Files/Some%20Company/Some%20Product%20Name/");
        
assertEquals("C:/Program%20Files/Some%20Company/Some%20Product%20Name/", 
message.getFormattedMessage());
    }
{code}


> LocalizedMessage causes a lot of noise on the console
> -
>
> Key: LOG4J2-3458
> URL: https://issues.apache.org/jira/browse/LOG4J2-3458
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.17.2
>Reporter: Gary D. Gregory
>Priority: Major
>
> I have an app where we log data that is percent encoded through a localized 
> message factory. We get a ton of noise on the console due to 

[jira] [Created] (LOG4J2-3458) LocalizedMessage causes a lot of noise on the console

[Gary D. Gregory (Jira)]

Gary D. Gregory created LOG4J2-3458:
---

 Summary: LocalizedMessage causes a lot of noise on the console
 Key: LOG4J2-3458
 URL: https://issues.apache.org/jira/browse/LOG4J2-3458
 Project: Log4j 2
  Issue Type: Bug
  Components: API
Affects Versions: 2.17.2
Reporter: Gary D. Gregory


I have an app where we log data that is percent encoded through a localized 
message factory. We get a ton of noise on the console due to logging of 
internal exceptions, for example:

ERROR StatusLogger Unable to format msg: 
C:/Program%20Files/Some%20Company/Some%20Product%20Name/
 java.util.UnknownFormatConversionException: Conversion = 'F'
    at java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2691)
    at java.util.Formatter$FormatSpecifier.(Formatter.java:2720)
    at java.util.Formatter.parse(Formatter.java:2560)
    at java.util.Formatter.format(Formatter.java:2501)
    at java.util.Formatter.format(Formatter.java:2455)
    at java.lang.String.format(String.java:2981)
    at 
org.apache.logging.log4j.message.StringFormattedMessage.formatMessage(StringFormattedMessage.java:116)
    at 
org.apache.logging.log4j.message.StringFormattedMessage.getFormattedMessage(StringFormattedMessage.java:88)
    at 
org.apache.logging.log4j.message.FormattedMessage.getFormattedMessage(FormattedMessage.java:178)
    at 
org.apache.logging.log4j.message.LocalizedMessage.getFormattedMessage(LocalizedMessage.java:196)
    at 
org.apache.logging.log4j.message.LocalizedSimpleMessageFactoryTest.testNoMatchPercentInMessage(LocalizedSimpleMessageFactoryTest.java:79)

I added to this test to demonstrate: 
[https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-api/src/test/java/org/apache/logging/log4j/message/LocalizedMessageFactoryTest.java]

In a nutshell:
{code:java}
    @Test
    public void testNoMatchPercentInMessage() {
        final LocalizedMessageFactory localizedMessageFactory = new 
LocalizedMessageFactory(ResourceBundle.getBundle("MF", Locale.US));
        final Message message = 
localizedMessageFactory.newMessage("C:/Program%20Files/Some%20Company/Some%20Product%20Name/");
        
assertEquals("C:/Program%20Files/Some%20Company/Some%20Product%20Name/", 
message.getFormattedMessage());
    }
{code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514812#comment-17514812
 ] 

Gary D. Gregory commented on LOG4J2-2795:
-

Another use case that would benefit from faster start-up time is 
unit/integration testing. Some apps I test have to perform some init and 
shutdown for each test to provide just enough of an environment for these tests 
to run, and some of that is logging configuration/shutdown.

> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
>  Issue Type: Task
>  Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by 
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test 
> with classpath scanning takes ~50ms).
>  
> This ticket is about trying to be faster (maybe by removing java 
> serialization usage and reducing registry usage + reflection of plugins by 
> generating java code?).



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3440) Log4j 1.2 bridge getAllAppenders() returns null enumeration

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17512040#comment-17512040
 ] 

Gary D. Gregory commented on LOG4J2-3440:
-

It seems that we should do something that is a close to Log4j 1.2 as possible. 
Internally, the whole "aai" implementation feels wrong since this is now a 
bridge rather than an implementation. We can do something simple for now and 
2.17.3 just so that we do not return an empty enumeration, so just the 1.2 
specific appenders I would say.

> Log4j 1.2 bridge getAllAppenders() returns null enumeration
> ---
>
> Key: LOG4J2-3440
> URL: https://issues.apache.org/jira/browse/LOG4J2-3440
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pablo Rogina
>Assignee: Piotr Karwasz
>Priority: Major
>
> Old application using Log4j 1.2.x relies on Logger.getAllAppenders() to 
> decide if Log4j it's already configured (returned Enumeration has at least 1 
> appender) or not (empty returned Enumeration).
> Some recent code audits mandate to remove log4j v1 component(s) and to 
> upgrade to latest 2.17.2 release, so we're using Log4j 1.2 Bridge to comply 
> and not to change application code.
> However, we're facing the issue describe here [1] for 
> Logger.getRootLogger().getAllAppenders() although with latest Log4j release 
> 2.17.2 the issue seems to be that data structure aai is never updated with 
> the proper configured appenders, given that now most of the work happens in 
> the Log4j v2 Core implementation, thus using LoggerContext
> [1] [java - Log4j getAllAppenders() returns null enumeration - Stack 
> Overflow|https://stackoverflow.com/questions/32864929/log4j-getallappenders-returns-null-enumeration]
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3444) Log4j 1.2 Unsupported Flagging by Nessus

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511458#comment-17511458
 ] 

Gary D. Gregory commented on LOG4J2-3444:
-

I do not see that we have to get in between two companies' businesses. You 
should contact them.

> Log4j 1.2 Unsupported Flagging by Nessus
> 
>
> Key: LOG4J2-3444
> URL: https://issues.apache.org/jira/browse/LOG4J2-3444
> Project: Log4j 2
>  Issue Type: Question
>Reporter: Sanjeev Kumar
>Priority: Major
>
> The Apache log4j open source software has a critical security vulnerabilities 
> in both major versions (1.x and 2.x). This is highlighted in:
> +[https://logging.apache.org/log4j/2.x/security.html]+
> We have many products deployed in RHEL7 that currently uses log4j version 1.x
> The Nessus Pluggin that scans the security vulnerabilities in products 
> declares that Log4j version 1.2 is unsupported. The Pluggin details are in:
> +[https://www.tenable.com/plugins/nessus/156032]+
> This is solely based on Apache Log4j EOL notice to version 1.x and 
> recommendation to upgrade to version 2.17+. The details of which are 
> available in:
> +[https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces]+
> But RedHat has been supporting deploying patches to version 1.2 to address 
> the recent security vulnerabilities and deploying patches as evident in:
> +[https://access.redhat.com/errata/RHSA-2022:0439]+
> Since, we have many third-party products dependent on log4j version 1.2 and 
> we need to update these third party products to log4j version 2.x, it is a 
> huge development. We plan to upgrade to version 2.x in the future, but until 
> then we need to address the Nessus Pluggin scans that is declaring Log4j 
> version 1.2 as unsupported, which is clearly incorrect as per RedHat.
> I request Log4j support to work work with Nessus Pluggin support to  
> facilitate declaring Log4j version 1.2.17+ as supported and not flag any 
> scans from Nessus Pluggin described above to flag the Log4j version 1.2.17+ 
> as unsupported.. It will give us some time frame to deploying the new Log4j 
> 2x. 
> Also, if thers any other way to contact Log4j support support in this matter, 
> please let me know.
> Thanks,
> Sanjeev
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3440) Log4j 1.2 bridge getAllAppenders() returns null enumeration

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510697#comment-17510697
 ] 

Gary D. Gregory commented on LOG4J2-3440:
-

For good or bad, I see this type of behavior all the time. If there is no 
config found, then an app creates one on the fly. If some condition is met, 
could be some admin  request or other signal, then reconfigue on the fly to 
some other settings. 

> Log4j 1.2 bridge getAllAppenders() returns null enumeration
> ---
>
> Key: LOG4J2-3440
> URL: https://issues.apache.org/jira/browse/LOG4J2-3440
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pablo Rogina
>Assignee: Piotr Karwasz
>Priority: Major
>
> Old application using Log4j 1.2.x relies on Logger.getAllAppenders() to 
> decide if Log4j it's already configured (returned Enumeration has at least 1 
> appender) or not (empty returned Enumeration).
> Some recent code audits mandate to remove log4j v1 component(s) and to 
> upgrade to latest 2.17.2 release, so we're using Log4j 1.2 Bridge to comply 
> and not to change application code.
> However, we're facing the issue describe here [1] for 
> Logger.getRootLogger().getAllAppenders() although with latest Log4j release 
> 2.17.2 the issue seems to be that data structure aai is never updated with 
> the proper configured appenders, given that now most of the work happens in 
> the Log4j v2 Core implementation, thus using LoggerContext
> [1] [java - Log4j getAllAppenders() returns null enumeration - Stack 
> Overflow|https://stackoverflow.com/questions/32864929/log4j-getallappenders-returns-null-enumeration]
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (LOG4J2-3440) Log4j 1.2 bridge getAllAppenders() returns null enumeration

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510375#comment-17510375
 ] 

Gary D. Gregory edited comment on LOG4J2-3440 at 3/22/22, 9:51 AM:
---

Hi all,

The bridge code has greatly improved in 2.17.2 but it is not perfect, so I 
would like us to keep making it better. I think we are already way above the 
80/20 rule FWIW. Any help is appreciated and your reporting this issue does 
help: -)


was (Author: garydgregory):
Hi all,

The bridge code has greatly improved in 2.17.2 but it is not perfect, so I 
would like us keep making it better. I think we are already way above the 80/20 
rule FWIW. Any help is appreciated and your reporting this issue does help: -)

> Log4j 1.2 bridge getAllAppenders() returns null enumeration
> ---
>
> Key: LOG4J2-3440
> URL: https://issues.apache.org/jira/browse/LOG4J2-3440
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pablo Rogina
>Assignee: Piotr Karwasz
>Priority: Major
>
> Old application using Log4j 1.2.x relies on Logger.getAllAppenders() to 
> decide if Log4j it's already configured (returned Enumeration has at least 1 
> appender) or not (empty returned Enumeration).
> Some recent code audits mandate to remove log4j v1 component(s) and to 
> upgrade to latest 2.17.2 release, so we're using Log4j 1.2 Bridge to comply 
> and not to change application code.
> However, we're facing the issue describe here [1] for 
> Logger.getRootLogger().getAllAppenders() although with latest Log4j release 
> 2.17.2 the issue seems to be that data structure aai is never updated with 
> the proper configured appenders, given that now most of the work happens in 
> the Log4j v2 Core implementation, thus using LoggerContext
> [1] [java - Log4j getAllAppenders() returns null enumeration - Stack 
> Overflow|https://stackoverflow.com/questions/32864929/log4j-getallappenders-returns-null-enumeration]
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3440) Log4j 1.2 bridge getAllAppenders() returns null enumeration

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510375#comment-17510375
 ] 

Gary D. Gregory commented on LOG4J2-3440:
-

Hi all,

The bridge code has greatly improved in 2.17.2 but it is not perfect, so I 
would like us keep making it better. I think we are already way above the 80/20 
rule FWIW. Any help is appreciated and your reporting this issue does help: -)

> Log4j 1.2 bridge getAllAppenders() returns null enumeration
> ---
>
> Key: LOG4J2-3440
> URL: https://issues.apache.org/jira/browse/LOG4J2-3440
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pablo Rogina
>Assignee: Piotr Karwasz
>Priority: Major
>
> Old application using Log4j 1.2.x relies on Logger.getAllAppenders() to 
> decide if Log4j it's already configured (returned Enumeration has at least 1 
> appender) or not (empty returned Enumeration).
> Some recent code audits mandate to remove log4j v1 component(s) and to 
> upgrade to latest 2.17.2 release, so we're using Log4j 1.2 Bridge to comply 
> and not to change application code.
> However, we're facing the issue describe here [1] for 
> Logger.getRootLogger().getAllAppenders() although with latest Log4j release 
> 2.17.2 the issue seems to be that data structure aai is never updated with 
> the proper configured appenders, given that now most of the work happens in 
> the Log4j v2 Core implementation, thus using LoggerContext
> [1] [java - Log4j getAllAppenders() returns null enumeration - Stack 
> Overflow|https://stackoverflow.com/questions/32864929/log4j-getallappenders-returns-null-enumeration]
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (LOG4J2-3428) Update 3rd party dependencies for 2.17.3

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LOG4J2-3428:

Description: 
This ticket should only be closed when we release 2.17.3.

The updated dependencies are:

* com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2
* com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2
* com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2
* com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2
* com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2
* com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> 2.13.2
* com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre
* de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3
* org.apache.maven:maven-core 3.8.4 -> 3.8.5
* org.awaitility:awaitility 4.1.1 -> 4.2.0
* org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10
* org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10
* org.junit-pioneer:junit-pioneer from 1.6.1 to 1.6.2
* org.mockito:mockito-core from 4.3.1 to 4.4.0
* org.mockito:mockito-junit-jupiter from 4.3.1 to 4.4.0
* org.springframework:spring-aop from 5.3.16 to 5.3.17
* org.springframework:spring-beans from 5.3.16 to 5.3.17
* org.springframework:spring-context from 5.3.16 to 5.3.17
* org.springframework:spring-context-support from 5.3.16 to 5.3.17
* org.springframework:spring-core from 5.3.16 to 5.3.17
* org.springframework:spring-expression from 5.3.16 to 5.3.17
* org.springframework:spring-oxm from 5.3.16 to 5.3.17
* org.springframework:spring-test from 5.3.16 to 5.3.17
* org.springframework:spring-web from 5.3.16 to 5.3.17
* org.springframework:spring-webmvc from 5.3.16 to 5.3.17


  was:
This ticket should only be closed when we release 2.17.3.

The updated dependencies are:

* com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2
* com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2
* com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2
* com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2
* com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2
* com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> 2.13.2
* com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre
* de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3
* org.awaitility:awaitility 4.1.1 -> 4.2.0
* org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10
* org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10
* org.junit-pioneer:junit-pioneer from 1.6.1 to 1.6.2
* org.mockito:mockito-core from 4.3.1 to 4.4.0
* org.mockito:mockito-junit-jupiter from 4.3.1 to 4.4.0
* org.springframework:spring-aop 5.3.15 -> 5.3.16
* org.springframework:spring-beans 5.3.15 -> 5.3.16
* org.springframework:spring-context 5.3.15 -> 5.3.16
* org.springframework:spring-context-support 5.3.15 -> 5.3.16
* org.springframework:spring-core 5.3.15 -> 5.3.16
* org.springframework:spring-expression 5.3.15 -> 5.3.16
* org.springframework:spring-oxm 5.3.15 -> 5.3.16
* org.springframework:spring-test 5.3.15 -> 5.3.16
* org.springframework:spring-web 5.3.15 -> 5.3.16
* org.springframework:spring-webmvc 5.3.15 -> 5.3.16



> Update 3rd party dependencies for 2.17.3
> 
>
> Key: LOG4J2-3428
> URL: https://issues.apache.org/jira/browse/LOG4J2-3428
> Project: Log4j 2
>  Issue Type: Task
>  Components: Build
>Reporter: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.3
>
>
> This ticket should only be closed when we release 2.17.3.
> The updated dependencies are:
> * com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> 
> 2.13.2
> * com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre
> * de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3
> * org.apache.maven:maven-core 3.8.4 -> 3.8.5
> * org.awaitility:awaitility 4.1.1 -> 4.2.0
> * org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10
> * org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10
> * org.junit-pioneer:junit-pioneer from 1.6.1 to 1.6.2
> * org.mockito:mockito-core from 4.3.1 to 4.4.0
> * org.mockito:mockito-junit-jupiter from 4.3.1 to 4.4.0
> * org.springframework:spring-aop from 5.3.16 to 5.3.17
> * org.springframework:spring-beans from 5.3.16 to 5.3.17
> * org.springframework:spring-context from 5.3.16 to 5.3.17
> * org.springframework:spring-context-support from 5.3.16 to 5.3.17
> * org.springframework:spring-core from 5.3.16 to 5.3.17
> * 

[jira] [Updated] (LOG4J2-3428) Update 3rd party dependencies for 2.17.3

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LOG4J2-3428:

Description: 
This ticket should only be closed when we release 2.17.3.

The updated dependencies are:

* com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2
* com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2
* com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2
* com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2
* com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2
* com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> 2.13.2
* com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre
* de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3
* org.awaitility:awaitility 4.1.1 -> 4.2.0
* org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10
* org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10
* org.junit-pioneer:junit-pioneer from 1.6.1 to 1.6.2
* org.mockito:mockito-core from 4.3.1 to 4.4.0
* org.mockito:mockito-junit-jupiter from 4.3.1 to 4.4.0
* org.springframework:spring-aop 5.3.15 -> 5.3.16
* org.springframework:spring-beans 5.3.15 -> 5.3.16
* org.springframework:spring-context 5.3.15 -> 5.3.16
* org.springframework:spring-context-support 5.3.15 -> 5.3.16
* org.springframework:spring-core 5.3.15 -> 5.3.16
* org.springframework:spring-expression 5.3.15 -> 5.3.16
* org.springframework:spring-oxm 5.3.15 -> 5.3.16
* org.springframework:spring-test 5.3.15 -> 5.3.16
* org.springframework:spring-web 5.3.15 -> 5.3.16
* org.springframework:spring-webmvc 5.3.15 -> 5.3.16


  was:
This ticket should only be closed when we release 2.17.3.

The updated dependencies are:

* com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2
* com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2
* com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2
* com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2
* com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2
* com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> 2.13.2
* com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre
* de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3
* org.awaitility:awaitility 4.1.1 -> 4.2.0
* org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10
* org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10
* org.springframework:spring-aop 5.3.15 -> 5.3.16
* org.springframework:spring-beans 5.3.15 -> 5.3.16
* org.springframework:spring-context 5.3.15 -> 5.3.16
* org.springframework:spring-context-support 5.3.15 -> 5.3.16
* org.springframework:spring-core 5.3.15 -> 5.3.16
* org.springframework:spring-expression 5.3.15 -> 5.3.16
* org.springframework:spring-oxm 5.3.15 -> 5.3.16
* org.springframework:spring-test 5.3.15 -> 5.3.16
* org.springframework:spring-web 5.3.15 -> 5.3.16
* org.springframework:spring-webmvc 5.3.15 -> 5.3.16
* Bump org.mockito:mockito-core from 4.3.1 to 4.4.0
* Bump org.mockito:mockito-junit-jupiter from 4.3.1 to 4.4.0



> Update 3rd party dependencies for 2.17.3
> 
>
> Key: LOG4J2-3428
> URL: https://issues.apache.org/jira/browse/LOG4J2-3428
> Project: Log4j 2
>  Issue Type: Task
>  Components: Build
>Reporter: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.3
>
>
> This ticket should only be closed when we release 2.17.3.
> The updated dependencies are:
> * com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> 
> 2.13.2
> * com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre
> * de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3
> * org.awaitility:awaitility 4.1.1 -> 4.2.0
> * org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10
> * org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10
> * org.junit-pioneer:junit-pioneer from 1.6.1 to 1.6.2
> * org.mockito:mockito-core from 4.3.1 to 4.4.0
> * org.mockito:mockito-junit-jupiter from 4.3.1 to 4.4.0
> * org.springframework:spring-aop 5.3.15 -> 5.3.16
> * org.springframework:spring-beans 5.3.15 -> 5.3.16
> * org.springframework:spring-context 5.3.15 -> 5.3.16
> * org.springframework:spring-context-support 5.3.15 -> 5.3.16
> * org.springframework:spring-core 5.3.15 -> 5.3.16
> * org.springframework:spring-expression 5.3.15 -> 5.3.16
> * org.springframework:spring-oxm 5.3.15 -> 5.3.16
> * org.springframework:spring-test 5.3.15 -> 5.3.16
> * org.springframework:spring-web 5.3.15 -> 5.3.16
> * 

[jira] [Commented] (LOG4J2-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507798#comment-17507798
 ] 

Gary D. Gregory commented on LOG4J2-3437:
-

FTR, the method is {{org.apache.log4j.Category.addAppender(Appender)}}, the 
superclass of Logger in 1.2.

> Log4j 1.x bridge Request to support programmatically configuring Log4j.
> ---
>
> Key: LOG4J2-3437
> URL: https://issues.apache.org/jira/browse/LOG4J2-3437
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
>
> As per log4j migration documentation 
> ([https://logging.apache.org/log4j/2.x/manual/migration.html),|https://logging.apache.org/log4j/2.x/manual/migration.html)]
>  I understand that currently log4j 1.x bridge 2.17.2 doesn't support 
> programmatically configuring log4j appenders.
> * Limitations of the Log4j 1.x bridge*
>  # *They must not programmatically configure Log4j.*
>  
> In our application, we have a requirement where we need to add many 
> FileAppender programmatically with various log threshold values.
>  
> Hoping to get this feature supported in future versions for log4j1.x bridge.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3019) HtmlLayoutTest.testLayoutWithDatePatternFixedFormat test fails on windows

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507668#comment-17507668
 ] 

Gary D. Gregory commented on LOG4J2-3019:
-

[~LKleeven] and all,

Please verify the release-2,x branch builds for you and close this ticket 
builds for you.

TY!

> HtmlLayoutTest.testLayoutWithDatePatternFixedFormat test fails on windows
> -
>
> Key: LOG4J2-3019
> URL: https://issues.apache.org/jira/browse/LOG4J2-3019
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.14.0
> Environment: OS: Windows 10 Enterprise 
> Version: 20H2
> OS Build: 19042.746
> Experience: Windows Feature Experience Pack 120.2212.551.0
> java version "1.8.0_192"
> Java(TM) SE Runtime Environment (build 1.8.0_192-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.192-b12, mixed mode)
>Reporter: Luc Kleeven
>Assignee: Volkan Yazici
>Priority: Minor
> Fix For: 2.17.3
>
>
> When running a './mvnw verify' on the 'release-2.x' branche, last commit id 
> '9788f33fc62b3b4012489a603772433d3440e6b0'. The following test fails:
> {code:java}
> [ERROR]   
> HtmlLayoutTest.testLayoutWithDatePatternFixedFormat:242->testLayoutWithDatePatternFixedFormat:273
>  Incorrect date=02 Nov 2012 21:34:02,123, format=DATE, 
> timezone=GMT+8 ==> expected: <02 nov 2012 21:34:02,123> but was: 
> <02 Nov 2012 21:34:02,123> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (LOG4J2-3019) HtmlLayoutTest.testLayoutWithDatePatternFixedFormat test fails on windows

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory resolved LOG4J2-3019.
-
Fix Version/s: 2.17.3
   Resolution: Fixed

> HtmlLayoutTest.testLayoutWithDatePatternFixedFormat test fails on windows
> -
>
> Key: LOG4J2-3019
> URL: https://issues.apache.org/jira/browse/LOG4J2-3019
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.14.0
> Environment: OS: Windows 10 Enterprise 
> Version: 20H2
> OS Build: 19042.746
> Experience: Windows Feature Experience Pack 120.2212.551.0
> java version "1.8.0_192"
> Java(TM) SE Runtime Environment (build 1.8.0_192-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.192-b12, mixed mode)
>Reporter: Luc Kleeven
>Assignee: Volkan Yazici
>Priority: Minor
> Fix For: 2.17.3
>
>
> When running a './mvnw verify' on the 'release-2.x' branche, last commit id 
> '9788f33fc62b3b4012489a603772433d3440e6b0'. The following test fails:
> {code:java}
> [ERROR]   
> HtmlLayoutTest.testLayoutWithDatePatternFixedFormat:242->testLayoutWithDatePatternFixedFormat:273
>  Incorrect date=02 Nov 2012 21:34:02,123, format=DATE, 
> timezone=GMT+8 ==> expected: <02 nov 2012 21:34:02,123> but was: 
> <02 Nov 2012 21:34:02,123> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3437) Log4j 1.x bridge Request to support programmatically configuring Log4j.

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507506#comment-17507506
 ] 

Gary D. Gregory commented on LOG4J2-3437:
-

Hi [~PoojaTheCoder] 

Would you provide an example program to show which APIs you use?

> Log4j 1.x bridge Request to support programmatically configuring Log4j.
> ---
>
> Key: LOG4J2-3437
> URL: https://issues.apache.org/jira/browse/LOG4J2-3437
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
>
> As per log4j migration documentation 
> ([https://logging.apache.org/log4j/2.x/manual/migration.html),|https://logging.apache.org/log4j/2.x/manual/migration.html)]
>  I understand that currently log4j 1.x bridge 2.17.2 doesn't support 
> programmatically configuring log4j appenders.
> * Limitations of the Log4j 1.x bridge*
>  # *They must not programmatically configure Log4j.*
>  
> In our application, we have a requirement where we need to add many 
> FileAppender programmatically with various log threshold values.
>  
> Hoping to get this feature supported in future versions for log4j1.x bridge.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (LOG4J2-3432) RollingFileAppender fails after 100 backup cycles if filePattern contains "%04i" .

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17506867#comment-17506867
 ] 

Gary D. Gregory edited comment on LOG4J2-3432 at 3/15/22, 11:48 AM:


My POV is different obviously: if there is anything for us to fix, it would be 
for the next release, so we would debug the current code or at worse the 
current released code tag. This due to the fact that we would not release a 
maintenance version "in between" older versions (Log4Shell was a kind of an 
exception), IOW we would not release a 2.17.1.1, instead we would put a fix in 
the next release, currently labeled 2.17.3. So to me it makes the most sense to 
have a bug or behavior confirmed on the most recent release because it has the 
least amount of cumulative difference with the current git code and the least 
chance for possible side effects. This goes along with my time management as a 
volunteer here, waste little of my time, ask users to share in the work, we all 
benefit.


was (Author: garydgregory):
My POV is different obviously: if there is anything for us to fix, it would be 
for the next release, so we would debug the current code or at worse the 
current released code tag. This due to the fact that we would not release a 
maintenance version "in between" older versions (Log4Shell was a kind of an 
exception), IOW we would not release a 2.17.1.1, instead we would put a fix in 
the next release, currently labeled 2.17.3. So to me it makes the most sense to 
have a bug or behavior confirmed on the most recent release because it has the 
least amount of cumulative difference with the current git code and the least 
chance for possible side effects. This goes along with my time management as a 
volunteer here, waste little of my time, ask users to share in the word, we all 
benefit.

> RollingFileAppender fails after 100 backup cycles if filePattern contains 
> "%04i" .
> --
>
> Key: LOG4J2-3432
> URL: https://issues.apache.org/jira/browse/LOG4J2-3432
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.17.1, 2.17.2
> Environment: * Red Hat Enterprise Linux Server release 6.10 (Santiago)
>  * java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
>  * 301873 Mar  9 07:53 log4j-api-2.17.1.jar
> 1790452 Mar  9 07:53 log4j-core-2.17.1.jar
>  
>Reporter: Carl Smotricz
>Assignee: Ralph Goers
>Priority: Major
> Attachments: Main.java, log4j2.xml, runit.sh
>
>
> If a {{%i}} formatter in a filePattern includes a width specifier, e.g. "%4i" 
> or "%04i", file renaming fails after a certain fixed number of cycles. After 
> that, successive backups are renamed to the maximum cycle number and 
> overwrite previous files of that same cycle number, regardless of min and max 
> settings on the appender. Here are some failure modes I've found by testing:
>  * if {{filePattern}} contains {{{}%06i{}}}, cycling breaks after 100.
>  * if {{filePattern}} contains {{{}%006i{}}}, it breaks after 100 also.
>  * if {{filePattern}} contains {{{}%6i{}}}, it breaks after 10.
>  * if {{filePattern}} contains {{%06i}} and 
> {{{}DefaultRolloverStrategy.min{}}}=1, {{{}max{}}}=9, it breaks after 
> just 1.
> Now, the doc doesn't mention the %i spec supporting width and leading zero 
> modifiers in the manner of printf() or String.format() . Yet, those 
> variations (which I think other users will also be tempted to try) work - 
> until they don't. So apparently width and padding on that spec are 
> implemented but buggy.
> The doc for RollingRandomAccessFileAppender explicitly recommends these 
> format modifiers:
> {quote}... and/or a %i which represents an integer counter. The integer 
> counter allows specifying a padding, like %3i for space-padding the counter 
> to 3 digits or (usually more useful) %03i for zero-padding the counter to 3 
> digits.
> {quote}
> ...but I haven't verified that the problem occurs with that appender as well.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (LOG4J2-3432) RollingFileAppender fails after 100 backup cycles if filePattern contains "%04i" .

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17506867#comment-17506867
 ] 

Gary D. Gregory edited comment on LOG4J2-3432 at 3/15/22, 11:48 AM:


My POV is different obviously: if there is anything for us to fix, it would be 
for the next release, so we would debug the current code or at worse the 
current released code tag. This due to the fact that we would not release a 
maintenance version "in between" older versions (Log4Shell was a kind of an 
exception), IOW we would not release a 2.17.1.1, instead we would put a fix in 
the next release, currently labeled 2.17.3. So to me it makes the most sense to 
have a bug or behavior confirmed on the most recent release because it has the 
least amount of cumulative difference with the current git code and the least 
chance for possible side effects. This goes along with my time management as a 
volunteer here, waste little of my time, ask users to share in the word, we all 
benefit.


was (Author: garydgregory):
My POV is different obviously: if there is anything for us to fix, it would be 
for the next release, so we would debug the current code or at worse the 
current released code tag. This due to the fact that we would not release a 
maintenance version "in between" older versions (Log4Shell was a kind of an 
exception), IOW we would not release a 2.17.0.1, instead we would put a fix in 
the next release, currently labeled 2.17.3. So to me it makes the most sense to 
have a big or behavior confirmed on the most recent release because it has the 
least amount of cumulative difference with the current git code and the least 
chance for possible side effects. This goes along with my time management as a 
volunteer here, waste little of my time, ask users to share in the word, we all 
benefit.

> RollingFileAppender fails after 100 backup cycles if filePattern contains 
> "%04i" .
> --
>
> Key: LOG4J2-3432
> URL: https://issues.apache.org/jira/browse/LOG4J2-3432
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.17.1, 2.17.2
> Environment: * Red Hat Enterprise Linux Server release 6.10 (Santiago)
>  * java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
>  * 301873 Mar  9 07:53 log4j-api-2.17.1.jar
> 1790452 Mar  9 07:53 log4j-core-2.17.1.jar
>  
>Reporter: Carl Smotricz
>Assignee: Ralph Goers
>Priority: Major
> Attachments: Main.java, log4j2.xml, runit.sh
>
>
> If a {{%i}} formatter in a filePattern includes a width specifier, e.g. "%4i" 
> or "%04i", file renaming fails after a certain fixed number of cycles. After 
> that, successive backups are renamed to the maximum cycle number and 
> overwrite previous files of that same cycle number, regardless of min and max 
> settings on the appender. Here are some failure modes I've found by testing:
>  * if {{filePattern}} contains {{{}%06i{}}}, cycling breaks after 100.
>  * if {{filePattern}} contains {{{}%006i{}}}, it breaks after 100 also.
>  * if {{filePattern}} contains {{{}%6i{}}}, it breaks after 10.
>  * if {{filePattern}} contains {{%06i}} and 
> {{{}DefaultRolloverStrategy.min{}}}=1, {{{}max{}}}=9, it breaks after 
> just 1.
> Now, the doc doesn't mention the %i spec supporting width and leading zero 
> modifiers in the manner of printf() or String.format() . Yet, those 
> variations (which I think other users will also be tempted to try) work - 
> until they don't. So apparently width and padding on that spec are 
> implemented but buggy.
> The doc for RollingRandomAccessFileAppender explicitly recommends these 
> format modifiers:
> {quote}... and/or a %i which represents an integer counter. The integer 
> counter allows specifying a padding, like %3i for space-padding the counter 
> to 3 digits or (usually more useful) %03i for zero-padding the counter to 3 
> digits.
> {quote}
> ...but I haven't verified that the problem occurs with that appender as well.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3432) RollingFileAppender fails after 100 backup cycles if filePattern contains "%04i" .

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17506867#comment-17506867
 ] 

Gary D. Gregory commented on LOG4J2-3432:
-

My POV is different obviously: if there is anything for us to fix, it would be 
for the next release, so we would debug the current code or at worse the 
current released code tag. This due to the fact that we would not release a 
maintenance version "in between" older versions (Log4Shell was a kind of an 
exception), IOW we would not release a 2.17.0.1, instead we would put a fix in 
the next release, currently labeled 2.17.3. So to me it makes the most sense to 
have a big or behavior confirmed on the most recent release because it has the 
least amount of cumulative difference with the current git code and the least 
chance for possible side effects. This goes along with my time management as a 
volunteer here, waste little of my time, ask users to share in the word, we all 
benefit.

> RollingFileAppender fails after 100 backup cycles if filePattern contains 
> "%04i" .
> --
>
> Key: LOG4J2-3432
> URL: https://issues.apache.org/jira/browse/LOG4J2-3432
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.17.1, 2.17.2
> Environment: * Red Hat Enterprise Linux Server release 6.10 (Santiago)
>  * java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
>  * 301873 Mar  9 07:53 log4j-api-2.17.1.jar
> 1790452 Mar  9 07:53 log4j-core-2.17.1.jar
>  
>Reporter: Carl Smotricz
>Assignee: Ralph Goers
>Priority: Major
> Attachments: Main.java, log4j2.xml, runit.sh
>
>
> If a {{%i}} formatter in a filePattern includes a width specifier, e.g. "%4i" 
> or "%04i", file renaming fails after a certain fixed number of cycles. After 
> that, successive backups are renamed to the maximum cycle number and 
> overwrite previous files of that same cycle number, regardless of min and max 
> settings on the appender. Here are some failure modes I've found by testing:
>  * if {{filePattern}} contains {{{}%06i{}}}, cycling breaks after 100.
>  * if {{filePattern}} contains {{{}%006i{}}}, it breaks after 100 also.
>  * if {{filePattern}} contains {{{}%6i{}}}, it breaks after 10.
>  * if {{filePattern}} contains {{%06i}} and 
> {{{}DefaultRolloverStrategy.min{}}}=1, {{{}max{}}}=9, it breaks after 
> just 1.
> Now, the doc doesn't mention the %i spec supporting width and leading zero 
> modifiers in the manner of printf() or String.format() . Yet, those 
> variations (which I think other users will also be tempted to try) work - 
> until they don't. So apparently width and padding on that spec are 
> implemented but buggy.
> The doc for RollingRandomAccessFileAppender explicitly recommends these 
> format modifiers:
> {quote}... and/or a %i which represents an integer counter. The integer 
> counter allows specifying a padding, like %3i for space-padding the counter 
> to 3 digits or (usually more useful) %03i for zero-padding the counter to 3 
> digits.
> {quote}
> ...but I haven't verified that the problem occurs with that appender as well.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3432) RollingFileAppender fails after 100 backup cycles if filePattern contains "%04i" .

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17506621#comment-17506621
 ] 

Gary D. Gregory commented on LOG4J2-3432:
-

I asked because the current version should be the baseline for fixing bugs or 
improving documentation.

> RollingFileAppender fails after 100 backup cycles if filePattern contains 
> "%04i" .
> --
>
> Key: LOG4J2-3432
> URL: https://issues.apache.org/jira/browse/LOG4J2-3432
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.17.1, 2.17.2
> Environment: * Red Hat Enterprise Linux Server release 6.10 (Santiago)
>  * java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
>  * 301873 Mar  9 07:53 log4j-api-2.17.1.jar
> 1790452 Mar  9 07:53 log4j-core-2.17.1.jar
>  
>Reporter: Carl Smotricz
>Assignee: Ralph Goers
>Priority: Major
> Attachments: Main.java, log4j2.xml, runit.sh
>
>
> If a {{%i}} formatter in a filePattern includes a width specifier, e.g. "%4i" 
> or "%04i", file renaming fails after a certain fixed number of cycles. After 
> that, successive backups are renamed to the maximum cycle number and 
> overwrite previous files of that same cycle number, regardless of min and max 
> settings on the appender. Here are some failure modes I've found by testing:
>  * if {{filePattern}} contains {{{}%06i{}}}, cycling breaks after 100.
>  * if {{filePattern}} contains {{{}%006i{}}}, it breaks after 100 also.
>  * if {{filePattern}} contains {{{}%6i{}}}, it breaks after 10.
>  * if {{filePattern}} contains {{%06i}} and 
> {{{}DefaultRolloverStrategy.min{}}}=1, {{{}max{}}}=9, it breaks after 
> just 1.
> Now, the doc doesn't mention the %i spec supporting width and leading zero 
> modifiers in the manner of printf() or String.format() . Yet, those 
> variations (which I think other users will also be tempted to try) work - 
> until they don't. So apparently width and padding on that spec are 
> implemented but buggy.
> The doc for RollingRandomAccessFileAppender explicitly recommends these 
> format modifiers:
> {quote}... and/or a %i which represents an integer counter. The integer 
> counter allows specifying a padding, like %3i for space-padding the counter 
> to 3 digits or (usually more useful) %03i for zero-padding the counter to 3 
> digits.
> {quote}
> ...but I haven't verified that the problem occurs with that appender as well.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3432) RollingFileAppender fails after 100 backup cycles if filePattern contains "%04i" .

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505921#comment-17505921
 ] 

Gary D. Gregory commented on LOG4J2-3432:
-

Hello [~CarlSmotricz] 

Thank you for your report. 

Would you check to see if this still happens with 2.17.2?

TY.

> RollingFileAppender fails after 100 backup cycles if filePattern contains 
> "%04i" .
> --
>
> Key: LOG4J2-3432
> URL: https://issues.apache.org/jira/browse/LOG4J2-3432
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.17.1
> Environment: * Red Hat Enterprise Linux Server release 6.10 (Santiago)
>  * java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
>  * 301873 Mar  9 07:53 log4j-api-2.17.1.jar
> 1790452 Mar  9 07:53 log4j-core-2.17.1.jar
>  
>Reporter: Carl Smotricz
>Priority: Major
> Attachments: Main.java, log4j2.xml, runit.sh
>
>
> If a {{%i}} formatter in a filePattern includes a width specifier, e.g. "%4i" 
> or "%04i", file renaming fails after a certain fixed number of cycles. After 
> that, successive backups are renamed to the maximum cycle number and 
> overwrite previous files of that same cycle number, regardless of min and max 
> settings on the appender. Here are some failure modes I've found by testing:
>  * if {{filePattern}} contains {{{}%06i{}}}, cycling breaks after 100.
>  * if {{filePattern}} contains {{{}%006i{}}}, it breaks after 100 also.
>  * if {{filePattern}} contains {{{}%6i{}}}, it breaks after 10.
>  * if {{filePattern}} contains {{%06i}} and 
> {{{}DefaultRolloverStrategy.min{}}}=1, {{{}max{}}}=9, it breaks after 
> just 1.
> Now, the doc doesn't mention the %i spec supporting width and leading zero 
> modifiers in the manner of printf() or String.format() . Yet, those 
> variations (which I think other users will also be tempted to try) work - 
> until they don't. So apparently width and padding on that spec are 
> implemented but buggy.
> The doc for RollingRandomAccessFileAppender explicitly recommends these 
> format modifiers:
> {quote}... and/or a %i which represents an integer counter. The integer 
> counter allows specifying a padding, like %3i for space-padding the counter 
> to 3 digits or (usually more useful) %03i for zero-padding the counter to 3 
> digits.
> {quote}
> ...but I haven't verified that the problem occurs with that appender as well.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (LOG4J2-3423) JAR file containing Log4j configuration isn't closed

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory resolved LOG4J2-3423.
-
Resolution: Fixed

> JAR file containing Log4j configuration isn't closed
> 
>
> Key: LOG4J2-3423
> URL: https://issues.apache.org/jira/browse/LOG4J2-3423
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.14.0
> Environment: Windows
>Reporter: Radim Tlusty
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.3
>
>
> If the Log4j configuration file is inside of a JAR file, then the JAR file 
> (which is backed by the {{JarURLConnection}} retrieved from 
> {{{}URL.openConnection{}}}) isn't closed.
> This causes problems on Tomcat running on Windows during undeploying of an 
> application, because the opened JAR file can't be deleted.
> The problem was introduced during implementation of LOG4J2-2901 (version 
> 2.14.0), where the {{URL.openStream}} was replaced by {{URL.openConnection}} 
> in the class {{{}org.apache.logging.log4j.core.config.ConfigurationSource{}}}.
> The proposed solution (https://github.com/apache/logging-log4j2/pull/780) is 
> to use the {{URL.openConnection}} only when needed (~ configuration URL has 
> HTTPS protocol), otherwise similar code as in previous versions (<= 2.13.3) 
> would be used.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3431) log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and all messages are written into log files

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505376#comment-17505376
 ] 

Gary D. Gregory commented on LOG4J2-3431:
-

[~TukeshK] 

Note the solution in [https://github.com/apache/logging-log4j2/pull/789]

Will that work for your use case? 

> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and 
> all messages are written into log files
> -
>
> Key: LOG4J2-3431
> URL: https://issues.apache.org/jira/browse/LOG4J2-3431
> Project: Log4j 2
>  Issue Type: Bug
> Environment: JDK 1.8
>  
> -Dlog4j1.compatibility=true 
>  # log4j-1.2-api-2.17.2.jar
>  # log4j-api-2.17.2.jar
>  # log4j-core-2.17.2.jar
>  
>  
>Reporter: Tukesh
>Assignee: Piotr Karwasz
>Priority: Major
>
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and 
> all messages are written into log files
>  
> {code:java}
> // demo code
> package test.logger;import org.apache.log4j.Logger;  
> import org.apache.log4j.helpers.UtilLoggingLevel;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{    
>     System.out.println("I'm running...");
> while(true){
>             System.out.println("I'm running...");           
>             
>             log.info("Log4j-shell this is a info message");
>             
>             log.log(UtilLoggingLevel.INFO,"INFO");
>             log.log(UtilLoggingLevel.FINE,"FINE");
>             log.log(UtilLoggingLevel.FINER,"FINER");            
>             log.log(UtilLoggingLevel.FINEST,"FINEST");
>             log.log(UtilLoggingLevel.CONFIG,"CONIG");          
>             
>             try {
>                 TimeUnit.MILLISECONDS.sleep(1000);
>             } catch (InterruptedException e) {
>                 e.printStackTrace();
>             }
>         }  
>     }  
> }   {code}
> {code:java}
> log4j.rootLogger=FINE#org.apache.log4j.helpers.UtilLoggingLevel,DMCC_TRACE_LOGGER
>  
> log4j.appender.DMCC_TRACE_LOGGER.Threshold=FINE#org.apache.log4j.helpers.UtilLoggingLevel
> log4j.appender.DMCC_TRACE_LOGGER=org.apache.log4j.RollingFileAppender 
> log4j.appender.DMCC_TRACE_LOGGER.File=Dmcc-trace.log 
> log4j.appender.DMCC_TRACE_LOGGER.Append=true 
> log4j.appender.DMCC_TRACE_LOGGER.layout=org.apache.log4j.PatternLayout 
> log4j.appender.DMCC_TRACE_LOGGER.layout.ConversionPattern=%d 
> DmccMain[%X{PID}] :%t: %c %-4p - %m%n 
> log4j.appender.DMCC_TRACE_LOGGER.maxFileSize=10MB 
> log4j.appender.DMCC_TRACE_LOGGER.maxBackupIndex=20
> {code}
>  
>  
> +*Investigation :-*+ 
> convertLevel function from OptionConverter.java doesn't consider 
> UtilLoggingLevel level for mapping. so it sets Level as DEBUG for 
> UtilLoggingLevel classes. 
> {code:java}
> // code placeholder
> final org.apache.logging.log4j.Level level = levelStr == null ? 
> org.apache.logging.log4j.Level.ERROR : 
> OptionConverter.convertLevel(levelStr, org.apache.logging.log4j.Level.DEBUG);
>              loggerConfig.setLevel(level);
>              LOGGER.debug("Logger {} level set to {}", loggerName, level);    
>          
>  
> OptionConverter.java :-
>   public static  org.apache.logging.log4j.Level convertLevel(final Level 
> level) {
>         if (level == null) {
>             return org.apache.logging.log4j.Level.ERROR;
>         }
>         if (level.isGreaterOrEqual(Level.FATAL)) {
>             return org.apache.logging.log4j.Level.FATAL;
>         } else if (level.isGreaterOrEqual(Level.ERROR)) {
>             return org.apache.logging.log4j.Level.ERROR;
>         } else if (level.isGreaterOrEqual(Level.WARN)) {
>             return org.apache.logging.log4j.Level.WARN;
>         } else if (level.isGreaterOrEqual(Level.INFO)) {
>             return org.apache.logging.log4j.Level.INFO;
>         } else if (level.isGreaterOrEqual(Level.DEBUG)) {
>             return org.apache.logging.log4j.Level.DEBUG;
>         } else if (level.isGreaterOrEqual(Level.TRACE)) {
>             return org.apache.logging.log4j.Level.TRACE;
>         }
>         return org.apache.logging.log4j.Level.ALL;
>     }
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3431) log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and all messages are written into log files

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17505353#comment-17505353
 ] 

Gary D. Gregory commented on LOG4J2-3431:
-

[~TukeshK] See the previous comment and 

> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and 
> all messages are written into log files
> -
>
> Key: LOG4J2-3431
> URL: https://issues.apache.org/jira/browse/LOG4J2-3431
> Project: Log4j 2
>  Issue Type: Bug
> Environment: JDK 1.8
>  
> -Dlog4j1.compatibility=true 
>  # log4j-1.2-api-2.17.2.jar
>  # log4j-api-2.17.2.jar
>  # log4j-core-2.17.2.jar
>  
>  
>Reporter: Tukesh
>Assignee: Piotr Karwasz
>Priority: Major
>
> log4j bridge API :- Log message filtering based on UtilLoggingLevel fails and 
> all messages are written into log files
>  
> {code:java}
> // demo code
> package test.logger;import org.apache.log4j.Logger;  
> import org.apache.log4j.helpers.UtilLoggingLevel;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{    
>     System.out.println("I'm running...");
> while(true){
>             System.out.println("I'm running...");           
>             
>             log.info("Log4j-shell this is a info message");
>             
>             log.log(UtilLoggingLevel.INFO,"INFO");
>             log.log(UtilLoggingLevel.FINE,"FINE");
>             log.log(UtilLoggingLevel.FINER,"FINER");            
>             log.log(UtilLoggingLevel.FINEST,"FINEST");
>             log.log(UtilLoggingLevel.CONFIG,"CONIG");          
>             
>             try {
>                 TimeUnit.MILLISECONDS.sleep(1000);
>             } catch (InterruptedException e) {
>                 e.printStackTrace();
>             }
>         }  
>     }  
> }   {code}
> {code:java}
> log4j.rootLogger=FINE#org.apache.log4j.helpers.UtilLoggingLevel,DMCC_TRACE_LOGGER
>  
> log4j.appender.DMCC_TRACE_LOGGER.Threshold=FINE#org.apache.log4j.helpers.UtilLoggingLevel
> log4j.appender.DMCC_TRACE_LOGGER=org.apache.log4j.RollingFileAppender 
> log4j.appender.DMCC_TRACE_LOGGER.File=Dmcc-trace.log 
> log4j.appender.DMCC_TRACE_LOGGER.Append=true 
> log4j.appender.DMCC_TRACE_LOGGER.layout=org.apache.log4j.PatternLayout 
> log4j.appender.DMCC_TRACE_LOGGER.layout.ConversionPattern=%d 
> DmccMain[%X{PID}] :%t: %c %-4p - %m%n 
> log4j.appender.DMCC_TRACE_LOGGER.maxFileSize=10MB 
> log4j.appender.DMCC_TRACE_LOGGER.maxBackupIndex=20
> {code}
>  
>  
> +*Investigation :-*+ 
> convertLevel function from OptionConverter.java doesn't consider 
> UtilLoggingLevel level for mapping. so it sets Level as DEBUG for 
> UtilLoggingLevel classes. 
> {code:java}
> // code placeholder
> final org.apache.logging.log4j.Level level = levelStr == null ? 
> org.apache.logging.log4j.Level.ERROR : 
> OptionConverter.convertLevel(levelStr, org.apache.logging.log4j.Level.DEBUG);
>              loggerConfig.setLevel(level);
>              LOGGER.debug("Logger {} level set to {}", loggerName, level);    
>          
>  
> OptionConverter.java :-
>   public static  org.apache.logging.log4j.Level convertLevel(final Level 
> level) {
>         if (level == null) {
>             return org.apache.logging.log4j.Level.ERROR;
>         }
>         if (level.isGreaterOrEqual(Level.FATAL)) {
>             return org.apache.logging.log4j.Level.FATAL;
>         } else if (level.isGreaterOrEqual(Level.ERROR)) {
>             return org.apache.logging.log4j.Level.ERROR;
>         } else if (level.isGreaterOrEqual(Level.WARN)) {
>             return org.apache.logging.log4j.Level.WARN;
>         } else if (level.isGreaterOrEqual(Level.INFO)) {
>             return org.apache.logging.log4j.Level.INFO;
>         } else if (level.isGreaterOrEqual(Level.DEBUG)) {
>             return org.apache.logging.log4j.Level.DEBUG;
>         } else if (level.isGreaterOrEqual(Level.TRACE)) {
>             return org.apache.logging.log4j.Level.TRACE;
>         }
>         return org.apache.logging.log4j.Level.ALL;
>     }
>  {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (LOG4J2-3428) Update 3rd party dependencies for 2.17.3

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LOG4J2-3428:

Description: 
This ticket should only be closed when we release 2.17.3.

The updated dependencies are:

* com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2
* com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2
* com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2
* com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2
* com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2
* com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> 2.13.2
* com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre
* de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3
* org.awaitility:awaitility 4.1.1 -> 4.2.0
* org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10
* org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10
* org.springframework:spring-aop 5.3.15 -> 5.3.16
* org.springframework:spring-beans 5.3.15 -> 5.3.16
* org.springframework:spring-context 5.3.15 -> 5.3.16
* org.springframework:spring-context-support 5.3.15 -> 5.3.16
* org.springframework:spring-core 5.3.15 -> 5.3.16
* org.springframework:spring-expression 5.3.15 -> 5.3.16
* org.springframework:spring-oxm 5.3.15 -> 5.3.16
* org.springframework:spring-test 5.3.15 -> 5.3.16
* org.springframework:spring-web 5.3.15 -> 5.3.16
* org.springframework:spring-webmvc 5.3.15 -> 5.3.16
* Bump org.mockito:mockito-core from 4.3.1 to 4.4.0
* Bump org.mockito:mockito-junit-jupiter from 4.3.1 to 4.4.0


  was:
This ticket should only be closed when we release 2.17.3.

The updated dependencies are:

* com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2
* com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2
* com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2
* com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2
* com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2
* com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> 2.13.2
* com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre
* de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3
* org.awaitility:awaitility 4.1.1 -> 4.2.0
* org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10
* org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10
* org.springframework:spring-aop 5.3.15 -> 5.3.16
* org.springframework:spring-beans 5.3.15 -> 5.3.16
* org.springframework:spring-context 5.3.15 -> 5.3.16
* org.springframework:spring-context-support 5.3.15 -> 5.3.16
* org.springframework:spring-core 5.3.15 -> 5.3.16
* org.springframework:spring-expression 5.3.15 -> 5.3.16
* org.springframework:spring-oxm 5.3.15 -> 5.3.16
* org.springframework:spring-test 5.3.15 -> 5.3.16
* org.springframework:spring-web 5.3.15 -> 5.3.16
* org.springframework:spring-webmvc 5.3.15 -> 5.3.16



> Update 3rd party dependencies for 2.17.3
> 
>
> Key: LOG4J2-3428
> URL: https://issues.apache.org/jira/browse/LOG4J2-3428
> Project: Log4j 2
>  Issue Type: Task
>  Components: Build
>Reporter: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.3
>
>
> This ticket should only be closed when we release 2.17.3.
> The updated dependencies are:
> * com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> 
> 2.13.2
> * com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre
> * de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3
> * org.awaitility:awaitility 4.1.1 -> 4.2.0
> * org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10
> * org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10
> * org.springframework:spring-aop 5.3.15 -> 5.3.16
> * org.springframework:spring-beans 5.3.15 -> 5.3.16
> * org.springframework:spring-context 5.3.15 -> 5.3.16
> * org.springframework:spring-context-support 5.3.15 -> 5.3.16
> * org.springframework:spring-core 5.3.15 -> 5.3.16
> * org.springframework:spring-expression 5.3.15 -> 5.3.16
> * org.springframework:spring-oxm 5.3.15 -> 5.3.16
> * org.springframework:spring-test 5.3.15 -> 5.3.16
> * org.springframework:spring-web 5.3.15 -> 5.3.16
> * org.springframework:spring-webmvc 5.3.15 -> 5.3.16
> * Bump org.mockito:mockito-core from 4.3.1 to 4.4.0
> * Bump org.mockito:mockito-junit-jupiter from 4.3.1 to 4.4.0



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (LOG4J2-3428) Update 3rd party dependencies for 2.17.3

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LOG4J2-3428:

Description: 
This ticket should only be closed when we release 2.17.3.

The updated dependencies are:

* com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2
* com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2
* com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2
* com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2
* com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2
* com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> 2.13.2
* com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre
* de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3
* org.awaitility:awaitility 4.1.1 -> 4.2.0
* org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10
* org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10
* org.springframework:spring-aop 5.3.15 -> 5.3.16
* org.springframework:spring-beans 5.3.15 -> 5.3.16
* org.springframework:spring-context 5.3.15 -> 5.3.16
* org.springframework:spring-context-support 5.3.15 -> 5.3.16
* org.springframework:spring-core 5.3.15 -> 5.3.16
* org.springframework:spring-expression 5.3.15 -> 5.3.16
* org.springframework:spring-oxm 5.3.15 -> 5.3.16
* org.springframework:spring-test 5.3.15 -> 5.3.16
* org.springframework:spring-web 5.3.15 -> 5.3.16
* org.springframework:spring-webmvc 5.3.15 -> 5.3.16


  was:
The updated dependencies are:

* com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2
* com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2
* com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2
* com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2
* com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2
* com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> 2.13.2
* com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre
* de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3
* org.awaitility:awaitility 4.1.1 -> 4.2.0
* org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10
* org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10
* org.springframework:spring-aop 5.3.15 -> 5.3.16
* org.springframework:spring-beans 5.3.15 -> 5.3.16
* org.springframework:spring-context 5.3.15 -> 5.3.16
* org.springframework:spring-context-support 5.3.15 -> 5.3.16
* org.springframework:spring-core 5.3.15 -> 5.3.16
* org.springframework:spring-expression 5.3.15 -> 5.3.16
* org.springframework:spring-oxm 5.3.15 -> 5.3.16
* org.springframework:spring-test 5.3.15 -> 5.3.16
* org.springframework:spring-web 5.3.15 -> 5.3.16
* org.springframework:spring-webmvc 5.3.15 -> 5.3.16



> Update 3rd party dependencies for 2.17.3
> 
>
> Key: LOG4J2-3428
> URL: https://issues.apache.org/jira/browse/LOG4J2-3428
> Project: Log4j 2
>  Issue Type: Task
>  Components: Build
>Reporter: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.3
>
>
> This ticket should only be closed when we release 2.17.3.
> The updated dependencies are:
> * com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> 
> 2.13.2
> * com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre
> * de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3
> * org.awaitility:awaitility 4.1.1 -> 4.2.0
> * org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10
> * org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10
> * org.springframework:spring-aop 5.3.15 -> 5.3.16
> * org.springframework:spring-beans 5.3.15 -> 5.3.16
> * org.springframework:spring-context 5.3.15 -> 5.3.16
> * org.springframework:spring-context-support 5.3.15 -> 5.3.16
> * org.springframework:spring-core 5.3.15 -> 5.3.16
> * org.springframework:spring-expression 5.3.15 -> 5.3.16
> * org.springframework:spring-oxm 5.3.15 -> 5.3.16
> * org.springframework:spring-test 5.3.15 -> 5.3.16
> * org.springframework:spring-web 5.3.15 -> 5.3.16
> * org.springframework:spring-webmvc 5.3.15 -> 5.3.16



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (LOG4J2-3428) Update 3rd party dependencies for 2.17.3

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LOG4J2-3428:

Description: 
The updated dependencies are:

* com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2
* com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2
* com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2
* com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2
* com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2
* com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> 2.13.2
* com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre
* de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3
* org.awaitility:awaitility 4.1.1 -> 4.2.0
* org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10
* org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10
* org.springframework:spring-aop 5.3.15 -> 5.3.16
* org.springframework:spring-beans 5.3.15 -> 5.3.16
* org.springframework:spring-context 5.3.15 -> 5.3.16
* org.springframework:spring-context-support 5.3.15 -> 5.3.16
* org.springframework:spring-core 5.3.15 -> 5.3.16
* org.springframework:spring-expression 5.3.15 -> 5.3.16
* org.springframework:spring-oxm 5.3.15 -> 5.3.16
* org.springframework:spring-test 5.3.15 -> 5.3.16
* org.springframework:spring-web 5.3.15 -> 5.3.16
* org.springframework:spring-webmvc 5.3.15 -> 5.3.16


  was:
The updated dependencies are:
 * TODO


> Update 3rd party dependencies for 2.17.3
> 
>
> Key: LOG4J2-3428
> URL: https://issues.apache.org/jira/browse/LOG4J2-3428
> Project: Log4j 2
>  Issue Type: Task
>  Components: Build
>Reporter: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.3
>
>
> The updated dependencies are:
> * com.fasterxml.jackson.core:jackson-annotations 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.core:jackson-core 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.core:jackson-databind 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.dataformat:jackson-dataformat-xml 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.dataformat:jackson-dataformat-yaml 2.13.1 -> 2.13.2
> * com.fasterxml.jackson.module:jackson-module-jaxb-annotations 2.13.1 -> 
> 2.13.2
> * com.google.guava:guava-testlib 31.0.1-jre -> 31.1-jre
> * de.flapdoodle.embed:de.flapdoodle.embed.mongo 3.4.1 -> 3.4.3
> * org.awaitility:awaitility 4.1.1 -> 4.2.0
> * org.codehaus.groovy:groovy-dateutil 3.0.9 -> 3.0.10
> * org.codehaus.groovy:groovy-jsr223 3.0.9 -> 3.0.10
> * org.springframework:spring-aop 5.3.15 -> 5.3.16
> * org.springframework:spring-beans 5.3.15 -> 5.3.16
> * org.springframework:spring-context 5.3.15 -> 5.3.16
> * org.springframework:spring-context-support 5.3.15 -> 5.3.16
> * org.springframework:spring-core 5.3.15 -> 5.3.16
> * org.springframework:spring-expression 5.3.15 -> 5.3.16
> * org.springframework:spring-oxm 5.3.15 -> 5.3.16
> * org.springframework:spring-test 5.3.15 -> 5.3.16
> * org.springframework:spring-web 5.3.15 -> 5.3.16
> * org.springframework:spring-webmvc 5.3.15 -> 5.3.16



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (LOG4J2-3428) Update 3rd party dependencies for 2.17.3

[Gary D. Gregory (Jira)]

Gary D. Gregory created LOG4J2-3428:
---

 Summary: Update 3rd party dependencies for 2.17.3
 Key: LOG4J2-3428
 URL: https://issues.apache.org/jira/browse/LOG4J2-3428
 Project: Log4j 2
  Issue Type: Task
  Components: Build
Reporter: Gary D. Gregory
 Fix For: 2.17.3


The updated dependencies are:
 * TODO



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3425) Syslog appender lacks the SocketOptions setting

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502006#comment-17502006
 ] 

Gary D. Gregory commented on LOG4J2-3425:
-

I think we should close this ticket and open a new one titled something like 
"provide a socker appender using NIO"

> Syslog appender lacks the SocketOptions setting
> ---
>
> Key: LOG4J2-3425
> URL: https://issues.apache.org/jira/browse/LOG4J2-3425
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.12.1
>Reporter: Jiří Smolík
>Priority: Major
> Fix For: 2.17.3
>
>
> Recently, we've had an issue with our syslog server (collector), where it was 
> suddenly unable to forward messages sent to it. This resulted in flooding the 
> server and ultimately, exhausting its resources (memory and allocated 
> temporary storage).
> However, more interestingly, Log4j2 appender behaved as follows:
>  # At the moment of exhaustion, one thread (T1) entered the synchronized 
> block in TcpSocketManager (see 
> https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L217)
>  and tried to write the message (see 
> [https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L253]).
>  # The server didn't respond immediately - actually,  it blocked T1 for hours 
> (it was most likely waiting for resources to be free).
>  # In the meantime, all threads attempting to write a message to the syslog 
> appender hanged at the synchronized block (they were waiting for T1 to 
> finish).
> Eventually, the connection to the server broke apart or some resources were 
> freed, and T1 finished. Interestingly, it didn't throw any exception, but 
> that is beside the point in this issue.
> So, what happened is that the server got flooded and blocked one thread in 
> our application, but due to the way TcpSocketManager is implemented, our 
> application suffered a DoS.
> As a precaution to such dreadful scenario, I would like to request adding a 
> read timeout setting to the TcpSocketManager (also syslog appender), which 
> would in case of the above described situation prevent T1 from blocking other 
> threads for a long time. At least, that's my idea of an easy fix. Connect and 
> reconnect timeout settings have a different purpose and were useless in this 
> case.
> I am aware that the issue is also a matter of the syslog server 
> configuration, but application developers do not always have it under their 
> control.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3423) JAR file containing Log4j configuration isn't closed

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501038#comment-17501038
 ] 

Gary D. Gregory commented on LOG4J2-3423:
-

I wonder if there is a JDK bug for that or it is has been fixed in a newer 
version of Java.

> JAR file containing Log4j configuration isn't closed
> 
>
> Key: LOG4J2-3423
> URL: https://issues.apache.org/jira/browse/LOG4J2-3423
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.14.0
> Environment: Windows
>Reporter: Radim Tlusty
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.3
>
>
> If the Log4j configuration file is inside of a JAR file, then the JAR file 
> (which is backed by the {{JarURLConnection}} retrieved from 
> {{{}URL.openConnection{}}}) isn't closed.
> This causes problems on Tomcat running on Windows during undeploying of an 
> application, because the opened JAR file can't be deleted.
> The problem was introduced during implementation of LOG4J2-2901 (version 
> 2.14.0), where the {{URL.openStream}} was replaced by {{URL.openConnection}} 
> in the class {{{}org.apache.logging.log4j.core.config.ConfigurationSource{}}}.
> The proposed solution (https://github.com/apache/logging-log4j2/pull/780) is 
> to use the {{URL.openConnection}} only when needed (~ configuration URL has 
> HTTPS protocol), otherwise similar code as in previous versions (<= 2.13.3) 
> would be used.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3425) Syslog appender lacks the SocketOptions setting

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500951#comment-17500951
 ] 

Gary D. Gregory commented on LOG4J2-3425:
-

Hm, do we want a new {{SocketChannelAppender}} so we can keep 
{{SocketAppender}} for maximum compatibility or do we want to reimplement 
{{SocketAppender}} using channels?

> Syslog appender lacks the SocketOptions setting
> ---
>
> Key: LOG4J2-3425
> URL: https://issues.apache.org/jira/browse/LOG4J2-3425
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.12.1
>Reporter: Jiří Smolík
>Priority: Major
> Fix For: 2.17.3
>
>
> Recently, we've had an issue with our syslog server (collector), where it was 
> suddenly unable to forward messages sent to it. This resulted in flooding the 
> server and ultimately, exhausting its resources (memory and allocated 
> temporary storage).
> However, more interestingly, Log4j2 appender behaved as follows:
>  # At the moment of exhaustion, one thread (T1) entered the synchronized 
> block in TcpSocketManager (see 
> https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L217)
>  and tried to write the message (see 
> [https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L253]).
>  # The server didn't respond immediately - actually,  it blocked T1 for hours 
> (it was most likely waiting for resources to be free).
>  # In the meantime, all threads attempting to write a message to the syslog 
> appender hanged at the synchronized block (they were waiting for T1 to 
> finish).
> Eventually, the connection to the server broke apart or some resources were 
> freed, and T1 finished. Interestingly, it didn't throw any exception, but 
> that is beside the point in this issue.
> So, what happened is that the server got flooded and blocked one thread in 
> our application, but due to the way TcpSocketManager is implemented, our 
> application suffered a DoS.
> As a precaution to such dreadful scenario, I would like to request adding a 
> read timeout setting to the TcpSocketManager (also syslog appender), which 
> would in case of the above described situation prevent T1 from blocking other 
> threads for a long time. At least, that's my idea of an easy fix. Connect and 
> reconnect timeout settings have a different purpose and were useless in this 
> case.
> I am aware that the issue is also a matter of the syslog server 
> configuration, but application developers do not always have it under their 
> control.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (LOG4J2-3425) Syslog appender lacks the SocketOptions setting

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LOG4J2-3425:

External issue URL: 
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4031100

> Syslog appender lacks the SocketOptions setting
> ---
>
> Key: LOG4J2-3425
> URL: https://issues.apache.org/jira/browse/LOG4J2-3425
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.12.1
>Reporter: Jiří Smolík
>Priority: Major
> Fix For: 2.17.3
>
>
> Recently, we've had an issue with our syslog server (collector), where it was 
> suddenly unable to forward messages sent to it. This resulted in flooding the 
> server and ultimately, exhausting its resources (memory and allocated 
> temporary storage).
> However, more interestingly, Log4j2 appender behaved as follows:
>  # At the moment of exhaustion, one thread (T1) entered the synchronized 
> block in TcpSocketManager (see 
> https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L217)
>  and tried to write the message (see 
> [https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L253]).
>  # The server didn't respond immediately - actually,  it blocked T1 for hours 
> (it was most likely waiting for resources to be free).
>  # In the meantime, all threads attempting to write a message to the syslog 
> appender hanged at the synchronized block (they were waiting for T1 to 
> finish).
> Eventually, the connection to the server broke apart or some resources were 
> freed, and T1 finished. Interestingly, it didn't throw any exception, but 
> that is beside the point in this issue.
> So, what happened is that the server got flooded and blocked one thread in 
> our application, but due to the way TcpSocketManager is implemented, our 
> application suffered a DoS.
> As a precaution to such dreadful scenario, I would like to request adding a 
> read timeout setting to the TcpSocketManager (also syslog appender), which 
> would in case of the above described situation prevent T1 from blocking other 
> threads for a long time. At least, that's my idea of an easy fix. Connect and 
> reconnect timeout settings have a different purpose and were useless in this 
> case.
> I am aware that the issue is also a matter of the syslog server 
> configuration, but application developers do not always have it under their 
> control.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (LOG4J2-3425) Syslog appender lacks the SocketOptions setting

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LOG4J2-3425:

Summary: Syslog appender lacks the SocketOptions setting  (was: Syslog 
appender lacks the 'readTimeoutMillis' setting)

> Syslog appender lacks the SocketOptions setting
> ---
>
> Key: LOG4J2-3425
> URL: https://issues.apache.org/jira/browse/LOG4J2-3425
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.12.1
>Reporter: Jiří Smolík
>Priority: Major
>
> Recently, we've had an issue with our syslog server (collector), where it was 
> suddenly unable to forward messages sent to it. This resulted in flooding the 
> server and ultimately, exhausting its resources (memory and allocated 
> temporary storage).
> However, more interestingly, Log4j2 appender behaved as follows:
>  # At the moment of exhaustion, one thread (T1) entered the synchronized 
> block in TcpSocketManager (see 
> https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L217)
>  and tried to write the message (see 
> [https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L253]).
>  # The server didn't respond immediately - actually,  it blocked T1 for hours 
> (it was most likely waiting for resources to be free).
>  # In the meantime, all threads attempting to write a message to the syslog 
> appender hanged at the synchronized block (they were waiting for T1 to 
> finish).
> Eventually, the connection to the server broke apart or some resources were 
> freed, and T1 finished. Interestingly, it didn't throw any exception, but 
> that is beside the point in this issue.
> So, what happened is that the server got flooded and blocked one thread in 
> our application, but due to the way TcpSocketManager is implemented, our 
> application suffered a DoS.
> As a precaution to such dreadful scenario, I would like to request adding a 
> read timeout setting to the TcpSocketManager (also syslog appender), which 
> would in case of the above described situation prevent T1 from blocking other 
> threads for a long time. At least, that's my idea of an easy fix. Connect and 
> reconnect timeout settings have a different purpose and were useless in this 
> case.
> I am aware that the issue is also a matter of the syslog server 
> configuration, but application developers do not always have it under their 
> control.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (LOG4J2-3425) Syslog appender lacks the SocketOptions setting

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500899#comment-17500899
 ] 

Gary D. Gregory edited comment on LOG4J2-3425 at 3/3/22, 5:04 PM:
--

[~SkyCrawl] 

Dang it, well that's lame, sorry about that. I fixed this in the git branch 
{{release-2.x}} and our Maven snapshot repository 
[https://repository.apache.org/content/repositories/snapshots] for version 
*2.17.3-SNAPSHOT*

Please give it a try.

Note that I change the title of this ticket to reflect this change.


was (Author: garydgregory):
[~SkyCrawl] 

Dang it, well that's lame, sorry about that. I fixed this in the git branch 
{{release-2.x}} and our Maven snapshot repository 
https://repository.apache.org/content/repositories/snapshots for version 
*2.17.3-SNAPSHOT*

Please give it a try.

> Syslog appender lacks the SocketOptions setting
> ---
>
> Key: LOG4J2-3425
> URL: https://issues.apache.org/jira/browse/LOG4J2-3425
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.12.1
>Reporter: Jiří Smolík
>Priority: Major
> Fix For: 2.17.3
>
>
> Recently, we've had an issue with our syslog server (collector), where it was 
> suddenly unable to forward messages sent to it. This resulted in flooding the 
> server and ultimately, exhausting its resources (memory and allocated 
> temporary storage).
> However, more interestingly, Log4j2 appender behaved as follows:
>  # At the moment of exhaustion, one thread (T1) entered the synchronized 
> block in TcpSocketManager (see 
> https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L217)
>  and tried to write the message (see 
> [https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L253]).
>  # The server didn't respond immediately - actually,  it blocked T1 for hours 
> (it was most likely waiting for resources to be free).
>  # In the meantime, all threads attempting to write a message to the syslog 
> appender hanged at the synchronized block (they were waiting for T1 to 
> finish).
> Eventually, the connection to the server broke apart or some resources were 
> freed, and T1 finished. Interestingly, it didn't throw any exception, but 
> that is beside the point in this issue.
> So, what happened is that the server got flooded and blocked one thread in 
> our application, but due to the way TcpSocketManager is implemented, our 
> application suffered a DoS.
> As a precaution to such dreadful scenario, I would like to request adding a 
> read timeout setting to the TcpSocketManager (also syslog appender), which 
> would in case of the above described situation prevent T1 from blocking other 
> threads for a long time. At least, that's my idea of an easy fix. Connect and 
> reconnect timeout settings have a different purpose and were useless in this 
> case.
> I am aware that the issue is also a matter of the syslog server 
> configuration, but application developers do not always have it under their 
> control.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (LOG4J2-3425) Syslog appender lacks the SocketOptions setting

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory resolved LOG4J2-3425.
-
Fix Version/s: 2.17.3
   Resolution: Fixed

> Syslog appender lacks the SocketOptions setting
> ---
>
> Key: LOG4J2-3425
> URL: https://issues.apache.org/jira/browse/LOG4J2-3425
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.12.1
>Reporter: Jiří Smolík
>Priority: Major
> Fix For: 2.17.3
>
>
> Recently, we've had an issue with our syslog server (collector), where it was 
> suddenly unable to forward messages sent to it. This resulted in flooding the 
> server and ultimately, exhausting its resources (memory and allocated 
> temporary storage).
> However, more interestingly, Log4j2 appender behaved as follows:
>  # At the moment of exhaustion, one thread (T1) entered the synchronized 
> block in TcpSocketManager (see 
> https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L217)
>  and tried to write the message (see 
> [https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L253]).
>  # The server didn't respond immediately - actually,  it blocked T1 for hours 
> (it was most likely waiting for resources to be free).
>  # In the meantime, all threads attempting to write a message to the syslog 
> appender hanged at the synchronized block (they were waiting for T1 to 
> finish).
> Eventually, the connection to the server broke apart or some resources were 
> freed, and T1 finished. Interestingly, it didn't throw any exception, but 
> that is beside the point in this issue.
> So, what happened is that the server got flooded and blocked one thread in 
> our application, but due to the way TcpSocketManager is implemented, our 
> application suffered a DoS.
> As a precaution to such dreadful scenario, I would like to request adding a 
> read timeout setting to the TcpSocketManager (also syslog appender), which 
> would in case of the above described situation prevent T1 from blocking other 
> threads for a long time. At least, that's my idea of an easy fix. Connect and 
> reconnect timeout settings have a different purpose and were useless in this 
> case.
> I am aware that the issue is also a matter of the syslog server 
> configuration, but application developers do not always have it under their 
> control.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3425) Syslog appender lacks the SocketOptions setting

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500899#comment-17500899
 ] 

Gary D. Gregory commented on LOG4J2-3425:
-

[~SkyCrawl] 

Dang it, well that's lame, sorry about that. I fixed this in the git branch 
{{release-2.x}} and our Maven snapshot repository 
https://repository.apache.org/content/repositories/snapshots for version 
*2.17.3-SNAPSHOT*

Please give it a try.

> Syslog appender lacks the SocketOptions setting
> ---
>
> Key: LOG4J2-3425
> URL: https://issues.apache.org/jira/browse/LOG4J2-3425
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.12.1
>Reporter: Jiří Smolík
>Priority: Major
>
> Recently, we've had an issue with our syslog server (collector), where it was 
> suddenly unable to forward messages sent to it. This resulted in flooding the 
> server and ultimately, exhausting its resources (memory and allocated 
> temporary storage).
> However, more interestingly, Log4j2 appender behaved as follows:
>  # At the moment of exhaustion, one thread (T1) entered the synchronized 
> block in TcpSocketManager (see 
> https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L217)
>  and tried to write the message (see 
> [https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L253]).
>  # The server didn't respond immediately - actually,  it blocked T1 for hours 
> (it was most likely waiting for resources to be free).
>  # In the meantime, all threads attempting to write a message to the syslog 
> appender hanged at the synchronized block (they were waiting for T1 to 
> finish).
> Eventually, the connection to the server broke apart or some resources were 
> freed, and T1 finished. Interestingly, it didn't throw any exception, but 
> that is beside the point in this issue.
> So, what happened is that the server got flooded and blocked one thread in 
> our application, but due to the way TcpSocketManager is implemented, our 
> application suffered a DoS.
> As a precaution to such dreadful scenario, I would like to request adding a 
> read timeout setting to the TcpSocketManager (also syslog appender), which 
> would in case of the above described situation prevent T1 from blocking other 
> threads for a long time. At least, that's my idea of an easy fix. Connect and 
> reconnect timeout settings have a different purpose and were useless in this 
> case.
> I am aware that the issue is also a matter of the syslog server 
> configuration, but application developers do not always have it under their 
> control.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3424) JDBC Appender configuration properties not handled correctly after upgrading to 2.17.2

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500887#comment-17500887
 ] 

Gary D. Gregory commented on LOG4J2-3424:
-

[~ckozak] Any advice? It looks like raw value is from your commit 
17a77f5c27bda545de4b8eda46590401313e0be8

Overall, it looks like we might be missing a non-JDBC-specific unit test?

> JDBC Appender configuration properties not handled correctly after upgrading 
> to 2.17.2
> --
>
> Key: LOG4J2-3424
> URL: https://issues.apache.org/jira/browse/LOG4J2-3424
> Project: Log4j 2
>  Issue Type: Dependency upgrade
>  Components: Appenders, Configuration
>Affects Versions: 2.17.2
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> I'm a maintainer of Pax Logging project and for long time we had this 
> configuration in integration tests:
> {noformat}
> appender.jdbc.type = JDBC
> appender.jdbc.name = jdbc
> appender.jdbc.tableName = LOG
> appender.jdbc.connectionSource.type = DriverManager
> appender.jdbc.connectionSource.driverClassName = org.h2.Driver
> appender.jdbc.connectionSource.connectionString = 
> jdbc:h2:tcp://localhost:PORT/logsdb
> appender.jdbc.connectionSource.p1.type = property
> appender.jdbc.connectionSource.p1.name = SCHEMA
> appender.jdbc.connectionSource.p1.value = logs
> appender.jdbc.connectionSource.p2.type = property
> appender.jdbc.connectionSource.p2.name = QUERY_TIMEOUT
> appender.jdbc.connectionSource.p2.value = 5000
> appender.jdbc.connectionSource.p3.type = property
> appender.jdbc.connectionSource.p3.name = user
> appender.jdbc.connectionSource.p3.value = logadmin
> appender.jdbc.connectionSource.p4.type = property
> appender.jdbc.connectionSource.p4.name = password
> appender.jdbc.connectionSource.p4.value = logpassword
> appender.jdbc.c1.type = Column
> appender.jdbc.c1.name = DATE
> appender.jdbc.c1.isEventTimestamp = true
> appender.jdbc.c2.type = Column
> appender.jdbc.c2.name = LEVEL
> appender.jdbc.c2.pattern = %level
> appender.jdbc.c2.isUnicode = false
> appender.jdbc.c3.type = Column
> appender.jdbc.c3.name = SOURCE
> appender.jdbc.c3.pattern = %logger
> appender.jdbc.c3.isUnicode = false
> appender.jdbc.c4.type = Column
> appender.jdbc.c4.name = MESSAGE
> appender.jdbc.c4.pattern = %message
> appender.jdbc.c4.isUnicode = false
> rootLogger.level = info
> rootLogger.appenderRef.console.ref = console
> logger.my.name = my.logger
> logger.my.level = trace
> logger.my.additivity = false
> logger.my.appenderRef.jdbc.ref = jdbc
> {noformat}
> now the properties are not handled correctly. For example with:
> {noformat}
> appender.jdbc.connectionSource.p1.type = property
> appender.jdbc.connectionSource.p1.name = SCHEMA
> appender.jdbc.connectionSource.p1.value = logs
> {noformat}
> I'm getting (in 
> {{org.apache.logging.log4j.core.config.plugins.util.PluginBuilder#generateParameters()}}):
> {noformat}
> createProperty(name="SCHEMA", value="logs", value="null")
> {noformat}
> call and 
> {{org.apache.logging.log4j.core.config.Property#createProperty(java.lang.String,
>  java.lang.String, java.lang.String)}} is called with:
> * SCHEMA
> * logs
> * null
> values.
> In debug logs there's:
> {noformat}
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building 
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : 
> createProperty(name="password", value="logpassword", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building 
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : 
> createProperty(name="SCHEMA", value="logs", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building 
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : 
> createProperty(name="user", value="logadmin", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building 
> Plugin[name=property, class=org.apache.logging.log4j.core.config.Property].
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : 
> createProperty(name="QUERY_TIMEOUT", value="5000", value="null")
> org.ops4j.pax.logging.pax-logging-api [log4j2] DEBUG : Building 
> Plugin[name=connectionSource, 
> class=org.apache.logging.log4j.core.appender.db.jdbc.DriverManagerConnectionSource].
> {noformat}
> 2.17.2 introduced {{org.apache.logging.log4j.core.config.Property#rawValue}} 
> and my values are available under {{rawValue}} instead of {{value}} fields of 
> {{org.apache.logging.log4j.core.config.Property}} objects.
> Eventually 
> 

[jira] [Comment Edited] (LOG4J2-3423) JAR file containing Log4j configuration isn't closed

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500866#comment-17500866
 ] 

Gary D. Gregory edited comment on LOG4J2-3423 at 3/3/22, 4:48 PM:
--

Fixed in git branch {{release-2.x}} and Maven snapshot version 2.17.3 
repository [https://repository.apache.org/content/repositories/snapshots/]

[~rtlusty] Please give it a try and let us know.


was (Author: garydgregory):
Fixed in git branch {{release-2.x}} and Maven snapshot version 2.17.3 
repository https://repository.apache.org/content/repositories/snapshots/

> JAR file containing Log4j configuration isn't closed
> 
>
> Key: LOG4J2-3423
> URL: https://issues.apache.org/jira/browse/LOG4J2-3423
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.14.0
> Environment: Windows
>Reporter: Radim Tlusty
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.3
>
>
> If the Log4j configuration file is inside of a JAR file, then the JAR file 
> (which is backed by the {{JarURLConnection}} retrieved from 
> {{{}URL.openConnection{}}}) isn't closed.
> This causes problems on Tomcat running on Windows during undeploying of an 
> application, because the opened JAR file can't be deleted.
> The problem was introduced during implementation of LOG4J2-2901 (version 
> 2.14.0), where the {{URL.openStream}} was replaced by {{URL.openConnection}} 
> in the class {{{}org.apache.logging.log4j.core.config.ConfigurationSource{}}}.
> The proposed solution (https://github.com/apache/logging-log4j2/pull/780) is 
> to use the {{URL.openConnection}} only when needed (~ configuration URL has 
> HTTPS protocol), otherwise similar code as in previous versions (<= 2.13.3) 
> would be used.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (LOG4J2-3360) Document unsafe lookup usage patterns

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LOG4J2-3360:

Fix Version/s: 2.17.3
   (was: 2.17.2)

> Document unsafe lookup usage patterns
> -
>
> Key: LOG4J2-3360
> URL: https://issues.apache.org/jira/browse/LOG4J2-3360
> Project: Log4j 2
>  Issue Type: Improvement
>Reporter: Volkan Yazici
>Priority: Major
> Fix For: 2.17.3
>
>
> The recent CVE storm has proven that lookups are employed by users in many 
> places where they shouldn't. In particular, lookups depending on 
> {{LogEvent}}'s (e.g., {{ctx}}) are honey pots for attackers and there are 
> safer ways to expose the very same information via more native constructs, 
> e.g., MDC accessors in {{PatternLayout}} and {{JsonTemplateLayout}}. This 
> story aims to enrich the lookup and certain layout documentations with such 
> best practices.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (LOG4J2-3340) StatusLogger's log Level cannot be changed as advertised

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LOG4J2-3340:

Fix Version/s: 2.17.3
   (was: 2.17.2)

> StatusLogger's log Level cannot be changed as advertised
> 
>
> Key: LOG4J2-3340
> URL: https://issues.apache.org/jira/browse/LOG4J2-3340
> Project: Log4j 2
>  Issue Type: Bug
>Reporter: Michael Vorburger
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.3
>
>
> I would like to see the warn log from {{LogManager}} re. which implementation 
> it picked, if multiple.
> I would like to be able to do this without a system property but using a 
> properties file on the classpath.
> StatusLogger's JavaDoc (currently) says that "This can be overridden via a 
> system property named #DEFAULT_STATUS_LISTENER_LEVEL and will work with any 
> Log4j provider.", where DEFAULT_STATUS_LISTENER_LEVEL is 
> "log4j2.StatusLogger.level".
> However that currently doesn't seem to quite work as advertised. (If you 
> think it does, please suggest how.) I can see some stuff in StatusLogger 
> related to its default log level been (only?) for StatusListener and 
> StatusData? This seems confusing.
> I'll raise a PR with a proposed simple fix for this for your review.
> [~ckozak] / [~ggregory]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (LOG4J2-3423) JAR file containing Log4j configuration isn't closed

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory resolved LOG4J2-3423.
-
Fix Version/s: 2.17.3
   Resolution: Fixed

Fixed in git branch {{release-2.x}} and Maven snapshot version 2.17.3 
repository https://repository.apache.org/content/repositories/snapshots/

> JAR file containing Log4j configuration isn't closed
> 
>
> Key: LOG4J2-3423
> URL: https://issues.apache.org/jira/browse/LOG4J2-3423
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.14.0
> Environment: Windows
>Reporter: Radim Tlusty
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.3
>
>
> If the Log4j configuration file is inside of a JAR file, then the JAR file 
> (which is backed by the {{JarURLConnection}} retrieved from 
> {{{}URL.openConnection{}}}) isn't closed.
> This causes problems on Tomcat running on Windows during undeploying of an 
> application, because the opened JAR file can't be deleted.
> The problem was introduced during implementation of LOG4J2-2901 (version 
> 2.14.0), where the {{URL.openStream}} was replaced by {{URL.openConnection}} 
> in the class {{{}org.apache.logging.log4j.core.config.ConfigurationSource{}}}.
> The proposed solution (https://github.com/apache/logging-log4j2/pull/780) is 
> to use the {{URL.openConnection}} only when needed (~ configuration URL has 
> HTTPS protocol), otherwise similar code as in previous versions (<= 2.13.3) 
> would be used.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Work started] (LOG4J2-3423) JAR file containing Log4j configuration isn't closed

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on LOG4J2-3423 started by Gary D. Gregory.
---
> JAR file containing Log4j configuration isn't closed
> 
>
> Key: LOG4J2-3423
> URL: https://issues.apache.org/jira/browse/LOG4J2-3423
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.14.0
> Environment: Windows
>Reporter: Radim Tlusty
>Assignee: Gary D. Gregory
>Priority: Major
>
> If the Log4j configuration file is inside of a JAR file, then the JAR file 
> (which is backed by the {{JarURLConnection}} retrieved from 
> {{{}URL.openConnection{}}}) isn't closed.
> This causes problems on Tomcat running on Windows during undeploying of an 
> application, because the opened JAR file can't be deleted.
> The problem was introduced during implementation of LOG4J2-2901 (version 
> 2.14.0), where the {{URL.openStream}} was replaced by {{URL.openConnection}} 
> in the class {{{}org.apache.logging.log4j.core.config.ConfigurationSource{}}}.
> The proposed solution (https://github.com/apache/logging-log4j2/pull/780) is 
> to use the {{URL.openConnection}} only when needed (~ configuration URL has 
> HTTPS protocol), otherwise similar code as in previous versions (<= 2.13.3) 
> would be used.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (LOG4J2-3423) JAR file containing Log4j configuration isn't closed

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory reassigned LOG4J2-3423:
---

Assignee: Gary D. Gregory

> JAR file containing Log4j configuration isn't closed
> 
>
> Key: LOG4J2-3423
> URL: https://issues.apache.org/jira/browse/LOG4J2-3423
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.14.0
> Environment: Windows
>Reporter: Radim Tlusty
>Assignee: Gary D. Gregory
>Priority: Major
>
> If the Log4j configuration file is inside of a JAR file, then the JAR file 
> (which is backed by the {{JarURLConnection}} retrieved from 
> {{{}URL.openConnection{}}}) isn't closed.
> This causes problems on Tomcat running on Windows during undeploying of an 
> application, because the opened JAR file can't be deleted.
> The problem was introduced during implementation of LOG4J2-2901 (version 
> 2.14.0), where the {{URL.openStream}} was replaced by {{URL.openConnection}} 
> in the class {{{}org.apache.logging.log4j.core.config.ConfigurationSource{}}}.
> The proposed solution (https://github.com/apache/logging-log4j2/pull/780) is 
> to use the {{URL.openConnection}} only when needed (~ configuration URL has 
> HTTPS protocol), otherwise similar code as in previous versions (<= 2.13.3) 
> would be used.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (LOG4J2-3423) JAR file containing Log4j configuration isn't closed

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500693#comment-17500693
 ] 

Gary D. Gregory edited comment on LOG4J2-3423 at 3/3/22, 2:05 PM:
--

The URL connection's {{setUseCaches}} can be called with false to avoid caching 
the jar file.

I will test fixing {{org.apache.logging.log4j.core.net.UrlConnectionFactory}}...


was (Author: garydgregory):
The url connection's setUseCaches can be called with false to avoid caching the 
jar file.

> JAR file containing Log4j configuration isn't closed
> 
>
> Key: LOG4J2-3423
> URL: https://issues.apache.org/jira/browse/LOG4J2-3423
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.14.0
> Environment: Windows
>Reporter: Radim Tlusty
>Priority: Major
>
> If the Log4j configuration file is inside of a JAR file, then the JAR file 
> (which is backed by the {{JarURLConnection}} retrieved from 
> {{{}URL.openConnection{}}}) isn't closed.
> This causes problems on Tomcat running on Windows during undeploying of an 
> application, because the opened JAR file can't be deleted.
> The problem was introduced during implementation of LOG4J2-2901 (version 
> 2.14.0), where the {{URL.openStream}} was replaced by {{URL.openConnection}} 
> in the class {{{}org.apache.logging.log4j.core.config.ConfigurationSource{}}}.
> The proposed solution (https://github.com/apache/logging-log4j2/pull/780) is 
> to use the {{URL.openConnection}} only when needed (~ configuration URL has 
> HTTPS protocol), otherwise similar code as in previous versions (<= 2.13.3) 
> would be used.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (LOG4J2-3425) Syslog appender lacks the 'readTimeoutMillis' setting

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500747#comment-17500747
 ] 

Gary D. Gregory edited comment on LOG4J2-3425 at 3/3/22, 1:50 PM:
--

[~SkyCrawl] 

A Syslog Appender is a Socket Appender, so you can use a *SocketOptions* 
element, here is a Socket Appender example:
{code:xml}

  

  
  

  

  
  

  

  

{code}
Any setting on a *Socket* 
([https://docs.oracle.com/javase/8/docs/api/java/net/Socket.html]), can be 
configured through the *SocketOptions* 
([https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-core/src/main/java/org/apache/logging/log4j/core/net/SocketOptions.java]),
 excerpted here:
{code:xml}
  

  
{code}
It looks like I forgot to document it on the site.

Also, do not use 2.12.1, use at least 2.12.4 to address security issues 
documented here: https://logging.apache.org/log4j/2.x/security.html


was (Author: garydgregory):
[~SkyCrawl] 

A Syslog Appender is a Socket Appender, so you can use a *SocketOptions* 
element, here is a Socket Appender example:
{code:xml}

  

  
  

  

  
  

  

  

{code}
Any setting on a *Socket* 
([https://docs.oracle.com/javase/8/docs/api/java/net/Socket.html]), can be 
configured through the *SocketOptions* 
([https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-core/src/main/java/org/apache/logging/log4j/core/net/SocketOptions.java]),
 excerpted here:
{code:xml}
  

  
{code}
It looks like I forgot to document it on the site.

> Syslog appender lacks the 'readTimeoutMillis' setting
> -
>
> Key: LOG4J2-3425
> URL: https://issues.apache.org/jira/browse/LOG4J2-3425
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.12.1
>Reporter: Jiří Smolík
>Priority: Major
>
> Recently, we've had an issue with our syslog server (collector), where it was 
> suddenly unable to forward messages sent to it. This resulted in flooding the 
> server and ultimately, exhausting its resources (memory and allocated 
> temporary storage).
> However, more interestingly, Log4j2 appender behaved as follows:
>  # At the moment of exhaustion, one thread (T1) entered the synchronized 
> block in TcpSocketManager (see 
> https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L217)
>  and tried to write the message (see 
> [https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L253]).
>  # The server didn't respond immediately - actually,  it blocked T1 for hours 
> (it was most likely waiting for resources to be free).
>  # In the meantime, all threads attempting to write a message to the syslog 
> appender hanged at the synchronized block (they were waiting for T1 to 
> finish).
> Eventually, the connection to the server broke apart or some resources were 
> freed, and T1 finished. Interestingly, it didn't throw any exception, but 
> that is beside the point in this issue.
> So, what happened is that the server got flooded and blocked one thread in 
> our application, but due to the way TcpSocketManager is implemented, our 
> application suffered a DoS.
> As a precaution to such dreadful scenario, I would like to request adding a 
> read timeout setting to the TcpSocketManager (also syslog appender), which 
> would in case of the above described situation prevent T1 from blocking other 
> threads for a long time. At least, that's my idea of an easy fix. Connect and 
> reconnect timeout settings have a different purpose and were useless in this 
> case.
> I am aware that the issue is also a matter of the syslog server 
> configuration, but application developers do not always have it under their 
> control.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (LOG4J2-3425) Syslog appender lacks the 'readTimeoutMillis' setting

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500747#comment-17500747
 ] 

Gary D. Gregory edited comment on LOG4J2-3425 at 3/3/22, 1:29 PM:
--

[~SkyCrawl] 

A Syslog Appender is a Socket Appender, so you can use a *SocketOptions* 
element, here is a Socket Appender example:
{code:xml}

  

  
  

  

  
  

  

  

{code}
Any setting on a *Socket* 
([https://docs.oracle.com/javase/8/docs/api/java/net/Socket.html]), can be 
configured through the *SocketOptions* 
([https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-core/src/main/java/org/apache/logging/log4j/core/net/SocketOptions.java]),
 excerpted here:
{code:xml}
  

  
{code}
It looks like forgot to document it on the site.


was (Author: garydgregory):
[~SkyCrawl] 

A Syslog Appender is a Socket Appender, so you can use a *SocketOptions* 
element, here is a Socket Appender example:
{code:xml}

  

  
  

  

  
  

  

  

{code}
Any setting on a *Socket* 
([https://docs.oracle.com/javase/8/docs/api/java/net/Socket.html]), can be 
configured through the *SocketOptions* 
([https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-core/src/main/java/org/apache/logging/log4j/core/net/SocketOptions.java]),
 excepted here:
{code:xml}
  

  
{code}
It looks like forgot to document it on the site.

> Syslog appender lacks the 'readTimeoutMillis' setting
> -
>
> Key: LOG4J2-3425
> URL: https://issues.apache.org/jira/browse/LOG4J2-3425
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.12.1
>Reporter: Jiří Smolík
>Priority: Major
>
> Recently, we've had an issue with our syslog server (collector), where it was 
> suddenly unable to forward messages sent to it. This resulted in flooding the 
> server and ultimately, exhausting its resources (memory and allocated 
> temporary storage).
> However, more interestingly, Log4j2 appender behaved as follows:
>  # At the moment of exhaustion, one thread (T1) entered the synchronized 
> block in TcpSocketManager (see 
> https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L217)
>  and tried to write the message (see 
> [https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L253]).
>  # The server didn't respond immediately - actually,  it blocked T1 for hours 
> (it was most likely waiting for resources to be free).
>  # In the meantime, all threads attempting to write a message to the syslog 
> appender hanged at the synchronized block (they were waiting for T1 to 
> finish).
> Eventually, the connection to the server broke apart or some resources were 
> freed, and T1 finished. Interestingly, it didn't throw any exception, but 
> that is beside the point in this issue.
> So, what happened is that the server got flooded and blocked one thread in 
> our application, but due to the way TcpSocketManager is implemented, our 
> application suffered a DoS.
> As a precaution to such dreadful scenario, I would like to request adding a 
> read timeout setting to the TcpSocketManager (also syslog appender), which 
> would in case of the above described situation prevent T1 from blocking other 
> threads for a long time. At least, that's my idea of an easy fix. Connect and 
> reconnect timeout settings have a different purpose and were useless in this 
> case.
> I am aware that the issue is also a matter of the syslog server 
> configuration, but application developers do not always have it under their 
> control.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (LOG4J2-3425) Syslog appender lacks the 'readTimeoutMillis' setting

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500747#comment-17500747
 ] 

Gary D. Gregory edited comment on LOG4J2-3425 at 3/3/22, 1:30 PM:
--

[~SkyCrawl] 

A Syslog Appender is a Socket Appender, so you can use a *SocketOptions* 
element, here is a Socket Appender example:
{code:xml}

  

  
  

  

  
  

  

  

{code}
Any setting on a *Socket* 
([https://docs.oracle.com/javase/8/docs/api/java/net/Socket.html]), can be 
configured through the *SocketOptions* 
([https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-core/src/main/java/org/apache/logging/log4j/core/net/SocketOptions.java]),
 excerpted here:
{code:xml}
  

  
{code}
It looks like I forgot to document it on the site.


was (Author: garydgregory):
[~SkyCrawl] 

A Syslog Appender is a Socket Appender, so you can use a *SocketOptions* 
element, here is a Socket Appender example:
{code:xml}

  

  
  

  

  
  

  

  

{code}
Any setting on a *Socket* 
([https://docs.oracle.com/javase/8/docs/api/java/net/Socket.html]), can be 
configured through the *SocketOptions* 
([https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-core/src/main/java/org/apache/logging/log4j/core/net/SocketOptions.java]),
 excerpted here:
{code:xml}
  

  
{code}
It looks like forgot to document it on the site.

> Syslog appender lacks the 'readTimeoutMillis' setting
> -
>
> Key: LOG4J2-3425
> URL: https://issues.apache.org/jira/browse/LOG4J2-3425
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.12.1
>Reporter: Jiří Smolík
>Priority: Major
>
> Recently, we've had an issue with our syslog server (collector), where it was 
> suddenly unable to forward messages sent to it. This resulted in flooding the 
> server and ultimately, exhausting its resources (memory and allocated 
> temporary storage).
> However, more interestingly, Log4j2 appender behaved as follows:
>  # At the moment of exhaustion, one thread (T1) entered the synchronized 
> block in TcpSocketManager (see 
> https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L217)
>  and tried to write the message (see 
> [https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L253]).
>  # The server didn't respond immediately - actually,  it blocked T1 for hours 
> (it was most likely waiting for resources to be free).
>  # In the meantime, all threads attempting to write a message to the syslog 
> appender hanged at the synchronized block (they were waiting for T1 to 
> finish).
> Eventually, the connection to the server broke apart or some resources were 
> freed, and T1 finished. Interestingly, it didn't throw any exception, but 
> that is beside the point in this issue.
> So, what happened is that the server got flooded and blocked one thread in 
> our application, but due to the way TcpSocketManager is implemented, our 
> application suffered a DoS.
> As a precaution to such dreadful scenario, I would like to request adding a 
> read timeout setting to the TcpSocketManager (also syslog appender), which 
> would in case of the above described situation prevent T1 from blocking other 
> threads for a long time. At least, that's my idea of an easy fix. Connect and 
> reconnect timeout settings have a different purpose and were useless in this 
> case.
> I am aware that the issue is also a matter of the syslog server 
> configuration, but application developers do not always have it under their 
> control.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3425) Syslog appender lacks the 'readTimeoutMillis' setting

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500747#comment-17500747
 ] 

Gary D. Gregory commented on LOG4J2-3425:
-

[~SkyCrawl] 

A Syslog Appender is a Socket Appender, so you can use a *SocketOptions* 
element, here is a Socket Appender example:
{code:xml}

  

  
  

  

  
  

  

  

{code}
Any setting on a *Socket* 
([https://docs.oracle.com/javase/8/docs/api/java/net/Socket.html]), can be 
configured through the *SocketOptions* 
([https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-core/src/main/java/org/apache/logging/log4j/core/net/SocketOptions.java]),
 excepted here:
{code:xml}
  

  
{code}
It looks like forgot to document it on the site.

> Syslog appender lacks the 'readTimeoutMillis' setting
> -
>
> Key: LOG4J2-3425
> URL: https://issues.apache.org/jira/browse/LOG4J2-3425
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.12.1
>Reporter: Jiří Smolík
>Priority: Major
>
> Recently, we've had an issue with our syslog server (collector), where it was 
> suddenly unable to forward messages sent to it. This resulted in flooding the 
> server and ultimately, exhausting its resources (memory and allocated 
> temporary storage).
> However, more interestingly, Log4j2 appender behaved as follows:
>  # At the moment of exhaustion, one thread (T1) entered the synchronized 
> block in TcpSocketManager (see 
> https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L217)
>  and tried to write the message (see 
> [https://github.com/apache/logging-log4j2/blob/e2ee2f4dd9327eb1841023c3269ba12f5673e694/log4j-core/src/main/java/org/apache/logging/log4j/core/net/TcpSocketManager.java#L253]).
>  # The server didn't respond immediately - actually,  it blocked T1 for hours 
> (it was most likely waiting for resources to be free).
>  # In the meantime, all threads attempting to write a message to the syslog 
> appender hanged at the synchronized block (they were waiting for T1 to 
> finish).
> Eventually, the connection to the server broke apart or some resources were 
> freed, and T1 finished. Interestingly, it didn't throw any exception, but 
> that is beside the point in this issue.
> So, what happened is that the server got flooded and blocked one thread in 
> our application, but due to the way TcpSocketManager is implemented, our 
> application suffered a DoS.
> As a precaution to such dreadful scenario, I would like to request adding a 
> read timeout setting to the TcpSocketManager (also syslog appender), which 
> would in case of the above described situation prevent T1 from blocking other 
> threads for a long time. At least, that's my idea of an easy fix. Connect and 
> reconnect timeout settings have a different purpose and were useless in this 
> case.
> I am aware that the issue is also a matter of the syslog server 
> configuration, but application developers do not always have it under their 
> control.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3423) JAR file containing Log4j configuration isn't closed

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500693#comment-17500693
 ] 

Gary D. Gregory commented on LOG4J2-3423:
-

The url connection's setUseCaches can be called with false to avoid caching the 
jar file.

> JAR file containing Log4j configuration isn't closed
> 
>
> Key: LOG4J2-3423
> URL: https://issues.apache.org/jira/browse/LOG4J2-3423
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.14.0
> Environment: Windows
>Reporter: Radim Tlusty
>Priority: Major
>
> If the Log4j configuration file is inside of a JAR file, then the JAR file 
> (which is backed by the {{JarURLConnection}} retrieved from 
> {{{}URL.openConnection{}}}) isn't closed.
> This causes problems on Tomcat running on Windows during undeploying of an 
> application, because the opened JAR file can't be deleted.
> The problem was introduced during implementation of LOG4J2-2901 (version 
> 2.14.0), where the {{URL.openStream}} was replaced by {{URL.openConnection}} 
> in the class {{{}org.apache.logging.log4j.core.config.ConfigurationSource{}}}.
> The proposed solution (https://github.com/apache/logging-log4j2/pull/780) is 
> to use the {{URL.openConnection}} only when needed (~ configuration URL has 
> HTTPS protocol), otherwise similar code as in previous versions (<= 2.13.3) 
> would be used.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3419) Unable to create custom logging level using log4j 2 Bridge API

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500686#comment-17500686
 ] 

Gary D. Gregory commented on LOG4J2-3419:
-

[~ragini] 

See my first comment and I should be able to work on it this week end: "Would 
you provide a PR on GitHub with a failing test?"

> Unable to create custom logging level using log4j 2 Bridge API
> --
>
> Key: LOG4J2-3419
> URL: https://issues.apache.org/jira/browse/LOG4J2-3419
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: Using log4j 2 bridge API: log4j-1.2-api-2.17.1.jar
>Reporter: Ragini Gawande
>Priority: Blocker
>
> Unable to create custom logging level using log4j 2 Bridge API
> Following did not create a custom logging level
> *public static final int FINE_INT = 13000;*
> *public static final Level FINE = new Level(FINE_INT, "FINE", 7);* 
>  
> Using FINE logging level is considered to be DEBUG level by default while 
> printing it
> *Adding log:*
> log.log({*}Level.FINE{*},"PRINT: Level.FINE log");
>  
> *Expected log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *FINE* - PRINT: 
> Level.FINE log 
>  
> *Actual log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *DEBUG* - PRINT: 
> Level.FINE log 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3419) Unable to create custom logging level using log4j 2 Bridge API

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499619#comment-17499619
 ] 

Gary D. Gregory commented on LOG4J2-3419:
-

Hi [~ragini] 

Would you provide a PR on GitHub with a failing test?

The example in the description should not even compile since 
{{org.apache.log4j.Level.Level(int, String, int)}} is a protected constructor.

So there is some mismatch in my understanding of what the description expresses.

 

 

> Unable to create custom logging level using log4j 2 Bridge API
> --
>
> Key: LOG4J2-3419
> URL: https://issues.apache.org/jira/browse/LOG4J2-3419
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: Using log4j 2 bridge API: log4j-1.2-api-2.17.1.jar
>Reporter: Ragini Gawande
>Priority: Blocker
>
> Unable to create custom logging level using log4j 2 Bridge API
> Following did not create a custom logging level
> *public static final int FINE_INT = 13000;*
> *public static final Level FINE = new Level(FINE_INT, "FINE", 7);* 
>  
> Using FINE logging level is considered to be DEBUG level by default while 
> printing it
> *Adding log:*
> log.log({*}Level.FINE{*},"PRINT: Level.FINE log");
>  
> *Expected log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *FINE* - PRINT: 
> Level.FINE log 
>  
> *Actual log printed:*
> 2022-02-25 15:50:09,208 Main[6788] :main: example.com.Test *DEBUG* - PRINT: 
> Level.FINE log 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3421) Programmatic Configuration

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499515#comment-17499515
 ] 

Gary D. Gregory commented on LOG4J2-3421:
-

[~sovikstepan] 

Thank you for this report.

Would you provide a PR on the github branch release-2.x?

> Programmatic Configuration
> --
>
> Key: LOG4J2-3421
> URL: https://issues.apache.org/jira/browse/LOG4J2-3421
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Configuration, Documentation
>Affects Versions: 2.17.1
>Reporter: Štěpán Sovík
>Priority: Major
>
> The documentation provided here: 
> [https://logging.apache.org/log4j/2.x/manual/customconfig.html] contains 
> plenty of 'code snippets' that are using deprecated API, non-compilable 
> issues ... and even when one fixes all, it still doesn't work.
> Documentation issues need to be fixed and documentation updated so it's 
> obvious how it should actually work.
> Just some examples:
>  
> {code:java}
> public Configuration getConfiguration(InputSource source) {return 
> new MyXMLConfiguration(source, configFile);} {code}
> Where the configFile comes from??
>  
>  
> {code:java}
> @Overrideprotected void doConfigure() {super.doConfigure();   
>  final LoggerContext ctx = (LoggerContext) LogManager.getContext(false);  
>   final Configuration config = context.getConfiguration();final 
> Layout layout = PatternLayout.createDefaultLayout(config);final 
> Appender appender = FileAppender.createAppender("target/test.log", "false", 
> "false", "File", "true",  "false", "false", "4000", layout, null, 
> "false", null, config);appender.start();
> addAppender(appender);LoggerConfig loggerConfig = 
> LoggerConfig.createLogger("false", "info", "org.apache.logging.log4j",
>   "true", refs, null, config, null );
> loggerConfig.addAppender(appender, null, null);
> addLogger("org.apache.logging.log4j", loggerConfig);} {code}
> Where the refs come from??
>  
>  
> {code:java}
> final LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
> final Configuration config = context.getConfiguration(); {code}
> Really? No one was doing some kind of review on this?? Code snippets were 
> done in plain text editors?
>  
> {code:java}
>         LoggerConfig loggerConfig = LoggerConfig.createLogger("false", 
> "info", "org.apache.logging.log4j",
>             "true", refs, null, config, null ); {code}
> Come on! This cannot be even compiled ... because "{_}The method 
> createLogger(String, Level, String, String, AppenderRef[], Property[], 
> Configuration, Filter) in the type LoggerConfig is not applicable for the 
> arguments (String, String, String, String, AppenderRef[], null, 
> Configuration, null){_}"
> I've never seen such a badly documented feature before.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (LOG4J2-3417) Create JDBC appender for compatibility with v1

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17498835#comment-17498835
 ] 

Gary D. Gregory edited comment on LOG4J2-3417 at 2/28/22, 10:47 AM:


Excellent. As long as we do reuse Log4j 2's appender code, we will avoid the 
risk of SQL injection. 


was (Author: garydgregory):
Excellent. As long as we do reuse Log4j 2's runtime, we will avoid the risk of 
SQL injection. 

> Create JDBC appender for compatibility with v1
> --
>
> Key: LOG4J2-3417
> URL: https://issues.apache.org/jira/browse/LOG4J2-3417
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Appenders, Log4j 1.2 bridge
>Reporter: Matt Sicker
>Priority: Major
>
> Log4j 1 had a JDBC appender which made it fairly simple to set up an appender 
> to a database. While the old version doesn't work properly with modern 
> security practices, it shouldn't be too hard to parse the configured SQL 
> statement for pattern layout keys and extract them into a parameterized query.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3417) Create JDBC appender for compatibility with v1

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17498835#comment-17498835
 ] 

Gary D. Gregory commented on LOG4J2-3417:
-

Excellent. As long as we do reuse Log4j 2's runtime, we will avoid the risk of 
SQL injection. 

> Create JDBC appender for compatibility with v1
> --
>
> Key: LOG4J2-3417
> URL: https://issues.apache.org/jira/browse/LOG4J2-3417
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Appenders, Log4j 1.2 bridge
>Reporter: Matt Sicker
>Priority: Major
>
> Log4j 1 had a JDBC appender which made it fairly simple to set up an appender 
> to a database. While the old version doesn't work properly with modern 
> security practices, it shouldn't be too hard to parse the configured SQL 
> statement for pattern layout keys and extract them into a parameterized query.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3417) Create JDBC appender for compatibility with v1

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17498660#comment-17498660
 ] 

Gary D. Gregory commented on LOG4J2-3417:
-

Internally the SQL for something like 

log4j.appender.DB.sql=INSERT INTO LOGS VALUES('%x','%d','%C','%p','%m')

Should translate to

INSERT INTO LOGS VALUES(?, ?, ?, ?, ?)

It should be a requirement on our implementation to use JDBC a prepared 
statement or callable statement for a stored procedure call.

> Create JDBC appender for compatibility with v1
> --
>
> Key: LOG4J2-3417
> URL: https://issues.apache.org/jira/browse/LOG4J2-3417
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Appenders, Log4j 1.2 bridge
>Reporter: Matt Sicker
>Priority: Major
>
> Log4j 1 had a JDBC appender which made it fairly simple to set up an appender 
> to a database. While the old version doesn't work properly with modern 
> security practices, it shouldn't be too hard to parse the configured SQL 
> statement for pattern layout keys and extract them into a parameterized query.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3414) Release date for 2.17.2 to ease migration from log4j1.x to log4j 2.x in one of our product

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17498134#comment-17498134
 ] 

Gary D. Gregory commented on LOG4J2-3414:
-

[~PoojaTheCoder] 

Please see https://logging.apache.org/log4j/2.x/mail-lists.html

> Release date for 2.17.2 to ease migration from log4j1.x to log4j 2.x in one 
> of our product
> --
>
> Key: LOG4J2-3414
> URL: https://issues.apache.org/jira/browse/LOG4J2-3414
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.17.1
>Reporter: Pooja Pandey
>Priority: Major
>
> We are trying to migrate one of our product from log4j 1.x to log4j 2.x by 
> using the Log4j 1.x bridge.
> We are using custom FileAppender and ConsoleAppender in our product. However 
> when we are trying to build the code using Log4j 1.x bridge, build fails with 
> errors 'cannot find symbol'. We are trying to resolve this yet.
> I have found a mention on web that "Version 2.17.2 will contain about 50 
> improvements in the Log4j 1.x bridge, among them some old classes like 
> org.apache.log4j.FileAppender".
> I expect that hopefully version 2.17.2 will ease the migration process.
> I wanted to check does anyone knows the date or approximate date for the 
> release of 2.17.2? 
> Thanks!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Closed] (LOG4J2-3414) Release date for 2.17.2 to ease migration from log4j1.x to log4j 2.x in one of our product

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory closed LOG4J2-3414.
---
Resolution: Information Provided

[~PoojaTheCoder] please subscribe to the user's mailing list instead of 
creating a ticket for this question. The release announcement will be posted on 
the mailing list.

> Release date for 2.17.2 to ease migration from log4j1.x to log4j 2.x in one 
> of our product
> --
>
> Key: LOG4J2-3414
> URL: https://issues.apache.org/jira/browse/LOG4J2-3414
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.17.1
>Reporter: Pooja Pandey
>Priority: Major
>
> We are trying to migrate one of our product from log4j 1.x to log4j 2.x by 
> using the Log4j 1.x bridge.
> We are using custom FileAppender and ConsoleAppender in our product. However 
> when we are trying to build the code using Log4j 1.x bridge, build fails with 
> errors 'cannot find symbol'. We are trying to resolve this yet.
> I have found a mention on web that "Version 2.17.2 will contain about 50 
> improvements in the Log4j 1.x bridge, among them some old classes like 
> org.apache.log4j.FileAppender".
> I expect that hopefully version 2.17.2 will ease the migration process.
> I wanted to check does anyone knows the date or approximate date for the 
> release of 2.17.2? 
> Thanks!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3396) ERROR Recursive call to appender mongodb with spring boot root logger

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17496096#comment-17496096
 ] 

Gary D. Gregory commented on LOG4J2-3396:
-

I am guessing there is a loop between slf4j and Log4j as the MongoDB client 
depends on slf4j: 
[https://search.maven.org/artifact/org.mongodb/mongodb-driver-sync/4.5.0/jar]

This can be configured to work as documented here: 
[https://logging.apache.org/log4j/2.x/log4j-slf4j-impl/index.html]

> ERROR Recursive call to appender mongodb with spring boot root logger
> -
>
> Key: LOG4J2-3396
> URL: https://issues.apache.org/jira/browse/LOG4J2-3396
> Project: Log4j 2
>  Issue Type: Question
>  Components: MongoDB
>Affects Versions: 2.17.1
>Reporter: Omer U
>Priority: Major
>
> If mongodb4 logger is used as root logger in basic spring boot rest 
> application, it causes some sort of recursion error. And stalls startup. 
>  below causes recursive call error
> {code:xml}
>  
>   
>   
>  
> {code}
> while following does not produce error
> {code:xml}
>   
> 
>   
> 
> 
>   
> 
> 
>   
> {code}
>  
> {noformat}
> 2022-02-07 23:35:43,487 cluster-ClusterId{value='620182632ff6a504abdb6699', 
> description='null'}-localhost:27017 ERROR Recursive call to appender mongodb
> 23:36:13.481 [st:27017] INFO  o.m.d.cluster - Cluster description not yet 
> available. Waiting for 3 ms before timing out
> 2022-02-07 23:36:13,480 
> cluster-rtt-ClusterId{value='620182632ff6a504abdb6697', 
> description='null'}-localhost:27017 ERROR Unable to write to database 
> [noSqlManager{ description=mongodb, bufferSize=0, provider=MongoDb4Provider 
> [connectionString=mongodb://localhost:27017/tombolog.mongo4test, 
> collectionSize=1073741824, isCapped=true, 
> mongoClient=com.mongodb.client.internal.MongoClientImpl@2f67a4d3, 
> mongoDatabase=com.mongodb.client.internal.MongoDatabaseImpl@5e3f861] }] for 
> appender [mongodb]. 
> org.apache.logging.log4j.core.appender.AppenderLoggingException: Failed to 
> write log event to MongoDB due to error: Timed out after 3 ms while 
> waiting to connect. Client view of cluster state is {type=UNKNOWN, 
> servers=[{address=localhost:27017, type=UNKNOWN, state=CONNECTING}]
> {noformat}
> full log4j2.xml file
> {code:xml}
> 
> 
>   
> 
>   
> 
> 
>connection="${env:MONGO_LOG_URI:-mongodb://localhost:27017/log.mongo4test}" />
> 
>   
>   
> 
>   
>   
> 
> 
> 
>   
> 
> {code}
> build.gradle
> {code:groovy}
> plugins {
>   id 'org.springframework.boot' version '2.6.3'
>   id 'io.spring.dependency-management' version '1.0.11.RELEASE'
>   id 'java'
> }
> group = 'com.example'
> version = '0.0.1-SNAPSHOT'
> sourceCompatibility = '11'
> ext ['log4j2.version'] = '2.17.2-SNAPSHOT'
> repositories {
> mavenCentral()
> maven {
> url "http://repository.apache.org/content/repositories/snapshots/;
> }
> }
> dependencies {
>   implementation group: 'org.apache.logging.log4j', name: 
> 'log4j-mongodb4', version: '2.17.2-SNAPSHOT'
>   implementation 'org.springframework.boot:spring-boot-starter-web'
>   implementation 'org.springframework.boot:spring-boot-starter-log4j2'
>   testImplementation 'org.springframework.boot:spring-boot-starter-test'
> }
> configurations {
>   all {
>   exclude group: 'org.springframework.boot', module: 
> 'spring-boot-starter-logging'
>   exclude group: 'org.springframework.boot', module: 
> 'logback-classic'
>   }
> }
> tasks.named('test') {
>   useJUnitPlatform()
> }
> {code}
> is this normal behavior? I have tried to reproduce this without spring boot  
> without any success. 
> Any ideas?



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] (LOG4J2-3407) PropertiesConfiguration.parseAppender NPE when logger refers to non-existent appender

[Gary D. Gregory (Jira)]

[ https://issues.apache.org/jira/browse/LOG4J2-3407 ]


Gary D. Gregory deleted comment on LOG4J2-3407:
-

was (Author: garydgregory):
I am guessing there is a loop between slf4j and Log4j as the MongoDB client 
depends on slf4j: 
[https://search.maven.org/artifact/org.mongodb/mongodb-driver-sync/4.5.0/jar]

This can be configured to work as documented here: 
[https://logging.apache.org/log4j/2.x/log4j-slf4j-impl/index.html]

 

 

> 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
> Fix For: 2.17.2
>
> 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

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17496094#comment-17496094
 ] 

Gary D. Gregory commented on LOG4J2-3407:
-

I am guessing there is a loop between slf4j and Log4j as the MongoDB client 
depends on slf4j: 
[https://search.maven.org/artifact/org.mongodb/mongodb-driver-sync/4.5.0/jar]

This can be configured to work as documented here: 
[https://logging.apache.org/log4j/2.x/log4j-slf4j-impl/index.html]

 

 

> 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
> Fix For: 2.17.2
>
> 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] [Resolved] (LOG4J2-3407) PropertiesConfiguration.parseAppender NPE when logger refers to non-existent appender

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory resolved LOG4J2-3407.
-
Fix Version/s: 2.17.2
   Resolution: Fixed

[~kennymacleod.atl] 

In git branch {{{}release-2.x{}}}.

Please verify and close this ticket.

TY!

 

> 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
> Fix For: 2.17.2
>
> 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] [Resolved] (LOG4J2-3410) Log4j 1.2 bridge throws a ClassCastException when logging a Map with non-String keys

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory resolved LOG4J2-3410.
-
Fix Version/s: 2.17.2
   Resolution: Fixed

Hi [~bcfsham] ,

Thank you for reporting your issue. I fixed this in the {{release-2.x}} branch 
in git. Please try a local build or a snapshot build from 
[https://repository.apache.org/content/repositories/snapshots/]

It appears that the message logged might be a bit odd depending on the kind of 
{{Map}} logged. See the new test for details: 
{{/log4j-1.2-api/src/test/java/org/apache/log4j/LoggerJira3410Test.java}}

> Log4j 1.2 bridge throws a ClassCastException when logging a Map with 
> non-String keys
> 
>
> Key: LOG4J2-3410
> URL: https://issues.apache.org/jira/browse/LOG4J2-3410
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Log4j 1.2 bridge
>Affects Versions: 2.13.0, 2.17.1
> Environment: OS: Windows 10 Enterprise 64bit
> Java version: zulu8.31.0.1-jdk8.0.181-win_x64{*}{*}
>Reporter: Barry Sham
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> Our existing business logic contains a debug message which print out a 
> {_}org.apache.commons.collections.map.MultiKeyMap{_}:
>  
> {code:java}
> MultiKeyMap prnMap = MultiKeyMap.decorate(new LinkedMap());
> prnMap.put("0", "1", "2");
> logger.debug(prnMap);
> {code}
>  
> in {*}log4j-1.2-api 2.12.4{*}, it can be print out 
> {color:#4c9aff}properly{color}:
>  
> {code:java}
> {MultiKey[0, 1]=2}{code}
>  
> However it becomes an {color:#FF}ClassCastException {color}+since 
> *2.13.0* (including the latest {*}2.17.1{*})+
> {code:java}
> Exception in thread "main" java.lang.ClassCastException: 
> org.apache.commons.collections.keyvalue.MultiKey cannot be cast to 
> java.lang.String
>     at 
> org.apache.logging.log4j.util.SortedArrayStringMap.(SortedArrayStringMap.java:154)
>     at org.apache.logging.log4j.message.MapMessage.(MapMessage.java:125)
>     at org.apache.log4j.Category.maybeLog(Category.java:507)
>     at org.apache.log4j.Category.debug(Category.java:243)
>     at sideproject.sideproject.App.proeces(App.java:25)
>     at sideproject.sideproject.App.main(App.java:17){code}
> As the map can print out using *System.out* +without issue,+ we are wondering 
> if it is a bug in Apache Log4j 1.x Compatibility API
> A GitHub Project is prepared for reference: [shin779/log4j-multikeymap 
> (github.com)|https://github.com/shin779/log4j-multikeymap]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Work started] (LOG4J2-3410) Log4j 1.2 bridge throws a ClassCastException when logging a Map with non-String keys

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on LOG4J2-3410 started by Gary D. Gregory.
---
> Log4j 1.2 bridge throws a ClassCastException when logging a Map with 
> non-String keys
> 
>
> Key: LOG4J2-3410
> URL: https://issues.apache.org/jira/browse/LOG4J2-3410
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Log4j 1.2 bridge
>Affects Versions: 2.13.0, 2.17.1
> Environment: OS: Windows 10 Enterprise 64bit
> Java version: zulu8.31.0.1-jdk8.0.181-win_x64{*}{*}
>Reporter: Barry Sham
>Assignee: Gary D. Gregory
>Priority: Major
>
> Our existing business logic contains a debug message which print out a 
> {_}org.apache.commons.collections.map.MultiKeyMap{_}:
>  
> {code:java}
> MultiKeyMap prnMap = MultiKeyMap.decorate(new LinkedMap());
> prnMap.put("0", "1", "2");
> logger.debug(prnMap);
> {code}
>  
> in {*}log4j-1.2-api 2.12.4{*}, it can be print out 
> {color:#4c9aff}properly{color}:
>  
> {code:java}
> {MultiKey[0, 1]=2}{code}
>  
> However it becomes an {color:#FF}ClassCastException {color}+since 
> *2.13.0* (including the latest {*}2.17.1{*})+
> {code:java}
> Exception in thread "main" java.lang.ClassCastException: 
> org.apache.commons.collections.keyvalue.MultiKey cannot be cast to 
> java.lang.String
>     at 
> org.apache.logging.log4j.util.SortedArrayStringMap.(SortedArrayStringMap.java:154)
>     at org.apache.logging.log4j.message.MapMessage.(MapMessage.java:125)
>     at org.apache.log4j.Category.maybeLog(Category.java:507)
>     at org.apache.log4j.Category.debug(Category.java:243)
>     at sideproject.sideproject.App.proeces(App.java:25)
>     at sideproject.sideproject.App.main(App.java:17){code}
> As the map can print out using *System.out* +without issue,+ we are wondering 
> if it is a bug in Apache Log4j 1.x Compatibility API
> A GitHub Project is prepared for reference: [shin779/log4j-multikeymap 
> (github.com)|https://github.com/shin779/log4j-multikeymap]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (LOG4J2-3410) Log4j 1.2 bridge throws a ClassCastException when logging a Map with non-String keys

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory reassigned LOG4J2-3410:
---

Assignee: Gary D. Gregory

> Log4j 1.2 bridge throws a ClassCastException when logging a Map with 
> non-String keys
> 
>
> Key: LOG4J2-3410
> URL: https://issues.apache.org/jira/browse/LOG4J2-3410
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Log4j 1.2 bridge
>Affects Versions: 2.13.0, 2.17.1
> Environment: OS: Windows 10 Enterprise 64bit
> Java version: zulu8.31.0.1-jdk8.0.181-win_x64{*}{*}
>Reporter: Barry Sham
>Assignee: Gary D. Gregory
>Priority: Major
>
> Our existing business logic contains a debug message which print out a 
> {_}org.apache.commons.collections.map.MultiKeyMap{_}:
>  
> {code:java}
> MultiKeyMap prnMap = MultiKeyMap.decorate(new LinkedMap());
> prnMap.put("0", "1", "2");
> logger.debug(prnMap);
> {code}
>  
> in {*}log4j-1.2-api 2.12.4{*}, it can be print out 
> {color:#4c9aff}properly{color}:
>  
> {code:java}
> {MultiKey[0, 1]=2}{code}
>  
> However it becomes an {color:#FF}ClassCastException {color}+since 
> *2.13.0* (including the latest {*}2.17.1{*})+
> {code:java}
> Exception in thread "main" java.lang.ClassCastException: 
> org.apache.commons.collections.keyvalue.MultiKey cannot be cast to 
> java.lang.String
>     at 
> org.apache.logging.log4j.util.SortedArrayStringMap.(SortedArrayStringMap.java:154)
>     at org.apache.logging.log4j.message.MapMessage.(MapMessage.java:125)
>     at org.apache.log4j.Category.maybeLog(Category.java:507)
>     at org.apache.log4j.Category.debug(Category.java:243)
>     at sideproject.sideproject.App.proeces(App.java:25)
>     at sideproject.sideproject.App.main(App.java:17){code}
> As the map can print out using *System.out* +without issue,+ we are wondering 
> if it is a bug in Apache Log4j 1.x Compatibility API
> A GitHub Project is prepared for reference: [shin779/log4j-multikeymap 
> (github.com)|https://github.com/shin779/log4j-multikeymap]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (LOG4J2-3410) Log4j 1.x Compatibility API - ClassCastException when logging a Map with non-String keys

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LOG4J2-3410:

Summary: Log4j 1.x Compatibility API - ClassCastException when logging a 
Map with non-String keys  (was: Log4j 1.x Compatibility API - 
ClassCastException when logging MultiKeyMap)

> Log4j 1.x Compatibility API - ClassCastException when logging a Map with 
> non-String keys
> 
>
> Key: LOG4J2-3410
> URL: https://issues.apache.org/jira/browse/LOG4J2-3410
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Log4j 1.2 bridge
>Affects Versions: 2.13.0, 2.17.1
> Environment: OS: Windows 10 Enterprise 64bit
> Java version: zulu8.31.0.1-jdk8.0.181-win_x64{*}{*}
>Reporter: Barry Sham
>Priority: Major
>
> Our existing business logic contains a debug message which print out a 
> {_}org.apache.commons.collections.map.MultiKeyMap{_}:
>  
> {code:java}
> MultiKeyMap prnMap = MultiKeyMap.decorate(new LinkedMap());
> prnMap.put("0", "1", "2");
> logger.debug(prnMap);
> {code}
>  
> in {*}log4j-1.2-api 2.12.4{*}, it can be print out 
> {color:#4c9aff}properly{color}:
>  
> {code:java}
> {MultiKey[0, 1]=2}{code}
>  
> However it becomes an {color:#FF}ClassCastException {color}+since 
> *2.13.0* (including the latest {*}2.17.1{*})+
> {code:java}
> Exception in thread "main" java.lang.ClassCastException: 
> org.apache.commons.collections.keyvalue.MultiKey cannot be cast to 
> java.lang.String
>     at 
> org.apache.logging.log4j.util.SortedArrayStringMap.(SortedArrayStringMap.java:154)
>     at org.apache.logging.log4j.message.MapMessage.(MapMessage.java:125)
>     at org.apache.log4j.Category.maybeLog(Category.java:507)
>     at org.apache.log4j.Category.debug(Category.java:243)
>     at sideproject.sideproject.App.proeces(App.java:25)
>     at sideproject.sideproject.App.main(App.java:17){code}
> As the map can print out using *System.out* +without issue,+ we are wondering 
> if it is a bug in Apache Log4j 1.x Compatibility API
> A GitHub Project is prepared for reference: [shin779/log4j-multikeymap 
> (github.com)|https://github.com/shin779/log4j-multikeymap]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (LOG4J2-3410) Log4j 1.2 bridge throws a ClassCastException when logging a Map with non-String keys

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LOG4J2-3410:

Summary: Log4j 1.2 bridge throws a ClassCastException when logging a Map 
with non-String keys  (was: Log4j 1.x Compatibility API - ClassCastException 
when logging a Map with non-String keys)

> Log4j 1.2 bridge throws a ClassCastException when logging a Map with 
> non-String keys
> 
>
> Key: LOG4J2-3410
> URL: https://issues.apache.org/jira/browse/LOG4J2-3410
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Log4j 1.2 bridge
>Affects Versions: 2.13.0, 2.17.1
> Environment: OS: Windows 10 Enterprise 64bit
> Java version: zulu8.31.0.1-jdk8.0.181-win_x64{*}{*}
>Reporter: Barry Sham
>Priority: Major
>
> Our existing business logic contains a debug message which print out a 
> {_}org.apache.commons.collections.map.MultiKeyMap{_}:
>  
> {code:java}
> MultiKeyMap prnMap = MultiKeyMap.decorate(new LinkedMap());
> prnMap.put("0", "1", "2");
> logger.debug(prnMap);
> {code}
>  
> in {*}log4j-1.2-api 2.12.4{*}, it can be print out 
> {color:#4c9aff}properly{color}:
>  
> {code:java}
> {MultiKey[0, 1]=2}{code}
>  
> However it becomes an {color:#FF}ClassCastException {color}+since 
> *2.13.0* (including the latest {*}2.17.1{*})+
> {code:java}
> Exception in thread "main" java.lang.ClassCastException: 
> org.apache.commons.collections.keyvalue.MultiKey cannot be cast to 
> java.lang.String
>     at 
> org.apache.logging.log4j.util.SortedArrayStringMap.(SortedArrayStringMap.java:154)
>     at org.apache.logging.log4j.message.MapMessage.(MapMessage.java:125)
>     at org.apache.log4j.Category.maybeLog(Category.java:507)
>     at org.apache.log4j.Category.debug(Category.java:243)
>     at sideproject.sideproject.App.proeces(App.java:25)
>     at sideproject.sideproject.App.main(App.java:17){code}
> As the map can print out using *System.out* +without issue,+ we are wondering 
> if it is a bug in Apache Log4j 1.x Compatibility API
> A GitHub Project is prepared for reference: [shin779/log4j-multikeymap 
> (github.com)|https://github.com/shin779/log4j-multikeymap]



--
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

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Commented] (LOG4J2-3407) PropertiesConfiguration.parseAppender NPE when logger refers to non-existent appender

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Commented] (LOG4J2-3388) Migration from log4j1.x to log4j2.x

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493208#comment-17493208
 ] 

Gary D. Gregory commented on LOG4J2-3388:
-

Do you have whitespace at the end of the lines in the prop file?

> Migration from log4j1.x to log4j2.x
> ---
>
> Key: LOG4J2-3388
> URL: https://issues.apache.org/jira/browse/LOG4J2-3388
> Project: Log4j 2
>  Issue Type: Question
>Reporter: Janardhan Naidu
>Priority: Major
>
> We are planning to upgrade log4j1.x to log4j2.x.
> So we went through the migration document: 
> [https://logging.apache.org/log4j/2.x/manual/migration.html] 
> in the above document, It says that (They must not access methods and classes 
> internal to the Log4j 1.x implementation such as Appenders, LoggerRepository 
> or Category’s callAppenders method.) 
> and In our product, currently we are using log4j1.x and we are extending some 
> of the log4j1.x classes like PatternParser, FileAppender etc... which were 
> made final in log4j2.x  so can we make use of Log4j 1.x bridge.?  If yes how 
> we can do that.
>  
> what could be the better option to migrate log4j 1.x to log4j 2.x as we are 
> making use of log4j internal classes? 
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3328) Log4j 1.2 bridge does not support system properties in log4j.xml

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491961#comment-17491961
 ] 

Gary D. Gregory commented on LOG4J2-3328:
-

Hi [~john215], my guess is within one month.

> Log4j 1.2 bridge does not support system properties in log4j.xml
> 
>
> Key: LOG4J2-3328
> URL: https://issues.apache.org/jira/browse/LOG4J2-3328
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Log4j 1.2 bridge
>Affects Versions: 2.17.1
> Environment: {{Windows 10}}
> {{Amazon Linux}}
>Reporter: Paul Cooper
>Assignee: Gary D. Gregory
>Priority: Blocker
> Fix For: 2.17.2
>
>
> I am attempting to use the log4j bridge with log4j2, and cannot use system 
> properties to set a location for my log files.
> Reported here: 
> [stackoverflow|https://stackoverflow.com/questions/70628593/system-property-not-being-read-by-log4j2-lo4j1-bridge]
> My log4j.xml file:
> {{log4j-dev.xml}}
> {{...}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{}}
> {{...}}
> The setenv.bat entry where I define which log4j.xml to use:
> {{-Dlog4j2.debug=true -Dlog4j.configuration=log4j-dev.xml}}
> The properties shown in the tomcat log illustrating that the system property 
> in question is being supplied to the log4j1 bridge
> {{...}}
> {{Command line argument: -Dlog4j2.debug=true}}
> {{Command line argument: -Dlog4j.logDir=C:\dev\apache-tomcat-8.5.50\logs}}
> {{Command line argument: -Dlog4j.configuration=log4j-dev.xml}}
> {{Command line argument: -Dcatalina.base=C:\dev\apache-tomcat-8.5.50}}
> {{Command line argument: -Dcatalina.home=C:\dev\apache-tomcat-8.5.50}}
> {{Command line argument: -Djava.io.tmpdir=C:\dev\apache-tomcat-8.5.50\temp}}
> {{...}}
> And the part of the log that shows where the log file is successfully created 
> and what path it is using:
> {{...}}
> {{DEBUG StatusLogger Class name: [org.apache.log4j.RollingFileAppender]}}
> {{DEBUG StatusLogger Parsing layout of class: 
> "org.apache.log4j.PatternLayout"}}
> {{DEBUG StatusLogger PluginManager 'Converter' found 47 plugins}}
> {{TRACE StatusLogger New file '${catalina.base}/etl.log' created = true}}
> {{DEBUG StatusLogger Returning file creation time for 
> C:\dev\apache-tomcat-8.5.50\bin\${catalina.base}\etl.log}}
> {{DEBUG StatusLogger Starting RollingFileManager ${catalina.base}/etl.log}}
> {{...}}
> The log file is being created in a folder named "${catalina.base}", in 
> whatever directory I'm in when I start tomcat.  The issue is similar to this 
> Jira issue, LOG4J2-2951, and that issue was just resolved in early December.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3371) Log Injection Vulnerability exists in Log4j2 default configuration

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490479#comment-17490479
 ] 

Gary D. Gregory commented on LOG4J2-3371:
-

If we were to allow for stripping out control characters like CR and LF (what 
about tabs, NUL, DEL?), we'd certainly want to point out the consequence of 
this feature for performance and garbage generation.

> Log Injection Vulnerability exists in Log4j2 default configuration
> --
>
> Key: LOG4J2-3371
> URL: https://issues.apache.org/jira/browse/LOG4J2-3371
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.17.1
>Reporter: 4ra1n
>Assignee: Ralph Goers
>Priority: Major
>
> For information about log injection, refer to OWASP:
> [https://owasp.org/www-community/attacks/Log_Injection]
>  
> Some time ago, the spring framework revealed two CVE vulnerabilities related 
> to log injection: CVE-2021-22096 and CVE-2021-22060:
> [https://tanzu.vmware.com/security/cve-2021-22096]
> [https://tanzu.vmware.com/security/cve-2021-22060]
> Their fix is to filter the log content, such as not allowing line seprators
>  
> Some time ago, I found a log injection vulnerability in other Apache project, 
> which use log4j2. Although the vulnerability is effective and can be 
> triggered, they think I should report the problem to Apahce Log4j and prevent 
> such log injection vulnerability under the default configuration
>  
> code(under the default configuration)
> {code:java}
> public static void main(String[] args) {
>Logger logger = LogManager.getLogger(Main.class);
>logger.info("test\n00:00:00.000 [main] ERROR com.text.Class -
> xxx\nxxx");
> } {code}
>  
> output(under the default configuration)
> {code:java}
> 09:47:34.190 [main] INFO com.example.Main - test
> 00:00:00.000 [main] ERROR com.text.Class - xxx
> xxx {code}
> On the exploitation of vulnerabilities: for example, add some confused logs, 
> such as forged IP, forged classes, forged error reports and exceptions, which 
> brings trouble to the operation and maintenance personnel and auditors. 
> Further, if there is an internal log analysis platform, and the xxx is 
> wrapped by the script tag, that is, JavaScript code, the platform reading the 
> log may have XSS vulnerabilities.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3391) Add optional additional fields to NoSQLAppender

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490271#comment-17490271
 ] 

Gary D. Gregory commented on LOG4J2-3391:
-

[~ugurlu] 

Give it another go and let me know...

> Add optional additional fields to NoSQLAppender
> ---
>
> Key: LOG4J2-3391
> URL: https://issues.apache.org/jira/browse/LOG4J2-3391
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Reporter: Omer U
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.17.2
>
>
> Additional fields cannot be added to NoSQLAppender logs. 
> I wasn't able to way a find of attaching fields application server hostname 
> or a simple tag like application server name.
> Only way of adding custom information seems to be ThreadContext



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (LOG4J2-3399) Release date for 2.17.2

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-3399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489856#comment-17489856
 ] 

Gary D. Gregory commented on LOG4J2-3399:
-

A better place for this query is the user's mailing list.

> Release date for 2.17.2
> ---
>
> Key: LOG4J2-3399
> URL: https://issues.apache.org/jira/browse/LOG4J2-3399
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.17.1
>Reporter: Steve Souza
>Priority: Major
>
> We are trying to get rid of log4j 1.x usage in various products by using the 
> log4j2 bridge. One of the products is Pentaho spoon.  The Pentaho vendor is 
> working on their code to get rid of log4j 1.x dependencies, but they don't 
> expect that to be until june.   
> To solve the problem more immediately we tried the log4j2 bridge version 
> 2.17.1.  However, an exception is thrown (LogLog class not found) when 
> Pentaho spoon startsup.  LogLog was added in the 2.17.2-SNAPSHOT release and 
> I was able to successfully run Pentaho spoon with it!  
> However, my security team will surely ask me when the full-blown log4j 2.17.2 
> will be fully released before they accept this solution.  Does anyone know 
> the date or approximate date for the release of 2.17.2?  If we don't get this 
> patch we may have to shut Pentaho down.
> Thanks!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)