[jira] [Commented] (LOG4J2-1883) Timestamp does not seem to support microseconds level
[
https://issues.apache.org/jira/browse/LOG4J2-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16315531#comment-16315531
]
Remko Popma commented on LOG4J2-1883:
-
I meant to make log4j-core a multi-release jar. This only works with Java 9+.
On the other hand, moving to Java 8 is on the roadmap and is not that far off.
From memory I believe it was 2019 that Java 7 becomes EOL and we agreed that
would be the time to start requiring Java 8.
But for this ticket we need to make log4j-core a Java 9 multi-release jar.
> Timestamp does not seem to support microseconds level
> -
>
> Key: LOG4J2-1883
> URL: https://issues.apache.org/jira/browse/LOG4J2-1883
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
> Environment: Linux with any JDK including JDK1.8
>Reporter: Madhava Dass
>Assignee: Remko Popma
>Priority: Critical
>
> Used log4j and 'log4j2.xml' to configure timestamp format as:
> {code}
>
>
>
>
> pattern="[%d{-MM-dd'T'HH:mm:ss.SSSXXX}{UTC}][%level][%logger{36}]:%msg%n"/>
>
>
>
>
>
>
>
>
> {code}
> This pattern produces the time stamp as:
> {code}
> [2017-03-29T13:55:28.363000][null]:[Thread-1]: -
> {code}
> The desired output is:
> {code}
> [2017-03-29T13:55:28.363701-07:00][null]:[Thread-1]: -
> {code}
> Different versions of JDKs were tried including JDK 1.8. It does not seem to
> make any difference in the outcome.
> Is there a way to get the desired time stamp through pattern matching
> configuration in the '*.xml' file?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-1883) Timestamp does not seem to support microseconds level
[
https://issues.apache.org/jira/browse/LOG4J2-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16315413#comment-16315413
]
Gary Gregory commented on LOG4J2-1883:
--
That's a Java 8 API BTW even though the precision is best on Java 9. IMO
the module should be named based on the Java API level.
OTOH, I am OK with moving the whole project to Java 8.
Gary
> Timestamp does not seem to support microseconds level
> -
>
> Key: LOG4J2-1883
> URL: https://issues.apache.org/jira/browse/LOG4J2-1883
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
> Environment: Linux with any JDK including JDK1.8
>Reporter: Madhava Dass
>Assignee: Remko Popma
>Priority: Critical
>
> Used log4j and 'log4j2.xml' to configure timestamp format as:
> {code}
>
>
>
>
> pattern="[%d{-MM-dd'T'HH:mm:ss.SSSXXX}{UTC}][%level][%logger{36}]:%msg%n"/>
>
>
>
>
>
>
>
>
> {code}
> This pattern produces the time stamp as:
> {code}
> [2017-03-29T13:55:28.363000][null]:[Thread-1]: -
> {code}
> The desired output is:
> {code}
> [2017-03-29T13:55:28.363701-07:00][null]:[Thread-1]: -
> {code}
> Different versions of JDKs were tried including JDK 1.8. It does not seem to
> make any difference in the outcome.
> Is there a way to get the desired time stamp through pattern matching
> configuration in the '*.xml' file?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-1883) Timestamp does not seem to support microseconds level
[
https://issues.apache.org/jira/browse/LOG4J2-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16315383#comment-16315383
]
Remko Popma commented on LOG4J2-1883:
-
I've started to work on this.
We will likely need a {{log4j-core-java9}} module to get the value of
[Instant.now()|https://docs.oracle.com/javase/9/docs/api/java/time/Instant.html#now--].
> Timestamp does not seem to support microseconds level
> -
>
> Key: LOG4J2-1883
> URL: https://issues.apache.org/jira/browse/LOG4J2-1883
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
> Environment: Linux with any JDK including JDK1.8
>Reporter: Madhava Dass
>Assignee: Remko Popma
>Priority: Critical
>
> Used log4j and 'log4j2.xml' to configure timestamp format as:
> {code}
>
>
>
>
> pattern="[%d{-MM-dd'T'HH:mm:ss.SSSXXX}{UTC}][%level][%logger{36}]:%msg%n"/>
>
>
>
>
>
>
>
>
> {code}
> This pattern produces the time stamp as:
> {code}
> [2017-03-29T13:55:28.363000][null]:[Thread-1]: -
> {code}
> The desired output is:
> {code}
> [2017-03-29T13:55:28.363701-07:00][null]:[Thread-1]: -
> {code}
> Different versions of JDKs were tried including JDK 1.8. It does not seem to
> make any difference in the outcome.
> Is there a way to get the desired time stamp through pattern matching
> configuration in the '*.xml' file?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Work started] (LOG4J2-1883) Timestamp does not seem to support microseconds level
[
https://issues.apache.org/jira/browse/LOG4J2-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on LOG4J2-1883 started by Remko Popma.
---
> Timestamp does not seem to support microseconds level
> -
>
> Key: LOG4J2-1883
> URL: https://issues.apache.org/jira/browse/LOG4J2-1883
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
> Environment: Linux with any JDK including JDK1.8
>Reporter: Madhava Dass
>Assignee: Remko Popma
>Priority: Critical
>
> Used log4j and 'log4j2.xml' to configure timestamp format as:
> {code}
>
>
>
>
> pattern="[%d{-MM-dd'T'HH:mm:ss.SSSXXX}{UTC}][%level][%logger{36}]:%msg%n"/>
>
>
>
>
>
>
>
>
> {code}
> This pattern produces the time stamp as:
> {code}
> [2017-03-29T13:55:28.363000][null]:[Thread-1]: -
> {code}
> The desired output is:
> {code}
> [2017-03-29T13:55:28.363701-07:00][null]:[Thread-1]: -
> {code}
> Different versions of JDKs were tried including JDK 1.8. It does not seem to
> make any difference in the outcome.
> Is there a way to get the desired time stamp through pattern matching
> configuration in the '*.xml' file?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (LOG4J2-2158) ThreadContext map is cleared => entries are only available for one log event
[
https://issues.apache.org/jira/browse/LOG4J2-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved LOG4J2-2158.
-
Resolution: Fixed
Fix Version/s: 2.10.1
Thanks for the contribution!
Merged into master. Please verify and close this ticket.
> ThreadContext map is cleared => entries are only available for one log event
>
>
> Key: LOG4J2-2158
> URL: https://issues.apache.org/jira/browse/LOG4J2-2158
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Björn Kautler
>Assignee: Remko Popma
>Priority: Critical
> Fix For: 2.10.1
>
>
> In
> {{org.apache.logging.log4j.core.impl.ThreadContextDataInjector.ForCopyOnWriteThreadContextMap.injectContextData}}
> without properties set, the result of
> {{ThreadContext.getThreadContextMap().getReadOnlyContextData()}} is returned
> which was saved in a variable called {{immutableCopy}}.
> {{org.apache.logging.log4j.core.impl.ReusableLogEventFactory.createEvent}}
> calls {{result.clear()}} on that context data when the next log event is
> created.
> Unfortunately the "immutable" copy is not immutable at all, but is cleared on
> the this call and all thread context map entries are lost.
> If I set a {{Property}} on all loggers in the config, then the thread context
> map entries are not cleared, because the internal string map is not given out
> but the entries copied, but that property is also logged then of course.
> If I instead set the system property {{log4j2.garbagefree.threadContextMap}},
> the thread context map entries are also not cleared, as then also the entries
> are copied and not the internal structure given out.
> From what I have seen, I'd say there is a {{immutableCopy.freeze()}} missing
> before the {{immutableCopy}} is returned inside the {{if}}-block.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] logging-log4j2 pull request #139: LOG4J2-2158 make inherited log event conte...
Github user asfgit closed the pull request at: https://github.com/apache/logging-log4j2/pull/139 ---
[jira] [Commented] (LOG4J2-2158) ThreadContext map is cleared => entries are only available for one log event
[
https://issues.apache.org/jira/browse/LOG4J2-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16315198#comment-16315198
]
ASF GitHub Bot commented on LOG4J2-2158:
Github user asfgit closed the pull request at:
https://github.com/apache/logging-log4j2/pull/139
> ThreadContext map is cleared => entries are only available for one log event
>
>
> Key: LOG4J2-2158
> URL: https://issues.apache.org/jira/browse/LOG4J2-2158
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Björn Kautler
>Assignee: Remko Popma
>Priority: Critical
>
> In
> {{org.apache.logging.log4j.core.impl.ThreadContextDataInjector.ForCopyOnWriteThreadContextMap.injectContextData}}
> without properties set, the result of
> {{ThreadContext.getThreadContextMap().getReadOnlyContextData()}} is returned
> which was saved in a variable called {{immutableCopy}}.
> {{org.apache.logging.log4j.core.impl.ReusableLogEventFactory.createEvent}}
> calls {{result.clear()}} on that context data when the next log event is
> created.
> Unfortunately the "immutable" copy is not immutable at all, but is cleared on
> the this call and all thread context map entries are lost.
> If I set a {{Property}} on all loggers in the config, then the thread context
> map entries are not cleared, because the internal string map is not given out
> but the entries copied, but that property is also logged then of course.
> If I instead set the system property {{log4j2.garbagefree.threadContextMap}},
> the thread context map entries are also not cleared, as then also the entries
> are copied and not the internal structure given out.
> From what I have seen, I'd say there is a {{immutableCopy.freeze()}} missing
> before the {{immutableCopy}} is returned inside the {{if}}-block.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2158) ThreadContext map is cleared => entries are only available for one log event
[
https://issues.apache.org/jira/browse/LOG4J2-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16315197#comment-16315197
]
ASF subversion and git services commented on LOG4J2-2158:
-
Commit 2352052d0bc797ede29a5b4a8897200aa49a8c43 in logging-log4j2's branch
refs/heads/master from rpopma
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=2352052 ]
LOG4J2-2158 (update change log) Fixed bug where ThreadContext map was cleared,
resulting in entries being only available for one log event.
> ThreadContext map is cleared => entries are only available for one log event
>
>
> Key: LOG4J2-2158
> URL: https://issues.apache.org/jira/browse/LOG4J2-2158
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Björn Kautler
>Assignee: Remko Popma
>Priority: Critical
>
> In
> {{org.apache.logging.log4j.core.impl.ThreadContextDataInjector.ForCopyOnWriteThreadContextMap.injectContextData}}
> without properties set, the result of
> {{ThreadContext.getThreadContextMap().getReadOnlyContextData()}} is returned
> which was saved in a variable called {{immutableCopy}}.
> {{org.apache.logging.log4j.core.impl.ReusableLogEventFactory.createEvent}}
> calls {{result.clear()}} on that context data when the next log event is
> created.
> Unfortunately the "immutable" copy is not immutable at all, but is cleared on
> the this call and all thread context map entries are lost.
> If I set a {{Property}} on all loggers in the config, then the thread context
> map entries are not cleared, because the internal string map is not given out
> but the entries copied, but that property is also logged then of course.
> If I instead set the system property {{log4j2.garbagefree.threadContextMap}},
> the thread context map entries are also not cleared, as then also the entries
> are copied and not the internal structure given out.
> From what I have seen, I'd say there is a {{immutableCopy.freeze()}} missing
> before the {{immutableCopy}} is returned inside the {{if}}-block.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2158) ThreadContext map is cleared => entries are only available for one log event
[
https://issues.apache.org/jira/browse/LOG4J2-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16315196#comment-16315196
]
ASF subversion and git services commented on LOG4J2-2158:
-
Commit f1f3945b707d8a590d2fb60624673484771b7d31 in logging-log4j2's branch
refs/heads/master from [~vampire]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=f1f3945 ]
LOG4J2-2158 make inherited log event context data immutable when using
CopyOnWriteThreadContextMap
> ThreadContext map is cleared => entries are only available for one log event
>
>
> Key: LOG4J2-2158
> URL: https://issues.apache.org/jira/browse/LOG4J2-2158
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.10.0
>Reporter: Björn Kautler
>Assignee: Remko Popma
>Priority: Critical
>
> In
> {{org.apache.logging.log4j.core.impl.ThreadContextDataInjector.ForCopyOnWriteThreadContextMap.injectContextData}}
> without properties set, the result of
> {{ThreadContext.getThreadContextMap().getReadOnlyContextData()}} is returned
> which was saved in a variable called {{immutableCopy}}.
> {{org.apache.logging.log4j.core.impl.ReusableLogEventFactory.createEvent}}
> calls {{result.clear()}} on that context data when the next log event is
> created.
> Unfortunately the "immutable" copy is not immutable at all, but is cleared on
> the this call and all thread context map entries are lost.
> If I set a {{Property}} on all loggers in the config, then the thread context
> map entries are not cleared, because the internal string map is not given out
> but the entries copied, but that property is also logged then of course.
> If I instead set the system property {{log4j2.garbagefree.threadContextMap}},
> the thread context map entries are also not cleared, as then also the entries
> are copied and not the internal structure given out.
> From what I have seen, I'd say there is a {{immutableCopy.freeze()}} missing
> before the {{immutableCopy}} is returned inside the {{if}}-block.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
