[jira] [Closed] (LOG4J2-1932) Add containsKey() method to class org.apache.logging.log4j.message.MapMessage

2017-06-02 Thread Gary Gregory (JIRA)
[ https://issues.apache.org/jira/browse/LOG4J2-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-1932. Resolution: Fixed Fix Version/s: 2.9 commit 864b7a83ecf2c7eb9ae0d7c7bdf98a14c5f277d6. > Add

[jira] [Commented] (LOG4J2-1932) Add containsKey() method to class org.apache.logging.log4j.message.MapMessage

2017-06-02 Thread ASF subversion and git services (JIRA)
[ https://issues.apache.org/jira/browse/LOG4J2-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035551#comment-16035551 ] ASF subversion and git services commented on LOG4J2-1932: - Commit

[jira] [Updated] (LOG4J2-1932) Add containsKey() method to class org.apache.logging.log4j.message.MapMessage

2017-06-02 Thread Gary Gregory (JIRA)
[ https://issues.apache.org/jira/browse/LOG4J2-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LOG4J2-1932: - Description: Add the method {{containsKey()}} method to class {{org.apache.logging.log4j.message

[jira] [Created] (LOG4J2-1932) Add containsKey() method to class org.apache.logging.log4j.message.MapMessage

2017-06-02 Thread Gary Gregory (JIRA)
Gary Gregory created LOG4J2-1932: Summary: Add containsKey() method to class org.apache.logging.log4j.message.MapMessage Key: LOG4J2-1932 URL: https://issues.apache.org/jira/browse/LOG4J2-1932 Project

Re: [log4j2] org.apache.logging.log4j.message.MapMessage String vs. Object values.

2017-06-02 Thread Ralph Goers
From a backward compatibility point of view changing that would be a problem. Also, StructuredDataMessage extends MapMessage and expects a String. That said, there must be a way to make it generic but have the default be a String. For example, you could create a GenericMapMessage that expects

[log4j2] org.apache.logging.log4j.message.MapMessage String vs. Object values.

2017-06-02 Thread Gary Gregory
Hi All: We make a big deal that our logger APIs take Object messages instead of Strings, but over in org.apache.logging.log4j.message.MapMessage the values are Strings, not Objects. Is that deliberate? That's proving to be a restriction for me... Any thoughts on allowing for the same kind of ty

[jira] [Updated] (LOG4J2-1931) Wrong Date is calculated for rollover filePattern with timezone parameter

2017-06-02 Thread Arakha (JIRA)
} calculated date is wrong. current date is : 20170602 but the calculated one while rolling over is : 20170601 , file name: rollapp-20170601-1.log Configurations used are: %d{HH:mm:ss.SSS}{UTC+0} %p %c{1.} [%t] %m%n it may be

[jira] [Updated] (LOG4J2-1931) Wrong Date is calculated for rollover filePattern with timezone parameter

2017-06-02 Thread Arakha (JIRA)
} calculated date is wrong. current date is : 20170602 but the calculated one while rolling over is : 20170601 , file name: rollapp-20170601-1.log Configurations used are: %d{HH:mm:ss.SSS}{UTC+0} %p %c{1.} [%t] %m%n it may be

[jira] [Updated] (LOG4J2-1931) Wrong Date is calculated for rollover filePattern with timezone parameter

2017-06-02 Thread Arakha (JIRA)
/temp/logs/${date:-MM}-test/rollapp-%d{MMdd}{UTC+0}-%i.log" due to {UTC+0} calculated date is wrong. current date is : 20170602 but the calculated one while rolling over is : 20170601 , file name: rollapp-20170601-1.log Configurations used are: %d{HH:mm:ss.SSS}{UTC

[jira] [Created] (LOG4J2-1931) Wrong Date is calculated for rollover filePattern with timezone parameter

2017-06-02 Thread Arakha (JIRA)
}-test/rollapp-%d{MMdd}{UTC+0}-%i.log due to {UTC+0} calculated date is wrong. current date is : 20170602 but the calculated one while rolling over is : 20170601 , file name: rollapp-20170601-1.log Configurations used are: %d{HH:mm:ss.SSS}{UTC+0} %p %c{1.} [%t] %m%n