[jira] [Commented] (LOG4J2-2591) RollingFileAppender don't append log file after restart service.

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-2591:
-

Please try with the latest code in the release-2.x branch. I suspect this may 
have been fixed by LOG4J2-2610.

If it doesn't then I might not have a clear understanding of the problem. For 
example it isn't clear to me how an example at April 16 applies to something on 
December 15. When was the original file created and how long was it active? If 
I understand correctly, the file should have been renamed to 
portal-2019-\{MM}-\{dd}.log, where MM and dd are the month and day the original 
log file was create, and then a new file should have been written to. Is that 
not what happened?

> RollingFileAppender don't append log file after restart service.
> 
>
> Key: LOG4J2-2591
> URL: https://issues.apache.org/jira/browse/LOG4J2-2591
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.11.2
> Environment: Windows Server 2008 R2 & Windows 10
> OpenJDK Runtime Environment 11.0.2
> Java 11
>Reporter: Philipp Fels
>Priority: Major
>  Labels: 11.0.2, Java, Windows
>
> The RollingFileAppender dosn't append to the current log file after restart 
> of Service at Windows.
> At UNIX Systems it works as expected.
> Our log4j2 Configuration:
>  
> {code:java}
> 
>  packages="de.uplanet.lucy.server.portalserver.messages" 
> shutdownHook="disable">
> 
>  log
> 
> 
> 
>  fileName="${sys:de.uplanet.lucy.logPath}/portal.log" 
> filePattern="${sys:de.uplanet.lucy.logPath}/portal.%d{-MM-dd}.log">
> 
> %-5p %d{ISO8601}{UTC}Z - %c[%t]%n %m%n
> 
> 
> 
> 
>  onMismatch="DENY"/>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> {code}
> If you have a new Installation it works as expected, after a few days we have 
> this behavior:
> Example at 16.04.2019:
> After an restart of the service, the content portal.log will be copied in a 
> file with that name portal.15-12-2018.log. the 15th december 2018 is the 
> creation date of the log folder where the logs are saved.
> And after that the old content in portal.log will be deleted.
> New log content will be logged in the empty portal.log
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (LOG4J2-2636) No default value for mdcId in SyslogAppender

[Ralph Goers (JIRA)]

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

Ralph Goers edited comment on LOG4J2-2636 at 6/21/19 4:40 PM:
--

The suggested patch is wrong. The id field is the default structured data id 
for all structured data elements. The mdcId field is the id value for the mdc 
structured data element only. Normally these would be the same but they don't 
have to be. So the id value should be the default for the mdcId.

the code really should be
{code:java}
this.mdcId = mdcId != null ? mdcId : id == null ? DEFAULT_MDCID : id;
this.mdcSdId = new StructuredDataId(this.mdcId, enterpriseNumber, null, 
null);{code}
 


was (Author: ralph.go...@dslextreme.com):
The suggested patch is wrong. The id field is the default structured data id 
for all structured data elements. The mdcId field is the id value for the mdc 
structured data element only. Normally these would be the same but they don't 
have to be. So the id value is the default for the mdcId, which is exactly what 
is in the code now.

> No default value for mdcId in SyslogAppender
> 
>
> Key: LOG4J2-2636
> URL: https://issues.apache.org/jira/browse/LOG4J2-2636
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.11.2
>Reporter: Filipp Gunbin
>Priority: Major
>
> 1) Main issue
> When Rfc5424Layout is created from configuration, it seems to receive default 
> value:
> {code:java}
> @PluginAttribute(value = "mdcId", defaultString = DEFAULT_MDCID) final String 
> mdcId,{code}
> But SyslogAppender has it with no default:
> {code:java}
> @PluginBuilderAttribute("mdcId")
> private String mdcId;{code}
> It is used in SyslogAppender.build() to create Rfc5424Layout.  So, if I don't 
> specify "mdcId" attribute in " config element, I get this exception:
> {quote}ERROR StatusLogger Could not create plugin of type class 
> org.apache.logging.log4j.core.appender.SyslogAppender for element Syslog: 
> java.lang.IllegalArgumentException: No structured id name was supplied 
> java.lang.IllegalArgumentException: No structured id name was supplied at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:146)
>  at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:130)
>  at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.(Rfc5424Layout.java:142)
>  at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.createLayout(Rfc5424Layout.java:672)
>  at 
> org.apache.logging.log4j.core.appender.SyslogAppender$Builder.build(SyslogAppender.java:117)
>  at 
> org.apache.logging.log4j.core.appender.SyslogAppender$Builder.build(SyslogAppender.java:50)
> {quote}
> 2) Documentation doesn't mention mdcId of SyslogAppender at all: 
> [https://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender]
> If I build site locally with "mvn site" in 2.11.2, it's not there either.
> 3) Commit ce1183629fe89625a77872c7153853e7774502a6 
> (https://issues.apache.org/jira/browse/LOG4J2-922) which introduces default 
> value for mdcId in Rfc5424Layout has this code:
> {code:java}
> this.mdcId = id == null ? DEFAULT_MDCID : id;         
> this.mdcSdId = new StructuredDataId(mdcId, enterpriseNumber, null, 
> null);{code}
> While "this.mdcId" is set in first line, the argument (not class member) 
> mdcId is used in the second line.  Maybe argument mdcId should be used in the 
> first line instead of "id"?  Maybe this.mdcId should be used in the second 
> line instead of argument mdcId? I'm not familiar with the code enough to tell 
> for sure, it just feels suspicious to me.
> Thanks.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2636) No default value for mdcId in SyslogAppender

[Filipp Gunbin (JIRA)]

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

Filipp Gunbin commented on LOG4J2-2636:
---

Makes sense.

> No default value for mdcId in SyslogAppender
> 
>
> Key: LOG4J2-2636
> URL: https://issues.apache.org/jira/browse/LOG4J2-2636
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.11.2
>Reporter: Filipp Gunbin
>Priority: Major
>
> 1) Main issue
> When Rfc5424Layout is created from configuration, it seems to receive default 
> value:
> {code:java}
> @PluginAttribute(value = "mdcId", defaultString = DEFAULT_MDCID) final String 
> mdcId,{code}
> But SyslogAppender has it with no default:
> {code:java}
> @PluginBuilderAttribute("mdcId")
> private String mdcId;{code}
> It is used in SyslogAppender.build() to create Rfc5424Layout.  So, if I don't 
> specify "mdcId" attribute in " config element, I get this exception:
> {quote}ERROR StatusLogger Could not create plugin of type class 
> org.apache.logging.log4j.core.appender.SyslogAppender for element Syslog: 
> java.lang.IllegalArgumentException: No structured id name was supplied 
> java.lang.IllegalArgumentException: No structured id name was supplied at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:146)
>  at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:130)
>  at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.(Rfc5424Layout.java:142)
>  at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.createLayout(Rfc5424Layout.java:672)
>  at 
> org.apache.logging.log4j.core.appender.SyslogAppender$Builder.build(SyslogAppender.java:117)
>  at 
> org.apache.logging.log4j.core.appender.SyslogAppender$Builder.build(SyslogAppender.java:50)
> {quote}
> 2) Documentation doesn't mention mdcId of SyslogAppender at all: 
> [https://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender]
> If I build site locally with "mvn site" in 2.11.2, it's not there either.
> 3) Commit ce1183629fe89625a77872c7153853e7774502a6 
> (https://issues.apache.org/jira/browse/LOG4J2-922) which introduces default 
> value for mdcId in Rfc5424Layout has this code:
> {code:java}
> this.mdcId = id == null ? DEFAULT_MDCID : id;         
> this.mdcSdId = new StructuredDataId(mdcId, enterpriseNumber, null, 
> null);{code}
> While "this.mdcId" is set in first line, the argument (not class member) 
> mdcId is used in the second line.  Maybe argument mdcId should be used in the 
> first line instead of "id"?  Maybe this.mdcId should be used in the second 
> line instead of argument mdcId? I'm not familiar with the code enough to tell 
> for sure, it just feels suspicious to me.
> Thanks.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2636) No default value for mdcId in SyslogAppender

[Filipp Gunbin (JIRA)]

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

Filipp Gunbin commented on LOG4J2-2636:
---

[~rgoers] what about the second line the patch changes? According to what you 
wrote, it should be correct.

> No default value for mdcId in SyslogAppender
> 
>
> Key: LOG4J2-2636
> URL: https://issues.apache.org/jira/browse/LOG4J2-2636
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.11.2
>Reporter: Filipp Gunbin
>Priority: Major
>
> 1) Main issue
> When Rfc5424Layout is created from configuration, it seems to receive default 
> value:
> {code:java}
> @PluginAttribute(value = "mdcId", defaultString = DEFAULT_MDCID) final String 
> mdcId,{code}
> But SyslogAppender has it with no default:
> {code:java}
> @PluginBuilderAttribute("mdcId")
> private String mdcId;{code}
> It is used in SyslogAppender.build() to create Rfc5424Layout.  So, if I don't 
> specify "mdcId" attribute in " config element, I get this exception:
> {quote}ERROR StatusLogger Could not create plugin of type class 
> org.apache.logging.log4j.core.appender.SyslogAppender for element Syslog: 
> java.lang.IllegalArgumentException: No structured id name was supplied 
> java.lang.IllegalArgumentException: No structured id name was supplied at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:146)
>  at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:130)
>  at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.(Rfc5424Layout.java:142)
>  at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.createLayout(Rfc5424Layout.java:672)
>  at 
> org.apache.logging.log4j.core.appender.SyslogAppender$Builder.build(SyslogAppender.java:117)
>  at 
> org.apache.logging.log4j.core.appender.SyslogAppender$Builder.build(SyslogAppender.java:50)
> {quote}
> 2) Documentation doesn't mention mdcId of SyslogAppender at all: 
> [https://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender]
> If I build site locally with "mvn site" in 2.11.2, it's not there either.
> 3) Commit ce1183629fe89625a77872c7153853e7774502a6 
> (https://issues.apache.org/jira/browse/LOG4J2-922) which introduces default 
> value for mdcId in Rfc5424Layout has this code:
> {code:java}
> this.mdcId = id == null ? DEFAULT_MDCID : id;         
> this.mdcSdId = new StructuredDataId(mdcId, enterpriseNumber, null, 
> null);{code}
> While "this.mdcId" is set in first line, the argument (not class member) 
> mdcId is used in the second line.  Maybe argument mdcId should be used in the 
> first line instead of "id"?  Maybe this.mdcId should be used in the second 
> line instead of argument mdcId? I'm not familiar with the code enough to tell 
> for sure, it just feels suspicious to me.
> Thanks.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Issue Comment Deleted] (LOG4J2-2636) No default value for mdcId in SyslogAppender

[Filipp Gunbin (JIRA)]

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

Filipp Gunbin updated LOG4J2-2636:
--
Comment: was deleted

(was: [~rgoers] what about the second line the patch changes? According to what 
you wrote, it should be correct.)

> No default value for mdcId in SyslogAppender
> 
>
> Key: LOG4J2-2636
> URL: https://issues.apache.org/jira/browse/LOG4J2-2636
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.11.2
>Reporter: Filipp Gunbin
>Priority: Major
>
> 1) Main issue
> When Rfc5424Layout is created from configuration, it seems to receive default 
> value:
> {code:java}
> @PluginAttribute(value = "mdcId", defaultString = DEFAULT_MDCID) final String 
> mdcId,{code}
> But SyslogAppender has it with no default:
> {code:java}
> @PluginBuilderAttribute("mdcId")
> private String mdcId;{code}
> It is used in SyslogAppender.build() to create Rfc5424Layout.  So, if I don't 
> specify "mdcId" attribute in " config element, I get this exception:
> {quote}ERROR StatusLogger Could not create plugin of type class 
> org.apache.logging.log4j.core.appender.SyslogAppender for element Syslog: 
> java.lang.IllegalArgumentException: No structured id name was supplied 
> java.lang.IllegalArgumentException: No structured id name was supplied at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:146)
>  at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:130)
>  at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.(Rfc5424Layout.java:142)
>  at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.createLayout(Rfc5424Layout.java:672)
>  at 
> org.apache.logging.log4j.core.appender.SyslogAppender$Builder.build(SyslogAppender.java:117)
>  at 
> org.apache.logging.log4j.core.appender.SyslogAppender$Builder.build(SyslogAppender.java:50)
> {quote}
> 2) Documentation doesn't mention mdcId of SyslogAppender at all: 
> [https://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender]
> If I build site locally with "mvn site" in 2.11.2, it's not there either.
> 3) Commit ce1183629fe89625a77872c7153853e7774502a6 
> (https://issues.apache.org/jira/browse/LOG4J2-922) which introduces default 
> value for mdcId in Rfc5424Layout has this code:
> {code:java}
> this.mdcId = id == null ? DEFAULT_MDCID : id;         
> this.mdcSdId = new StructuredDataId(mdcId, enterpriseNumber, null, 
> null);{code}
> While "this.mdcId" is set in first line, the argument (not class member) 
> mdcId is used in the second line.  Maybe argument mdcId should be used in the 
> first line instead of "id"?  Maybe this.mdcId should be used in the second 
> line instead of argument mdcId? I'm not familiar with the code enough to tell 
> for sure, it just feels suspicious to me.
> Thanks.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2636) No default value for mdcId in SyslogAppender

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-2636:
-

The suggested patch is wrong. The id field is the default structured data id 
for all structured data elements. The mdcId field is the id value for the mdc 
structured data element only. Normally these would be the same but they don't 
have to be. So the id value is the default for the mdcId, which is exactly what 
is in the code now.

> No default value for mdcId in SyslogAppender
> 
>
> Key: LOG4J2-2636
> URL: https://issues.apache.org/jira/browse/LOG4J2-2636
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.11.2
>Reporter: Filipp Gunbin
>Priority: Major
>
> 1) Main issue
> When Rfc5424Layout is created from configuration, it seems to receive default 
> value:
> {code:java}
> @PluginAttribute(value = "mdcId", defaultString = DEFAULT_MDCID) final String 
> mdcId,{code}
> But SyslogAppender has it with no default:
> {code:java}
> @PluginBuilderAttribute("mdcId")
> private String mdcId;{code}
> It is used in SyslogAppender.build() to create Rfc5424Layout.  So, if I don't 
> specify "mdcId" attribute in " config element, I get this exception:
> {quote}ERROR StatusLogger Could not create plugin of type class 
> org.apache.logging.log4j.core.appender.SyslogAppender for element Syslog: 
> java.lang.IllegalArgumentException: No structured id name was supplied 
> java.lang.IllegalArgumentException: No structured id name was supplied at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:146)
>  at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:130)
>  at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.(Rfc5424Layout.java:142)
>  at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.createLayout(Rfc5424Layout.java:672)
>  at 
> org.apache.logging.log4j.core.appender.SyslogAppender$Builder.build(SyslogAppender.java:117)
>  at 
> org.apache.logging.log4j.core.appender.SyslogAppender$Builder.build(SyslogAppender.java:50)
> {quote}
> 2) Documentation doesn't mention mdcId of SyslogAppender at all: 
> [https://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender]
> If I build site locally with "mvn site" in 2.11.2, it's not there either.
> 3) Commit ce1183629fe89625a77872c7153853e7774502a6 
> (https://issues.apache.org/jira/browse/LOG4J2-922) which introduces default 
> value for mdcId in Rfc5424Layout has this code:
> {code:java}
> this.mdcId = id == null ? DEFAULT_MDCID : id;         
> this.mdcSdId = new StructuredDataId(mdcId, enterpriseNumber, null, 
> null);{code}
> While "this.mdcId" is set in first line, the argument (not class member) 
> mdcId is used in the second line.  Maybe argument mdcId should be used in the 
> first line instead of "id"?  Maybe this.mdcId should be used in the second 
> line instead of argument mdcId? I'm not familiar with the code enough to tell 
> for sure, it just feels suspicious to me.
> Thanks.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Jenkins build is back to stable : Log4j 2 2.x #3935

[Apache Jenkins Server]

See 

[jira] [Commented] (LOG4J2-2591) RollingFileAppender don't append log file after restart service.

[Davide Martusciello (JIRA)]

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

Davide Martusciello commented on LOG4J2-2591:
-

same problem to me! With CronTriggeringPolicy suggested from [~philippfels] 
same problem.
 * +Downgrade Log4j2 to version 2.11.1 solve my problem.(y)+
 * +With version 2.11.2, using RollingRandomAccessFile solve this issue(y)+

this is my configuration:
{code:xml}








%d{-MM-dd HH:mm:ss} %-5p 
%C{1}:%T:%L - %m%n



  













{code}
*Environment Windows 10 - Java  version: 1.8.0_111*

> RollingFileAppender don't append log file after restart service.
> 
>
> Key: LOG4J2-2591
> URL: https://issues.apache.org/jira/browse/LOG4J2-2591
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.11.2
> Environment: Windows Server 2008 R2 & Windows 10
> OpenJDK Runtime Environment 11.0.2
> Java 11
>Reporter: Philipp Fels
>Priority: Major
>  Labels: 11.0.2, Java, Windows
>
> The RollingFileAppender dosn't append to the current log file after restart 
> of Service at Windows.
> At UNIX Systems it works as expected.
> Our log4j2 Configuration:
>  
> {code:java}
> 
>  packages="de.uplanet.lucy.server.portalserver.messages" 
> shutdownHook="disable">
> 
>  log
> 
> 
> 
>  fileName="${sys:de.uplanet.lucy.logPath}/portal.log" 
> filePattern="${sys:de.uplanet.lucy.logPath}/portal.%d{-MM-dd}.log">
> 
> %-5p %d{ISO8601}{UTC}Z - %c[%t]%n %m%n
> 
> 
> 
> 
>  onMismatch="DENY"/>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> {code}
> If you have a new Installation it works as expected, after a few days we have 
> this behavior:
> Example at 16.04.2019:
> After an restart of the service, the content portal.log will be copied in a 
> file with that name portal.15-12-2018.log. the 15th december 2018 is the 
> creation date of the log folder where the logs are saved.
> And after that the old content in portal.log will be deleted.
> New log content will be logged in the empty portal.log
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2636) No default value for mdcId in SyslogAppender

[Filipp Gunbin (JIRA)]

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

Filipp Gunbin commented on LOG4J2-2636:
---

Yes, that's what I meant about 3rd point, but I really don't know about syslog 
enough to be sure

> No default value for mdcId in SyslogAppender
> 
>
> Key: LOG4J2-2636
> URL: https://issues.apache.org/jira/browse/LOG4J2-2636
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.11.2
>Reporter: Filipp Gunbin
>Priority: Major
>
> 1) Main issue
> When Rfc5424Layout is created from configuration, it seems to receive default 
> value:
> {code:java}
> @PluginAttribute(value = "mdcId", defaultString = DEFAULT_MDCID) final String 
> mdcId,{code}
> But SyslogAppender has it with no default:
> {code:java}
> @PluginBuilderAttribute("mdcId")
> private String mdcId;{code}
> It is used in SyslogAppender.build() to create Rfc5424Layout.  So, if I don't 
> specify "mdcId" attribute in " config element, I get this exception:
> {quote}ERROR StatusLogger Could not create plugin of type class 
> org.apache.logging.log4j.core.appender.SyslogAppender for element Syslog: 
> java.lang.IllegalArgumentException: No structured id name was supplied 
> java.lang.IllegalArgumentException: No structured id name was supplied at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:146)
>  at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:130)
>  at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.(Rfc5424Layout.java:142)
>  at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.createLayout(Rfc5424Layout.java:672)
>  at 
> org.apache.logging.log4j.core.appender.SyslogAppender$Builder.build(SyslogAppender.java:117)
>  at 
> org.apache.logging.log4j.core.appender.SyslogAppender$Builder.build(SyslogAppender.java:50)
> {quote}
> 2) Documentation doesn't mention mdcId of SyslogAppender at all: 
> [https://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender]
> If I build site locally with "mvn site" in 2.11.2, it's not there either.
> 3) Commit ce1183629fe89625a77872c7153853e7774502a6 
> (https://issues.apache.org/jira/browse/LOG4J2-922) which introduces default 
> value for mdcId in Rfc5424Layout has this code:
> {code:java}
> this.mdcId = id == null ? DEFAULT_MDCID : id;         
> this.mdcSdId = new StructuredDataId(mdcId, enterpriseNumber, null, 
> null);{code}
> While "this.mdcId" is set in first line, the argument (not class member) 
> mdcId is used in the second line.  Maybe argument mdcId should be used in the 
> first line instead of "id"?  Maybe this.mdcId should be used in the second 
> line instead of argument mdcId? I'm not familiar with the code enough to tell 
> for sure, it just feels suspicious to me.
> Thanks.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Jenkins build is unstable: Log4j 2 3.x #431

[Apache Jenkins Server]

See 

[jira] [Work logged] (LOG4J2-1301) Automatic reconfiguration with xml and xinclude

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1301?focusedWorklogId=264687=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-264687
 ]

ASF GitHub Bot logged work on LOG4J2-1301:
--

Author: ASF GitHub Bot
Created on: 21/Jun/19 14:42
Start Date: 21/Jun/19 14:42
Worklog Time Spent: 10m 
  Work Description: rgoers commented on issue #25: LOG4J2-1301 added 
optionalMonitorFiles attribute for automatic reconf…
URL: https://github.com/apache/logging-log4j2/pull/25#issuecomment-504451158
 
 
   In light of LOG4J2-494 and LOG4J2-913 this PR now has conflicts that would 
have to be resolved. This functionality should be achievable through the 
mechanisms implemented in those, although it doesn't specifically apply to 
XInclude.
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 264687)
Time Spent: 10m
Remaining Estimate: 0h

> Automatic reconfiguration with xml and xinclude
> ---
>
> Key: LOG4J2-1301
> URL: https://issues.apache.org/jira/browse/LOG4J2-1301
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alan Achtenberg
>Priority: Major
> Attachments: GroupFileConfigurationMonitor.java, 
> MyXmlConfiguration.java, MyXmlConfigurationFactory.java
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Automatic reconfiguration does not work with xinclude/xml.
> Modifying xinclude files is not detected as a file change on on the main 
> config file and as such it is not reconfigured when updates are made to files 
> included with xinclude (ie. log4j2-appenders.xml).
> Desired functionality would be to also listen for changes of files that are 
> included by main configuration file as well and update the configuration as 
> needed.
> An alternative would be to allow user to specify additional files to monitor 
> for changes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] [logging-log4j2] rgoers commented on issue #25: LOG4J2-1301 added optionalMonitorFiles attribute for automatic reconf…

[GitBox]

rgoers commented on issue #25: LOG4J2-1301 added optionalMonitorFiles attribute 
for automatic reconf…
URL: https://github.com/apache/logging-log4j2/pull/25#issuecomment-504451158
 
 
   In light of LOG4J2-494 and LOG4J2-913 this PR now has conflicts that would 
have to be resolved. This functionality should be achievable through the 
mechanisms implemented in those, although it doesn't specifically apply to 
XInclude.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (LOG4J2-1301) Automatic reconfiguration with xml and xinclude

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-1301:
-

Actually, CompositeConfiguration was implemented with LOG4J2-494.

> Automatic reconfiguration with xml and xinclude
> ---
>
> Key: LOG4J2-1301
> URL: https://issues.apache.org/jira/browse/LOG4J2-1301
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alan Achtenberg
>Priority: Major
> Attachments: GroupFileConfigurationMonitor.java, 
> MyXmlConfiguration.java, MyXmlConfigurationFactory.java
>
>
> Automatic reconfiguration does not work with xinclude/xml.
> Modifying xinclude files is not detected as a file change on on the main 
> config file and as such it is not reconfigured when updates are made to files 
> included with xinclude (ie. log4j2-appenders.xml).
> Desired functionality would be to also listen for changes of files that are 
> included by main configuration file as well and update the configuration as 
> needed.
> An alternative would be to allow user to specify additional files to monitor 
> for changes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Jenkins build is unstable: Log4j 2 2.x #3934

[Apache Jenkins Server]

See 

[jira] [Closed] (LOG4J2-2638) Add and use method org.apache.logging.log4j.message.MapMessage.toKey(String) for simpler subclasses

[Gary Gregory (JIRA)]

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

Gary Gregory closed LOG4J2-2638.

   Resolution: Fixed
 Assignee: Gary Gregory
Fix Version/s: 2.12.0
   3.0.0

> Add and use method org.apache.logging.log4j.message.MapMessage.toKey(String) 
> for simpler subclasses
> ---
>
> Key: LOG4J2-2638
> URL: https://issues.apache.org/jira/browse/LOG4J2-2638
> Project: Log4j 2
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.0.0, 2.12.0
>
>
> Add and use method a new method 
> {{org.apache.logging.log4j.message.MapMessage.toKey(String)}} for simpler 
> subclasses:
> {code:java}
>     /**
>  * Allows subclasses to change a candidate key to an actual key.
>  * 
>  * @param candidateKey The candidate key.
>  * @return The candidate key.
>  * @since 2.12
>  */
>     protected String toKey(final String candidateKey) {
>         return candidateKey;
>     }
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (LOG4J2-2636) No default value for mdcId in SyslogAppender

[Gary Gregory (JIRA)]

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

Gary Gregory edited comment on LOG4J2-2636 at 6/21/19 2:09 PM:
---

How about:
{code}
diff --git 
a/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/Rfc5424Layout.java
 
b/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/Rfc5424Layout.java
index f019e84..374e6a4 100644
--- 
a/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/Rfc5424Layout.java
+++ 
b/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/Rfc5424Layout.java
@@ -138,8 +138,8 @@
 this.includeMdc = includeMDC;
 this.includeNewLine = includeNL;
 this.escapeNewLine = escapeNL == null ? null : 
Matcher.quoteReplacement(escapeNL);
-this.mdcId = id == null ? DEFAULT_MDCID : id;
-this.mdcSdId = new StructuredDataId(mdcId, enterpriseNumber, null, 
null);
+this.mdcId = mdcId == null ? DEFAULT_MDCID : mdcId;
+this.mdcSdId = new StructuredDataId(this.mdcId, enterpriseNumber, 
null, null);
 this.mdcPrefix = mdcPrefix;
 this.eventPrefix = eventPrefix;
 this.appName = appName;
{code}
?


was (Author: garydgregory):
How about:
{code:diff}
diff --git 
a/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/Rfc5424Layout.java
 
b/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/Rfc5424Layout.java
index f019e84..374e6a4 100644
--- 
a/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/Rfc5424Layout.java
+++ 
b/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/Rfc5424Layout.java
@@ -138,8 +138,8 @@
 this.includeMdc = includeMDC;
 this.includeNewLine = includeNL;
 this.escapeNewLine = escapeNL == null ? null : 
Matcher.quoteReplacement(escapeNL);
-this.mdcId = id == null ? DEFAULT_MDCID : id;
-this.mdcSdId = new StructuredDataId(mdcId, enterpriseNumber, null, 
null);
+this.mdcId = mdcId == null ? DEFAULT_MDCID : mdcId;
+this.mdcSdId = new StructuredDataId(this.mdcId, enterpriseNumber, 
null, null);
 this.mdcPrefix = mdcPrefix;
 this.eventPrefix = eventPrefix;
 this.appName = appName;
{code}
?

> No default value for mdcId in SyslogAppender
> 
>
> Key: LOG4J2-2636
> URL: https://issues.apache.org/jira/browse/LOG4J2-2636
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.11.2
>Reporter: Filipp Gunbin
>Priority: Major
>
> 1) Main issue
> When Rfc5424Layout is created from configuration, it seems to receive default 
> value:
> {code:java}
> @PluginAttribute(value = "mdcId", defaultString = DEFAULT_MDCID) final String 
> mdcId,{code}
> But SyslogAppender has it with no default:
> {code:java}
> @PluginBuilderAttribute("mdcId")
> private String mdcId;{code}
> It is used in SyslogAppender.build() to create Rfc5424Layout.  So, if I don't 
> specify "mdcId" attribute in " config element, I get this exception:
> {quote}ERROR StatusLogger Could not create plugin of type class 
> org.apache.logging.log4j.core.appender.SyslogAppender for element Syslog: 
> java.lang.IllegalArgumentException: No structured id name was supplied 
> java.lang.IllegalArgumentException: No structured id name was supplied at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:146)
>  at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:130)
>  at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.(Rfc5424Layout.java:142)
>  at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.createLayout(Rfc5424Layout.java:672)
>  at 
> org.apache.logging.log4j.core.appender.SyslogAppender$Builder.build(SyslogAppender.java:117)
>  at 
> org.apache.logging.log4j.core.appender.SyslogAppender$Builder.build(SyslogAppender.java:50)
> {quote}
> 2) Documentation doesn't mention mdcId of SyslogAppender at all: 
> [https://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender]
> If I build site locally with "mvn site" in 2.11.2, it's not there either.
> 3) Commit ce1183629fe89625a77872c7153853e7774502a6 
> (https://issues.apache.org/jira/browse/LOG4J2-922) which introduces default 
> value for mdcId in Rfc5424Layout has this code:
> {code:java}
> this.mdcId = id == null ? DEFAULT_MDCID : id;         
> this.mdcSdId = new StructuredDataId(mdcId, enterpriseNumber, null, 
> null);{code}
> While "this.mdcId" is set in first line, the argument (not class member) 
> mdcId is used in the second line.  Maybe argument mdcId should be used in the 
> first line instead of "id"?  Maybe this.mdcId should be used in the second 
> line instead of argument mdcId? I'm not familiar with the code enough to tell 
> for sure, it just feels suspicious to me.
> Thanks.
>  



--
This 

[jira] [Commented] (LOG4J2-2636) No default value for mdcId in SyslogAppender

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-2636:
--

How about:
{code:diff}
diff --git 
a/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/Rfc5424Layout.java
 
b/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/Rfc5424Layout.java
index f019e84..374e6a4 100644
--- 
a/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/Rfc5424Layout.java
+++ 
b/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/Rfc5424Layout.java
@@ -138,8 +138,8 @@
 this.includeMdc = includeMDC;
 this.includeNewLine = includeNL;
 this.escapeNewLine = escapeNL == null ? null : 
Matcher.quoteReplacement(escapeNL);
-this.mdcId = id == null ? DEFAULT_MDCID : id;
-this.mdcSdId = new StructuredDataId(mdcId, enterpriseNumber, null, 
null);
+this.mdcId = mdcId == null ? DEFAULT_MDCID : mdcId;
+this.mdcSdId = new StructuredDataId(this.mdcId, enterpriseNumber, 
null, null);
 this.mdcPrefix = mdcPrefix;
 this.eventPrefix = eventPrefix;
 this.appName = appName;
{code}
?

> No default value for mdcId in SyslogAppender
> 
>
> Key: LOG4J2-2636
> URL: https://issues.apache.org/jira/browse/LOG4J2-2636
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.11.2
>Reporter: Filipp Gunbin
>Priority: Major
>
> 1) Main issue
> When Rfc5424Layout is created from configuration, it seems to receive default 
> value:
> {code:java}
> @PluginAttribute(value = "mdcId", defaultString = DEFAULT_MDCID) final String 
> mdcId,{code}
> But SyslogAppender has it with no default:
> {code:java}
> @PluginBuilderAttribute("mdcId")
> private String mdcId;{code}
> It is used in SyslogAppender.build() to create Rfc5424Layout.  So, if I don't 
> specify "mdcId" attribute in " config element, I get this exception:
> {quote}ERROR StatusLogger Could not create plugin of type class 
> org.apache.logging.log4j.core.appender.SyslogAppender for element Syslog: 
> java.lang.IllegalArgumentException: No structured id name was supplied 
> java.lang.IllegalArgumentException: No structured id name was supplied at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:146)
>  at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:130)
>  at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.(Rfc5424Layout.java:142)
>  at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.createLayout(Rfc5424Layout.java:672)
>  at 
> org.apache.logging.log4j.core.appender.SyslogAppender$Builder.build(SyslogAppender.java:117)
>  at 
> org.apache.logging.log4j.core.appender.SyslogAppender$Builder.build(SyslogAppender.java:50)
> {quote}
> 2) Documentation doesn't mention mdcId of SyslogAppender at all: 
> [https://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender]
> If I build site locally with "mvn site" in 2.11.2, it's not there either.
> 3) Commit ce1183629fe89625a77872c7153853e7774502a6 
> (https://issues.apache.org/jira/browse/LOG4J2-922) which introduces default 
> value for mdcId in Rfc5424Layout has this code:
> {code:java}
> this.mdcId = id == null ? DEFAULT_MDCID : id;         
> this.mdcSdId = new StructuredDataId(mdcId, enterpriseNumber, null, 
> null);{code}
> While "this.mdcId" is set in first line, the argument (not class member) 
> mdcId is used in the second line.  Maybe argument mdcId should be used in the 
> first line instead of "id"?  Maybe this.mdcId should be used in the second 
> line instead of argument mdcId? I'm not familiar with the code enough to tell 
> for sure, it just feels suspicious to me.
> Thanks.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2634) AsyncLogger method bytecode should be reduced to 35 bytes for fast inlining

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LOG4J2-2634:
-

Commit 19cc11d505b884cbcccdf643503d05d3965f8001 in logging-log4j2's branch 
refs/heads/master from Gary Gregory
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=19cc11d ]

[LOG4J2-2634] Add and use method
org.apache.logging.log4j.message.MapMessage.toKey(String) for simpler
subclasses.

Also remove trailing whitepace.

> AsyncLogger method bytecode should be reduced to 35 bytes for fast inlining
> ---
>
> Key: LOG4J2-2634
> URL: https://issues.apache.org/jira/browse/LOG4J2-2634
> Project: Log4j 2
>  Issue Type: Improvement
>Affects Versions: 2.11.2
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Minor
> Fix For: 2.12.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Large methods:
> AsyncLogger.logMessage conditional behavior produces a large method, this can 
> be broken into an abstraction which two implementations.
>  
> AsyncLogger.actualAsyncLog can be inlined in cases where Properties are not 
> set
> RingBufferLogEventHandler.onEvent callback notification makes sense in a 
> separate method so that both are below 35b



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2634) AsyncLogger method bytecode should be reduced to 35 bytes for fast inlining

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LOG4J2-2634:
-

Commit 0ca6501e1088f6f6fd9a270a2ec60eea5f87feb1 in logging-log4j2's branch 
refs/heads/release-2.x from Gary Gregory
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=0ca6501 ]

[LOG4J2-2634] Add and use method
org.apache.logging.log4j.message.MapMessage.toKey(String) for simpler
subclasses.

> AsyncLogger method bytecode should be reduced to 35 bytes for fast inlining
> ---
>
> Key: LOG4J2-2634
> URL: https://issues.apache.org/jira/browse/LOG4J2-2634
> Project: Log4j 2
>  Issue Type: Improvement
>Affects Versions: 2.11.2
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Minor
> Fix For: 2.12.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Large methods:
> AsyncLogger.logMessage conditional behavior produces a large method, this can 
> be broken into an abstraction which two implementations.
>  
> AsyncLogger.actualAsyncLog can be inlined in cases where Properties are not 
> set
> RingBufferLogEventHandler.onEvent callback notification makes sense in a 
> separate method so that both are below 35b



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (LOG4J2-2638) Add and use method org.apache.logging.log4j.message.MapMessage.toKey(String) for simpler subclasses

[Gary Gregory (JIRA)]

Gary Gregory created LOG4J2-2638:


 Summary: Add and use method 
org.apache.logging.log4j.message.MapMessage.toKey(String) for simpler subclasses
 Key: LOG4J2-2638
 URL: https://issues.apache.org/jira/browse/LOG4J2-2638
 Project: Log4j 2
  Issue Type: New Feature
Reporter: Gary Gregory


Add and use method a new method 
{{org.apache.logging.log4j.message.MapMessage.toKey(String)}} for simpler 
subclasses:

{code:java}
    /**
 * Allows subclasses to change a candidate key to an actual key.
 * 
 * @param candidateKey The candidate key.
 * @return The candidate key.
 * @since 2.12
 */
    protected String toKey(final String candidateKey) {
        return candidateKey;
    }
{code}
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2637) log4j-over-slf4j.jar and slf4j-log4j12.jar

[james601232 (JIRA)]

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

james601232 commented on LOG4J2-2637:
-

fine. thank u so much

> log4j-over-slf4j.jar and slf4j-log4j12.jar 
> ---
>
> Key: LOG4J2-2637
> URL: https://issues.apache.org/jira/browse/LOG4J2-2637
> Project: Log4j 2
>  Issue Type: Question
>  Components: Build
> Environment: jdk:
> 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)
> OS:CentOS
> CPU:x86
>  
>  
>Reporter: james601232
>Priority: Blocker
>
> I have a spring boot application and dependency log4j package.  
> slf4j-api-1.7.25.jar slf4j-log4j12-1.7.25.jar packages exists in lib 
> directory.  make me so puzzeld that the application worked fine. why? l 
> browser site and  found  slf4j-api-1.7.25.jar and  slf4j-log4j12-1.7.25.jar 
> can't _simultaneously exists. but why my application worked fine_



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (LOG4J2-2405) Better handling of %highlight pattern when using jul-bridge

[Marco Herrn (JIRA)]

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

Marco Herrn closed LOG4J2-2405.
---

> Better handling of %highlight pattern when using jul-bridge
> ---
>
> Key: LOG4J2-2405
> URL: https://issues.apache.org/jira/browse/LOG4J2-2405
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: JUL adapter, Lookups, Pattern Converters
>Affects Versions: 2.11.1
>Reporter: Marco Herrn
>Priority: Minor
> Fix For: 3.0.0, 2.11.2
>
> Attachments: jul-bridge-highlight.png
>
>
> When using the jul-bridge and %highlight in the pattern layout, LogLevels 
> that are not mapped to log4j LogLevels incorrectly display "null" in front of 
> the highlighted string.
> See the following pattern:
> {{pattern="%d %highlight{%-6p} [%c{1.}] (%t) %m%n"}}
> that should display the loglevel with color highlighting.
> The following log statements:
> {{
> LOGGER.log(Level.SEVERE, "SEVERE");
> LOGGER.log(Level.WARNING,"WARN");
> LOGGER.log(Level.INFO, "INFO");
> LOGGER.log(Level.FINE, "FINE");
> LOGGER.log(Level.FINER, "FINER");
> LOGGER.log(Level.FINEST, "FINEST");
> LOGGER.log(Level.CONFIG, "CONFIG");
> }}
> will be displayed as in the attached picture.
> As you can see the FINEST and CONFIG levels are not highlighted (which is 
> acceptable), but are prefixed by "null", which is not acceptable.
> I think it would be well enough to support setting the style for such unknown 
> log levels like:
> {{pattern="%d %highlight{%-6p}{FINEST=black, CONFIG=blue} [%c{1.}] (%t) 
> %m%n"}}
> This would also allow to set a color different than black for these log 
> levels.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (LOG4J2-2403) Allow zero padding the counter of a RollingFileAppender

[Marco Herrn (JIRA)]

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

Marco Herrn closed LOG4J2-2403.
---

> Allow zero padding the counter of a RollingFileAppender
> ---
>
> Key: LOG4J2-2403
> URL: https://issues.apache.org/jira/browse/LOG4J2-2403
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.11.1
>Reporter: Marco Herrn
>Priority: Minor
> Fix For: 2.12.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> 2It would be good if the filenamePattern for a RollingFileAppender would 
> allow to zero pad the counter. Either automatically based on the max number 
> of the counter or manually by giving the number of characters to pad to or 
> even both approaches.
> For example the current sitution is this:
>   
>  {{filepattern="logs/mylog-%i.log"
>  DefaultRolloverStrategy max="15"}}
>   
>  The files I get will be:
> {{hh-10.log.gz
>  hh-11.log.gz
>  hh-12.log.gz
>  hh-13.log.gz
>  hh-14.log.gz
>  hh-15.log.gz 
>  hh-1.log.gz
>  hh-2.log.gz
>  hh-3.log.gz
>  hh-4.log.gz
>  hh-5.log.gz
>  hh-6.log.gz
>  hh-7.log.gz
>  hh-8.log.gz
>  hh-9.log.gz
>  hh.log}}
> This is very ugly in file listings. Therefore I propose two things:
> 1. Automatic padding based on the "max" parameter to the RolloverStrategy. If 
> the max parameter has two digits (as in 15) it should automatically zero-pad 
> the counter to be two digits as well.
> 2. Manual padding based on the filepattern pattern to the 
> RollingFileAppender. At the moment it is possible to specify this as "%05i", 
> but this does no zero-padding as expected, but instead pads with whitespaces. 
> It should be possible to use zero-padding here too.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] [logging-log4j2] fgunbin commented on issue #283: LOG4J-2635: Fix java.version check in ThreadNameCachingStrategy

[GitBox]

fgunbin commented on issue #283: LOG4J-2635: Fix java.version check in 
ThreadNameCachingStrategy
URL: https://github.com/apache/logging-log4j2/pull/283#issuecomment-504414546
 
 
   Pushed the update, please check.  
   There's Travis failure somewhere in Log4j Sample Configuration Service 
build, and I cannot see the reason, could you help please?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Resolved] (LOG4J2-2637) log4j-over-slf4j.jar and slf4j-log4j12.jar

[Ralph Goers (JIRA)]

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

Ralph Goers resolved LOG4J2-2637.
-
Resolution: Invalid

The jars you are mentioning are part of slf4j, not Log4J. Please ask on their 
users list.

> log4j-over-slf4j.jar and slf4j-log4j12.jar 
> ---
>
> Key: LOG4J2-2637
> URL: https://issues.apache.org/jira/browse/LOG4J2-2637
> Project: Log4j 2
>  Issue Type: Question
>  Components: Build
> Environment: jdk:
> 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)
> OS:CentOS
> CPU:x86
>  
>  
>Reporter: james601232
>Priority: Blocker
>
> I have a spring boot application and dependency log4j package.  
> slf4j-api-1.7.25.jar slf4j-log4j12-1.7.25.jar packages exists in lib 
> directory.  make me so puzzeld that the application worked fine. why? l 
> browser site and  found  slf4j-api-1.7.25.jar and  slf4j-log4j12-1.7.25.jar 
> can't _simultaneously exists. but why my application worked fine_



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (LOG4J2-2637) log4j-over-slf4j.jar and slf4j-log4j12.jar

[Ralph Goers (JIRA)]

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

Ralph Goers closed LOG4J2-2637.
---

> log4j-over-slf4j.jar and slf4j-log4j12.jar 
> ---
>
> Key: LOG4J2-2637
> URL: https://issues.apache.org/jira/browse/LOG4J2-2637
> Project: Log4j 2
>  Issue Type: Question
>  Components: Build
> Environment: jdk:
> 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)
> OS:CentOS
> CPU:x86
>  
>  
>Reporter: james601232
>Priority: Blocker
>
> I have a spring boot application and dependency log4j package.  
> slf4j-api-1.7.25.jar slf4j-log4j12-1.7.25.jar packages exists in lib 
> directory.  make me so puzzeld that the application worked fine. why? l 
> browser site and  found  slf4j-api-1.7.25.jar and  slf4j-log4j12-1.7.25.jar 
> can't _simultaneously exists. but why my application worked fine_



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] [logging-log4j2] remkop commented on issue #283: LOG4J-2635: Fix java.version check in ThreadNameCachingStrategy

[GitBox]

remkop commented on issue #283: LOG4J-2635: Fix java.version check in 
ThreadNameCachingStrategy
URL: https://github.com/apache/logging-log4j2/pull/283#issuecomment-504393658
 
 
   Makes sense. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [logging-log4j2] carterkozak commented on issue #283: LOG4J-2635: Fix java.version check in ThreadNameCachingStrategy

[GitBox]

carterkozak commented on issue #283: LOG4J-2635: Fix java.version check in 
ThreadNameCachingStrategy
URL: https://github.com/apache/logging-log4j2/pull/283#issuecomment-504390983
 
 
   I think we can use the enum `name()` from `ThreadNameCachingStrategy` 
instead of defining new constants.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [logging-log4j2] remkop commented on issue #283: LOG4J-2635: Fix java.version check in ThreadNameCachingStrategy

[GitBox]

remkop commented on issue #283: LOG4J-2635: Fix java.version check in 
ThreadNameCachingStrategy
URL: https://github.com/apache/logging-log4j2/pull/283#issuecomment-504383978
 
 
   @fgunbin if these are only locally used I would prefer not to define them in 
`Constants` but just define them locally. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Created] (LOG4J2-2637) log4j-over-slf4j.jar and slf4j-log4j12.jar

[james601232 (JIRA)]

james601232 created LOG4J2-2637:
---

 Summary: log4j-over-slf4j.jar and slf4j-log4j12.jar 
 Key: LOG4J2-2637
 URL: https://issues.apache.org/jira/browse/LOG4J2-2637
 Project: Log4j 2
  Issue Type: Question
  Components: Build
 Environment: jdk:

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)

OS:CentOS

CPU:x86

 

 
Reporter: james601232


I have a spring boot application and dependency log4j package.  
slf4j-api-1.7.25.jar slf4j-log4j12-1.7.25.jar packages exists in lib directory. 
 make me so puzzeld that the application worked fine. why? l browser site and  
found  slf4j-api-1.7.25.jar and  slf4j-log4j12-1.7.25.jar can't _simultaneously 
exists. but why my application worked fine_



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] [logging-log4j2] fgunbin commented on issue #283: LOG4J-2635: Fix java.version check in ThreadNameCachingStrategy

[GitBox]

fgunbin commented on issue #283: LOG4J-2635: Fix java.version check in 
ThreadNameCachingStrategy
URL: https://github.com/apache/logging-log4j2/pull/283#issuecomment-504364852
 
 
   @garydgregory No problem, though I viewed duplication in test file as a kind 
of test that strings are right.
   Add to org.apache.logging.log4j.core.util.Constants, right?
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Comment Edited] (LOG4J2-2635) Wrong java.version check in ThreadNameCachingStrategy

[Filipp Gunbin (JIRA)]

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

Filipp Gunbin edited comment on LOG4J2-2635 at 6/21/19 9:21 AM:


Yes, here it is [https://github.com/apache/logging-log4j2/pull/283] . It's 
against release-2.x because I could not build master. The reason seems to be 
circular dependency in Maven, "cd log4j-core; mvn dependency:tree" shows this:
{quote}[INFO] +- com.vlkan.log4j2:log4j2-logstash-layout:jar:0.18:test
[INFO] \- com.github.ivandzf:log4j2-custom-layout:jar:1.1.0:compile
[INFO]+- org.apache.logging.log4j:log4j-core:jar:3.0.0-SNAPSHOT:compile
{quote}


was (Author: fgunbin):
Yes, here it is [https://github.com/apache/logging-log4j2/pull/283] . It's 
against release-2.x because I could not build master. The reason seems to be 
circular dependency in Maven, "cd log4j-core; mvn dependency:tree" shows this:
{quote}[INFO] +- com.vlkan.log4j2:log4j2-logstash-layout:jar:0.18:test
[INFO] \\- com.github.ivandzf:log4j2-custom-layout:jar:1.1.0:compile
[INFO]+- org.apache.logging.log4j:log4j-core:jar:3.0.0-SNAPSHOT:compile
{quote}

> Wrong java.version check in ThreadNameCachingStrategy
> -
>
> Key: LOG4J2-2635
> URL: https://issues.apache.org/jira/browse/LOG4J2-2635
> Project: Log4j 2
>  Issue Type: Bug
>Reporter: Filipp Gunbin
>Priority: Major
>
> I see this in ThreadNameCachingStrategy.java:
> {code:java}
> final String defaultStrategy = 
> System.getProperty("java.version").compareTo("1.8.0_102") < 0
>         ? "CACHED" // LOG4J2-2052 JDK 8u102 removed the String allocation in 
> Thread.getName()
>         : "UNCACHED";{code}
> This doesn't look right because java.version of, say, "1.8.0_77" compares 
> greater than "1.8.0_102" lexicographically.  This is why I have failed tests 
> when trying to build log4j-core.
> Similar check is also present in AsyncLoggerThreadNameStrategyTest.java.
> This was initially added in https://issues.apache.org/jira/browse/LOG4J2-2052
> [posted this on dev mailing list first, but got no response, so creating 
> issue here]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (LOG4J2-2635) Wrong java.version check in ThreadNameCachingStrategy

[Filipp Gunbin (JIRA)]

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

Filipp Gunbin edited comment on LOG4J2-2635 at 6/21/19 9:21 AM:


Yes, here it is [https://github.com/apache/logging-log4j2/pull/283] . It's 
against release-2.x because I could not build master. The reason seems to be 
circular dependency in Maven, "cd log4j-core; mvn dependency:tree" shows this:
{quote}[INFO] +- com.vlkan.log4j2:log4j2-logstash-layout:jar:0.18:test
[INFO] \\- com.github.ivandzf:log4j2-custom-layout:jar:1.1.0:compile
[INFO]+- org.apache.logging.log4j:log4j-core:jar:3.0.0-SNAPSHOT:compile
{quote}


was (Author: fgunbin):
Yes, here it is [https://github.com/apache/logging-log4j2/pull/283] . It's 
against release-2.x because I could not build master. The reason seems to be 
circular dependency in Maven, "cd log4j-core; mvn dependency:tree" shows this:
{quote}[INFO] +- com.vlkan.log4j2:log4j2-logstash-layout:jar:0.18:test
[INFO] \- com.github.ivandzf:log4j2-custom-layout:jar:1.1.0:compile
[INFO]+- org.apache.logging.log4j:log4j-core:jar:3.0.0-SNAPSHOT:compile
{quote}

> Wrong java.version check in ThreadNameCachingStrategy
> -
>
> Key: LOG4J2-2635
> URL: https://issues.apache.org/jira/browse/LOG4J2-2635
> Project: Log4j 2
>  Issue Type: Bug
>Reporter: Filipp Gunbin
>Priority: Major
>
> I see this in ThreadNameCachingStrategy.java:
> {code:java}
> final String defaultStrategy = 
> System.getProperty("java.version").compareTo("1.8.0_102") < 0
>         ? "CACHED" // LOG4J2-2052 JDK 8u102 removed the String allocation in 
> Thread.getName()
>         : "UNCACHED";{code}
> This doesn't look right because java.version of, say, "1.8.0_77" compares 
> greater than "1.8.0_102" lexicographically.  This is why I have failed tests 
> when trying to build log4j-core.
> Similar check is also present in AsyncLoggerThreadNameStrategyTest.java.
> This was initially added in https://issues.apache.org/jira/browse/LOG4J2-2052
> [posted this on dev mailing list first, but got no response, so creating 
> issue here]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (LOG4J2-2635) Wrong java.version check in ThreadNameCachingStrategy

[Filipp Gunbin (JIRA)]

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

Filipp Gunbin edited comment on LOG4J2-2635 at 6/21/19 9:21 AM:


Yes, here it is [https://github.com/apache/logging-log4j2/pull/283] . It's 
against release-2.x because I could not build master. The reason seems to be 
circular dependency in Maven, "cd log4j-core; mvn dependency:tree" shows this:
{quote}[INFO] +- com.vlkan.log4j2:log4j2-logstash-layout:jar:0.18:test
[INFO] \- com.github.ivandzf:log4j2-custom-layout:jar:1.1.0:compile
[INFO]+- org.apache.logging.log4j:log4j-core:jar:3.0.0-SNAPSHOT:compile
{quote}


was (Author: fgunbin):
Yes, here it is [https://github.com/apache/logging-log4j2/pull/283] . It's 
against release-2.x because I could not build master. The reason seems to be 
circular dependency in Maven, "cd log4j-core; mvn dependency:tree" shows this:
{quote}[INFO] +- com.vlkan.log4j2:log4j2-logstash-layout:jar:0.18:test
 [INFO] - com.github.ivandzf:log4j2-custom-layout:jar:1.1.0:compile
 [INFO]    +- org.apache.logging.log4j:log4j-core:jar:3.0.0-SNAPSHOT:compile
{quote}

> Wrong java.version check in ThreadNameCachingStrategy
> -
>
> Key: LOG4J2-2635
> URL: https://issues.apache.org/jira/browse/LOG4J2-2635
> Project: Log4j 2
>  Issue Type: Bug
>Reporter: Filipp Gunbin
>Priority: Major
>
> I see this in ThreadNameCachingStrategy.java:
> {code:java}
> final String defaultStrategy = 
> System.getProperty("java.version").compareTo("1.8.0_102") < 0
>         ? "CACHED" // LOG4J2-2052 JDK 8u102 removed the String allocation in 
> Thread.getName()
>         : "UNCACHED";{code}
> This doesn't look right because java.version of, say, "1.8.0_77" compares 
> greater than "1.8.0_102" lexicographically.  This is why I have failed tests 
> when trying to build log4j-core.
> Similar check is also present in AsyncLoggerThreadNameStrategyTest.java.
> This was initially added in https://issues.apache.org/jira/browse/LOG4J2-2052
> [posted this on dev mailing list first, but got no response, so creating 
> issue here]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (LOG4J2-2635) Wrong java.version check in ThreadNameCachingStrategy

[Filipp Gunbin (JIRA)]

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

Filipp Gunbin edited comment on LOG4J2-2635 at 6/21/19 9:20 AM:


Yes, here it is [https://github.com/apache/logging-log4j2/pull/283] . It's 
against release-2.x because I could not build master. The reason seems to be 
circular dependency in Maven, "cd log4j-core; mvn dependency:tree" shows this:
{quote}[INFO] +- com.vlkan.log4j2:log4j2-logstash-layout:jar:0.18:test
 [INFO] - com.github.ivandzf:log4j2-custom-layout:jar:1.1.0:compile
 [INFO]    +- org.apache.logging.log4j:log4j-core:jar:3.0.0-SNAPSHOT:compile
{quote}


was (Author: fgunbin):
Yes, here it is [https://github.com/apache/logging-log4j2/pull/283] . It's 
against release-2.x because I could not build master. The reason seems to be 
circular dependency in Maven, "cd log4j-core; mvn dependency:tree" shows this:
{code:java}
[INFO] +- com.vlkan.log4j2:log4j2-logstash-layout:jar:0.18:test
[INFO] \- com.github.ivandzf:log4j2-custom-layout:jar:1.1.0:compile
[INFO]    +- 
org.apache.logging.log4j:log4j-core:jar:3.0.0-SNAPSHOT:compile{code}
 

(

> Wrong java.version check in ThreadNameCachingStrategy
> -
>
> Key: LOG4J2-2635
> URL: https://issues.apache.org/jira/browse/LOG4J2-2635
> Project: Log4j 2
>  Issue Type: Bug
>Reporter: Filipp Gunbin
>Priority: Major
>
> I see this in ThreadNameCachingStrategy.java:
> {code:java}
> final String defaultStrategy = 
> System.getProperty("java.version").compareTo("1.8.0_102") < 0
>         ? "CACHED" // LOG4J2-2052 JDK 8u102 removed the String allocation in 
> Thread.getName()
>         : "UNCACHED";{code}
> This doesn't look right because java.version of, say, "1.8.0_77" compares 
> greater than "1.8.0_102" lexicographically.  This is why I have failed tests 
> when trying to build log4j-core.
> Similar check is also present in AsyncLoggerThreadNameStrategyTest.java.
> This was initially added in https://issues.apache.org/jira/browse/LOG4J2-2052
> [posted this on dev mailing list first, but got no response, so creating 
> issue here]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LOG4J2-2635) Wrong java.version check in ThreadNameCachingStrategy

[Filipp Gunbin (JIRA)]

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

Filipp Gunbin commented on LOG4J2-2635:
---

Yes, here it is [https://github.com/apache/logging-log4j2/pull/283] . It's 
against release-2.x because I could not build master. The reason seems to be 
circular dependency in Maven, "cd log4j-core; mvn dependency:tree" shows this:
{code:java}
[INFO] +- com.vlkan.log4j2:log4j2-logstash-layout:jar:0.18:test
[INFO] \- com.github.ivandzf:log4j2-custom-layout:jar:1.1.0:compile
[INFO]    +- 
org.apache.logging.log4j:log4j-core:jar:3.0.0-SNAPSHOT:compile{code}
 

(

> Wrong java.version check in ThreadNameCachingStrategy
> -
>
> Key: LOG4J2-2635
> URL: https://issues.apache.org/jira/browse/LOG4J2-2635
> Project: Log4j 2
>  Issue Type: Bug
>Reporter: Filipp Gunbin
>Priority: Major
>
> I see this in ThreadNameCachingStrategy.java:
> {code:java}
> final String defaultStrategy = 
> System.getProperty("java.version").compareTo("1.8.0_102") < 0
>         ? "CACHED" // LOG4J2-2052 JDK 8u102 removed the String allocation in 
> Thread.getName()
>         : "UNCACHED";{code}
> This doesn't look right because java.version of, say, "1.8.0_77" compares 
> greater than "1.8.0_102" lexicographically.  This is why I have failed tests 
> when trying to build log4j-core.
> Similar check is also present in AsyncLoggerThreadNameStrategyTest.java.
> This was initially added in https://issues.apache.org/jira/browse/LOG4J2-2052
> [posted this on dev mailing list first, but got no response, so creating 
> issue here]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] [logging-log4j2] fgunbin opened a new pull request #283: LOG4J-2635: Fix java.version check in ThreadNameCachingStrategy

[GitBox]

fgunbin opened a new pull request #283: LOG4J-2635: Fix java.version check in 
ThreadNameCachingStrategy
URL: https://github.com/apache/logging-log4j2/pull/283
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services