[jira] [Commented] (LOG4J2-3453) Filters contains invalid attributes "onMatch", "onMismatch"
[
https://issues.apache.org/jira/browse/LOG4J2-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515094#comment-17515094
]
Piotr Karwasz commented on LOG4J2-3453:
---
[~ana4]: yes, it should. The headaches that come with the properties format
will disappear too. :)
> Filters contains invalid attributes "onMatch", "onMismatch"
> ---
>
> Key: LOG4J2-3453
> URL: https://issues.apache.org/jira/browse/LOG4J2-3453
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Luning Wang
>Priority: Major
> Fix For: 2.17.2
>
>
> The following is my log4j2.properties
> {code:java}
> appender.console.filter.1.type = Filters
> appender.console.filter.1.a.type = ThresholdFilter
> appender.console.filter.1.a.level = info
> appender.console.filter.1.b.type = RegexFilter
> appender.console.filter.1.b.regex = .*Thrift error occurred during processing
> of message.*
> appender.console.filter.1.b.onMatch = deny
> appender.console.filter.1.b.onMismatch = neutral
> {code}
> When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
> `Filters contains invalid attributes "onMatch", "onMismatch"` error message.
> What is correctly conf?
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3455) Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
[ https://issues.apache.org/jira/browse/LOG4J2-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515087#comment-17515087 ] Pooja Pandey commented on LOG4J2-3455: -- Okay, thank you [~rgoers] for the suggestion and detailed explanation!! > Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work > -- > > Key: LOG4J2-3455 > URL: https://issues.apache.org/jira/browse/LOG4J2-3455 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > Attachments: CustomLogger.java, CustomLoggerFactory.java, > CustomMultiProcessRollingAppender.java, ThreadLevelLogThresholdTest.java, > customlog.properties > > > In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. > With bridge 2.17.2/2.17.3-SNAPSHOT, thread specific log level threshold > doesn't work which used to work earlier with log4j1.x. We had achieved this > feature by overriding getEffectiveLevel(), but now this doesn't work anymore > with log4j1.x bridge since the method getEffectiveLevel() is not getting > invoked to set effective level. > > For reference, Java class files for Custom Logger, Custom Multiprocess > Rolling Appender and Test program are attached along with cutom log4j > properties > file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3455) Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
[
https://issues.apache.org/jira/browse/LOG4J2-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515084#comment-17515084
]
Ralph Goers edited comment on LOG4J2-3455 at 3/31/22, 5:18 AM:
---
We are suggesting that you forget about your Log4j 1 customizations and focus
on what Log4j 2 provides out of the box. Instead, have your application do:
{code:java}
ThreadContext.put("LEVEL", threadLevel.toUpperCase());
{code}
Then you can use either the
[DynamicThresholdFilter|https://logging.apache.org/log4j/2.x/manual/filters.html#DynamicThresholdFilter]
{code:java}
{code}
or you can create your own custom Filter. You DO NOT need a custom Logger.
Note that it is quite common to create a servlet filter that inspects the
incoming headers and sets ThreadContext values accordingly, remembering to
clear it when the request completes.
was (Author: ralph.go...@dslextreme.com):
We are suggesting that you forget about your Log4j 1 customizations and focus
on what Log4j 2 provides out of the box. Instead, have your application do:
{code:java}
ThreadContext.put("LEVEL", threadLevel.toUpperCase());
{code}
Then you can use either the
[DynamicThresholdFilter|https://logging.apache.org/log4j/2.x/manual/filters.html#DynamicThresholdFilter]
{code:java}
{code}
or you can create your own custom Filter. You DO NOT need a custom Logger.
> Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
> --
>
> Key: LOG4J2-3455
> URL: https://issues.apache.org/jira/browse/LOG4J2-3455
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments: CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, ThreadLevelLogThresholdTest.java,
> customlog.properties
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With bridge 2.17.2/2.17.3-SNAPSHOT, thread specific log level threshold
> doesn't work which used to work earlier with log4j1.x. We had achieved this
> feature by overriding getEffectiveLevel(), but now this doesn't work anymore
> with log4j1.x bridge since the method getEffectiveLevel() is not getting
> invoked to set effective level.
>
> For reference, Java class files for Custom Logger, Custom Multiprocess
> Rolling Appender and Test program are attached along with cutom log4j
> properties
> file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3455) Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
[
https://issues.apache.org/jira/browse/LOG4J2-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515084#comment-17515084
]
Ralph Goers commented on LOG4J2-3455:
-
We are suggesting that you forget about your Log4j 1 customizations and focus
on what Log4j 2 provides out of the box. Instead, have your application do:
{code:java}
ThreadContext.put("LEVEL", threadLevel.toUpperCase());
{code}
Then you can use either the
[DynamicThresholdFilter|https://logging.apache.org/log4j/2.x/manual/filters.html#DynamicThresholdFilter]
{code:java}
{code}
or you can create your own custom Filter. You DO NOT need a custom Logger.
> Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
> --
>
> Key: LOG4J2-3455
> URL: https://issues.apache.org/jira/browse/LOG4J2-3455
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments: CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, ThreadLevelLogThresholdTest.java,
> customlog.properties
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With bridge 2.17.2/2.17.3-SNAPSHOT, thread specific log level threshold
> doesn't work which used to work earlier with log4j1.x. We had achieved this
> feature by overriding getEffectiveLevel(), but now this doesn't work anymore
> with log4j1.x bridge since the method getEffectiveLevel() is not getting
> invoked to set effective level.
>
> For reference, Java class files for Custom Logger, Custom Multiprocess
> Rolling Appender and Test program are attached along with cutom log4j
> properties
> file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515080#comment-17515080
]
Pooja Pandey commented on LOG4J2-3457:
--
[~rgoers] ,
Okay, thank you Ralph for your response and suggestion!!
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments:
> CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG,
> CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> In our application we require a rolling file appender which can be used
> across multiple processes targeting the same file.
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
> !CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG|width=756,height=434!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3458) LocalizedMessage logs misleading errors on the console
[
https://issues.apache.org/jira/browse/LOG4J2-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515081#comment-17515081
]
ASF subversion and git services commented on LOG4J2-3458:
-
Commit 55a0147ec3cef9cd87c9f96e5ceb202eeb487249 in logging-log4j2's branch
refs/heads/master from Gary Gregory
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=55a0147 ]
[LOG4J2-3458] LocalizedMessage logs misleading errors on the console.
Can't cherry-pick from release-2.x.
> 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] [Commented] (LOG4J2-3459) Reduce use of class static initialization blocks
[ https://issues.apache.org/jira/browse/LOG4J2-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515077#comment-17515077 ] Ralph Goers commented on LOG4J2-3459: - If you profile start up what shows up as the hot spots? > Reduce use of class static initialization blocks > > > Key: LOG4J2-3459 > URL: https://issues.apache.org/jira/browse/LOG4J2-3459 > Project: Log4j 2 > Issue Type: Improvement > Components: API, Core >Reporter: Matt Sicker >Priority: Major > > There are numerous classes that use static initializer blocks to perform > computation for caching some results. These should all generally be deferred > until some other reference to the class such as instantiation of use of a > singleton getter method. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515075#comment-17515075
]
Ralph Goers commented on LOG4J2-3457:
-
OK, thanks. It is clear now.
# I do not envision that we would update Log4j's RollingFileAppender to do
what you are doing. The RollingFileAppender is already overly complicated.
# Your best bet would be to convert your custom appender to be a Log4j 2
Appender.
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments:
> CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG,
> CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> In our application we require a rolling file appender which can be used
> across multiple processes targeting the same file.
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
> !CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG|width=756,height=434!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3455) Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
[
https://issues.apache.org/jira/browse/LOG4J2-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515074#comment-17515074
]
Pooja Pandey edited comment on LOG4J2-3455 at 3/31/22, 4:52 AM:
Hi [~mattsicker],
Thank you for your response!!
Actually to achieve our functionality we are overriding getEffectiveLevel() in
our CustomLogger as below, where we have a concept of General Logger along with
other various loggers for performance and diagnostics(Sample code is captured
in attached CustomLogger.java file). In our application we have a requirement
to update threshold level only for GeneralLogger. I think with log4j1.x bridge,
the issue could be fixed only if log4j1.x bridge invokes getEffectiveLevel() as
it used to happen in log4j1.x. Currently we could achieve this with a
workaround in our application where we get logger as per log4j2.x API and
set/clear threshold as per log4j2.x API.
@Override
public Level getEffectiveLevel()
{ Level configuredLevel = super.getEffectiveLevel(); if (!isGeneralLogger)
return configuredLevel; Level currLevel = myLevel.get(); if (currLevel == null)
return configuredLevel; if (configuredLevel == null) return currLevel; if
(currLevel.isGreaterOrEqual(configuredLevel)) return configuredLevel; return
currLevel; }
was (Author: JIRAUSER285751):
Hi [~mattsicker],
Thank you for your response!!
Actually to achieve our functionality we are overriding getEffectiveLevel() in
our CustomLogger as below, where we have a concept of General Logger along with
various other various loggers for performance and diagnostics(Sample code is
captured in attached CustomLogger.java file). In our application we have a
requirement to update threshold level only for GeneralLogger. I think with
log4j1.x bridge, the issue could be fixed only if log4j1.x bridge invokes
getEffectiveLevel() as it used to happen in log4j1.x. Currently we could
achieve this with a workaround in our application where we get logger as per
log4j2.x API and set/clear threshold as per log4j2.x API.
@Override
public Level getEffectiveLevel()
{ Level configuredLevel = super.getEffectiveLevel(); if (!isGeneralLogger)
return configuredLevel; Level currLevel = myLevel.get(); if (currLevel == null)
return configuredLevel; if (configuredLevel == null) return currLevel; if
(currLevel.isGreaterOrEqual(configuredLevel)) return configuredLevel; return
currLevel; }
> Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
> --
>
> Key: LOG4J2-3455
> URL: https://issues.apache.org/jira/browse/LOG4J2-3455
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments: CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, ThreadLevelLogThresholdTest.java,
> customlog.properties
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With bridge 2.17.2/2.17.3-SNAPSHOT, thread specific log level threshold
> doesn't work which used to work earlier with log4j1.x. We had achieved this
> feature by overriding getEffectiveLevel(), but now this doesn't work anymore
> with log4j1.x bridge since the method getEffectiveLevel() is not getting
> invoked to set effective level.
>
> For reference, Java class files for Custom Logger, Custom Multiprocess
> Rolling Appender and Test program are attached along with cutom log4j
> properties
> file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3455) Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
[
https://issues.apache.org/jira/browse/LOG4J2-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515074#comment-17515074
]
Pooja Pandey commented on LOG4J2-3455:
--
Hi [~mattsicker],
Actually to achieve our functionality we are overriding getEffectiveLevel() in
our CustomLogger as below, where we have a concept of General Logger along with
various other various loggers for performance and diagnostics(Sample code is
captured in attached CustomLogger.java file). In our application we have a
requirement to update threshold level only for GeneralLogger. I think with
log4j1.x bridge, the issue could be fixed only if log4j1.x bridge invokes
getEffectiveLevel() as it used to happen in log4j1.x. Currently we could
achieve this with a workaround in our application where we get logger as per
log4j2.x API and set/clear threshold as per log4j2.x API.
@Override
public Level getEffectiveLevel() {
Level configuredLevel = super.getEffectiveLevel();
if (!isGeneralLogger)
return configuredLevel;
Level currLevel = myLevel.get();
if (currLevel == null)
return configuredLevel;
if (configuredLevel == null)
return currLevel;
if (currLevel.isGreaterOrEqual(configuredLevel))
return configuredLevel;
return currLevel;
}
> Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
> --
>
> Key: LOG4J2-3455
> URL: https://issues.apache.org/jira/browse/LOG4J2-3455
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments: CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, ThreadLevelLogThresholdTest.java,
> customlog.properties
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With bridge 2.17.2/2.17.3-SNAPSHOT, thread specific log level threshold
> doesn't work which used to work earlier with log4j1.x. We had achieved this
> feature by overriding getEffectiveLevel(), but now this doesn't work anymore
> with log4j1.x bridge since the method getEffectiveLevel() is not getting
> invoked to set effective level.
>
> For reference, Java class files for Custom Logger, Custom Multiprocess
> Rolling Appender and Test program are attached along with cutom log4j
> properties
> file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3455) Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
[
https://issues.apache.org/jira/browse/LOG4J2-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515074#comment-17515074
]
Pooja Pandey edited comment on LOG4J2-3455 at 3/31/22, 4:49 AM:
Hi [~mattsicker],
Thank you for your response!!
Actually to achieve our functionality we are overriding getEffectiveLevel() in
our CustomLogger as below, where we have a concept of General Logger along with
various other various loggers for performance and diagnostics(Sample code is
captured in attached CustomLogger.java file). In our application we have a
requirement to update threshold level only for GeneralLogger. I think with
log4j1.x bridge, the issue could be fixed only if log4j1.x bridge invokes
getEffectiveLevel() as it used to happen in log4j1.x. Currently we could
achieve this with a workaround in our application where we get logger as per
log4j2.x API and set/clear threshold as per log4j2.x API.
@Override
public Level getEffectiveLevel()
{ Level configuredLevel = super.getEffectiveLevel(); if (!isGeneralLogger)
return configuredLevel; Level currLevel = myLevel.get(); if (currLevel == null)
return configuredLevel; if (configuredLevel == null) return currLevel; if
(currLevel.isGreaterOrEqual(configuredLevel)) return configuredLevel; return
currLevel; }
was (Author: JIRAUSER285751):
Hi [~mattsicker],
Actually to achieve our functionality we are overriding getEffectiveLevel() in
our CustomLogger as below, where we have a concept of General Logger along with
various other various loggers for performance and diagnostics(Sample code is
captured in attached CustomLogger.java file). In our application we have a
requirement to update threshold level only for GeneralLogger. I think with
log4j1.x bridge, the issue could be fixed only if log4j1.x bridge invokes
getEffectiveLevel() as it used to happen in log4j1.x. Currently we could
achieve this with a workaround in our application where we get logger as per
log4j2.x API and set/clear threshold as per log4j2.x API.
@Override
public Level getEffectiveLevel() {
Level configuredLevel = super.getEffectiveLevel();
if (!isGeneralLogger)
return configuredLevel;
Level currLevel = myLevel.get();
if (currLevel == null)
return configuredLevel;
if (configuredLevel == null)
return currLevel;
if (currLevel.isGreaterOrEqual(configuredLevel))
return configuredLevel;
return currLevel;
}
> Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
> --
>
> Key: LOG4J2-3455
> URL: https://issues.apache.org/jira/browse/LOG4J2-3455
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments: CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, ThreadLevelLogThresholdTest.java,
> customlog.properties
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With bridge 2.17.2/2.17.3-SNAPSHOT, thread specific log level threshold
> doesn't work which used to work earlier with log4j1.x. We had achieved this
> feature by overriding getEffectiveLevel(), but now this doesn't work anymore
> with log4j1.x bridge since the method getEffectiveLevel() is not getting
> invoked to set effective level.
>
> For reference, Java class files for Custom Logger, Custom Multiprocess
> Rolling Appender and Test program are attached along with cutom log4j
> properties
> file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3458) LocalizedMessage logs misleading errors on the console
[
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] [Commented] (LOG4J2-3455) Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
[ https://issues.apache.org/jira/browse/LOG4J2-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515070#comment-17515070 ] Matt Sicker commented on LOG4J2-3455: - You might find [https://logging.apache.org/log4j/2.x/manual/filters.html#ThreadContextMapFilter] and [https://logging.apache.org/log4j/2.x/manual/thread-context.html] useful for this. ThreadContext gives you the per-thread value, and the filter allows for a dynamic filter on loggers, appenders, or whatever else that supports filters. > Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work > -- > > Key: LOG4J2-3455 > URL: https://issues.apache.org/jira/browse/LOG4J2-3455 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > Attachments: CustomLogger.java, CustomLoggerFactory.java, > CustomMultiProcessRollingAppender.java, ThreadLevelLogThresholdTest.java, > customlog.properties > > > In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. > With bridge 2.17.2/2.17.3-SNAPSHOT, thread specific log level threshold > doesn't work which used to work earlier with log4j1.x. We had achieved this > feature by overriding getEffectiveLevel(), but now this doesn't work anymore > with log4j1.x bridge since the method getEffectiveLevel() is not getting > invoked to set effective level. > > For reference, Java class files for Custom Logger, Custom Multiprocess > Rolling Appender and Test program are attached along with cutom log4j > properties > file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3458) LocalizedMessage logs misleading errors on the console
[
https://issues.apache.org/jira/browse/LOG4J2-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515067#comment-17515067
]
ASF subversion and git services commented on LOG4J2-3458:
-
Commit 5eaeb95760b9d4460288fde9c7af3f2cf98765ae in logging-log4j2's branch
refs/heads/release-2.x from Gary Gregory
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5eaeb95 ]
LOG4J2-3458 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] [Commented] (LOG4J2-3455) Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
[ https://issues.apache.org/jira/browse/LOG4J2-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515066#comment-17515066 ] Pooja Pandey commented on LOG4J2-3455: -- Hi [~rgoers], Thank you for your response! Below is what defines our requirement. " Our application has a standard for command line clients – that they should accept a command line parameter that overrides the logging threshold for operations in aid of that client on both the client and server sides. The server is operating on behalf of any number of clients simultaneously and in normal operation is sparing in what it actually writes to the log file. We are using CustomLogger class which is a specialization of the log4j Logger class. log4j uses an approach of fine grained log level control, driving its specialization by the name of the logger used. Named loggers may have different thresholds, usually configured through specific entries in the properties file. If we want to provide operation level threshold control, it cannot be done using any of log4j’s natural approaches to the problem. To achieve the command line client specific log level threshold, we capture the threshold setting as a thread local variable. The value of the variable is used in an override of the getEffectiveLevel method from log4j’s Logger class. log4j1.x uses getEffectiveLevel internally to determine the threshold for logging messages. The net effect of this approach is that a body of code can set the threshold at a higher logical level of the code and all lower level code invoked by that level will respect the lower threshold without needing be otherwise told. On exit from the high level function, it must clear the threshold setting so that other operations that reuse the thread do not encounter a spurious setting. However since now we have migrated to log4j1.x 2.17.2 bridge and it doesn't use getEffectiveLevel() internally, which has broken our feature and to fix the feature we have implemented a workaround where we set/clear threshold with Log4j2 API directly. " > Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work > -- > > Key: LOG4J2-3455 > URL: https://issues.apache.org/jira/browse/LOG4J2-3455 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > Attachments: CustomLogger.java, CustomLoggerFactory.java, > CustomMultiProcessRollingAppender.java, ThreadLevelLogThresholdTest.java, > customlog.properties > > > In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. > With bridge 2.17.2/2.17.3-SNAPSHOT, thread specific log level threshold > doesn't work which used to work earlier with log4j1.x. We had achieved this > feature by overriding getEffectiveLevel(), but now this doesn't work anymore > with log4j1.x bridge since the method getEffectiveLevel() is not getting > invoked to set effective level. > > For reference, Java class files for Custom Logger, Custom Multiprocess > Rolling Appender and Test program are attached along with cutom log4j > properties > file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3458) LocalizedMessage logs misleading errors on the console
[
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.
[
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\
[
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] [Commented] (LOG4J2-3459) Reduce use of class static initialization blocks
[ https://issues.apache.org/jira/browse/LOG4J2-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515063#comment-17515063 ] Matt Sicker commented on LOG4J2-3459: - What kind of profiler and profiling would you recommend for checking startup time? So far, the only thing I've figured out was class init logging to find some stuff that was being unnecessarily initialized in the plugin system, but now I'm finding it harder to figure out the rest. > Reduce use of class static initialization blocks > > > Key: LOG4J2-3459 > URL: https://issues.apache.org/jira/browse/LOG4J2-3459 > Project: Log4j 2 > Issue Type: Improvement > Components: API, Core >Reporter: Matt Sicker >Priority: Major > > There are numerous classes that use static initializer blocks to perform > computation for caching some results. These should all generally be deferred > until some other reference to the class such as instantiation of use of a > singleton getter method. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515061#comment-17515061
]
Pooja Pandey edited comment on LOG4J2-3457 at 3/31/22, 4:09 AM:
Hi [~rgoers] ,
Thank you for your response.
I have attached updated java class(CustomMultiProcessRollingAppender.java) and
log4j property(customlog.properties) file reflecting our application's
requirement.
was (Author: JIRAUSER285751):
Hi [~rgoers] ,
Thank you for your response.
I have updated attached java class(CustomMultiProcessRollingAppender.java) and
log4j property(customlog.properties) file reflecting our application's
requirement.
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments:
> CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG,
> CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> In our application we require a rolling file appender which can be used
> across multiple processes targeting the same file.
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
> !CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG|width=756,height=434!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515061#comment-17515061
]
Pooja Pandey commented on LOG4J2-3457:
--
Hi [~rgoers] ,
Thank you for your response.
I have updated attached java class(CustomMultiProcessRollingAppender.java) and
log4j property(customlog.properties) file reflecting our application's
requirement.
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments:
> CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG,
> CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> In our application we require a rolling file appender which can be used
> across multiple processes targeting the same file.
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
> !CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG|width=756,height=434!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Pandey updated LOG4J2-3457:
-
Attachment: (was: customlog.properties)
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments:
> CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG,
> CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> In our application we require a rolling file appender which can be used
> across multiple processes targeting the same file.
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
> !CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG|width=756,height=434!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Pandey updated LOG4J2-3457:
-
Attachment: (was: CustomMultiProcessRollingAppender.java)
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments:
> CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG,
> CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> In our application we require a rolling file appender which can be used
> across multiple processes targeting the same file.
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
> !CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG|width=756,height=434!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Pandey updated LOG4J2-3457:
-
Attachment: customlog.properties
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments:
> CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG,
> CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> In our application we require a rolling file appender which can be used
> across multiple processes targeting the same file.
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
> !CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG|width=756,height=434!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Pandey updated LOG4J2-3457:
-
Attachment: CustomMultiProcessRollingAppender.java
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments:
> CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG,
> CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> In our application we require a rolling file appender which can be used
> across multiple processes targeting the same file.
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
> !CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG|width=756,height=434!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3459) Reduce use of class static initialization blocks
[ https://issues.apache.org/jira/browse/LOG4J2-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515052#comment-17515052 ] Remko Popma commented on LOG4J2-3459: - Preaching:) from painful experience, I would recommend using a profiler, and only change the topmost performance bottleneck, then profile again, and again only change the topmost bottleneck etc. Without profiling, our intuition about what is fast or slow can be far off the mark… > Reduce use of class static initialization blocks > > > Key: LOG4J2-3459 > URL: https://issues.apache.org/jira/browse/LOG4J2-3459 > Project: Log4j 2 > Issue Type: Improvement > Components: API, Core >Reporter: Matt Sicker >Priority: Major > > There are numerous classes that use static initializer blocks to perform > computation for caching some results. These should all generally be deferred > until some other reference to the class such as instantiation of use of a > singleton getter method. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3459) Reduce use of class static initialization blocks
[
https://issues.apache.org/jira/browse/LOG4J2-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515033#comment-17515033
]
Matt Sicker commented on LOG4J2-3459:
-
Search code base for the string "static {" and see which ones can be made lazy.
I'm testing out some changes right now.
> Reduce use of class static initialization blocks
>
>
> Key: LOG4J2-3459
> URL: https://issues.apache.org/jira/browse/LOG4J2-3459
> Project: Log4j 2
> Issue Type: Improvement
> Components: API, Core
>Reporter: Matt Sicker
>Priority: Major
>
> There are numerous classes that use static initializer blocks to perform
> computation for caching some results. These should all generally be deferred
> until some other reference to the class such as instantiation of use of a
> singleton getter method.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3459) Reduce use of class static initialization blocks
[ https://issues.apache.org/jira/browse/LOG4J2-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515031#comment-17515031 ] Ralph Goers edited comment on LOG4J2-3459 at 3/31/22, 2:44 AM: --- You are going to have to be more specific. The use of static initializer blocks comes with the guarantee of thread safety so it is often the most preferable method of initialization. I would prefer a minor startup overhead to the cost of introducing bugs that are hard to find and fix. was (Author: ralph.go...@dslextreme.com): You are going to have to be more specific. The use of static initializer blocks comes with the guarantee of thread safety so it is often the most preferable method of initialization. > Reduce use of class static initialization blocks > > > Key: LOG4J2-3459 > URL: https://issues.apache.org/jira/browse/LOG4J2-3459 > Project: Log4j 2 > Issue Type: Improvement > Components: API, Core >Reporter: Matt Sicker >Priority: Major > > There are numerous classes that use static initializer blocks to perform > computation for caching some results. These should all generally be deferred > until some other reference to the class such as instantiation of use of a > singleton getter method. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3459) Reduce use of class static initialization blocks
[ https://issues.apache.org/jira/browse/LOG4J2-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515031#comment-17515031 ] Ralph Goers commented on LOG4J2-3459: - You are going to have to be more specific. The use of static initializer blocks comes with the guarantee of thread safety so it is often the most preferable method of initialization. > Reduce use of class static initialization blocks > > > Key: LOG4J2-3459 > URL: https://issues.apache.org/jira/browse/LOG4J2-3459 > Project: Log4j 2 > Issue Type: Improvement > Components: API, Core >Reporter: Matt Sicker >Priority: Major > > There are numerous classes that use static initializer blocks to perform > computation for caching some results. These should all generally be deferred > until some other reference to the class such as instantiation of use of a > singleton getter method. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3456) Log4j 1.x 2.17.2 bridge - Runtime log4j property update doesn't work
[ https://issues.apache.org/jira/browse/LOG4J2-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515029#comment-17515029 ] Ralph Goers commented on LOG4J2-3456: - Why are you changing properties? If you want to log differently based on the data Log4j 2 provides many features to do that. But without understanding what your requirements are we cannot advise the best way to do this. Simply trying to port your customizations to Log4j 1 is probably not the correct approach. > Log4j 1.x 2.17.2 bridge - Runtime log4j property update doesn't work > > > Key: LOG4J2-3456 > URL: https://issues.apache.org/jira/browse/LOG4J2-3456 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > Attachments: CustomLogger.java, CustomLoggerFactory.java, > CustomMultiProcessRollingAppender.java, > RuntimeUpdateLoggingPropertiesTest.java, customlog.properties > > > In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. > With bridge 2.17.2/2.17.3-SNAPSHOT, we have found that we could not update > log4j config properties at run time while same used to work with log4j1.x. It > looks like there is some problem with PropertyConfigurator.configure(url) > when we call it at run time to reconfigure properties programmatically at run > time and it doesn't reset property value at run time. > > For reference, Java class files for Custom Logger, Custom Multiprocess > Rolling Appender and Test program are attached along with cutom log4j > properties > file.[^CustomLogger.java][^customlog.properties][^RuntimeUpdateLoggingPropertiesTest.java] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3455) Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
[ https://issues.apache.org/jira/browse/LOG4J2-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515027#comment-17515027 ] Ralph Goers commented on LOG4J2-3455: - You really need to explain what your requirement is. Out of the box Log4j 2 supports many different ways to dynamically determine what to log. There is likely no need for a ThreadLocal level. > Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work > -- > > Key: LOG4J2-3455 > URL: https://issues.apache.org/jira/browse/LOG4J2-3455 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > Attachments: CustomLogger.java, CustomLoggerFactory.java, > CustomMultiProcessRollingAppender.java, ThreadLevelLogThresholdTest.java, > customlog.properties > > > In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. > With bridge 2.17.2/2.17.3-SNAPSHOT, thread specific log level threshold > doesn't work which used to work earlier with log4j1.x. We had achieved this > feature by overriding getEffectiveLevel(), but now this doesn't work anymore > with log4j1.x bridge since the method getEffectiveLevel() is not getting > invoked to set effective level. > > For reference, Java class files for Custom Logger, Custom Multiprocess > Rolling Appender and Test program are attached along with cutom log4j > properties > file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3453) Filters contains invalid attributes "onMatch", "onMismatch"
[
https://issues.apache.org/jira/browse/LOG4J2-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515015#comment-17515015
]
Luning Wang commented on LOG4J2-3453:
-
[~pkarwasz] Thank you respoense. If I change properties to XML, will the error
message disappear?
> Filters contains invalid attributes "onMatch", "onMismatch"
> ---
>
> Key: LOG4J2-3453
> URL: https://issues.apache.org/jira/browse/LOG4J2-3453
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Luning Wang
>Priority: Major
> Fix For: 2.17.2
>
>
> The following is my log4j2.properties
> {code:java}
> appender.console.filter.1.type = Filters
> appender.console.filter.1.a.type = ThresholdFilter
> appender.console.filter.1.a.level = info
> appender.console.filter.1.b.type = RegexFilter
> appender.console.filter.1.b.regex = .*Thrift error occurred during processing
> of message.*
> appender.console.filter.1.b.onMatch = deny
> appender.console.filter.1.b.onMismatch = neutral
> {code}
> When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
> `Filters contains invalid attributes "onMatch", "onMismatch"` error message.
> What is correctly conf?
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (LOG4J2-3459) Reduce use of class static initialization blocks
Matt Sicker created LOG4J2-3459: --- Summary: Reduce use of class static initialization blocks Key: LOG4J2-3459 URL: https://issues.apache.org/jira/browse/LOG4J2-3459 Project: Log4j 2 Issue Type: Improvement Components: API, Core Reporter: Matt Sicker There are numerous classes that use static initializer blocks to perform computation for caching some results. These should all generally be deferred until some other reference to the class such as instantiation of use of a singleton getter method. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515011#comment-17515011
]
Matt Sicker commented on LOG4J2-2795:
-
{quote}Wonder if you evaluated to not collect plugins but just try to load them
lazily when they are referenced. Concretely, ConsoleAppender wouldnt be loaded
until it appears in some configuration etc...Also loading it using a registrar
class (kind of ServiceLoader mecanism but with a name deduced from the name
encoutered by log4j) can enable to simplify the serialization too and get back
to something closer to the previous (v1) configuration where it was loaded per
class directly (even if it still has an indirection with the resource lookup
but it is a bit better).
{quote}
This is exactly how it works in master right now.
The static init stuff is something I'll have to look into. It's possible that
the remaining lag is from things in log4j-api that could be refactored.
> 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] [Comment Edited] (LOG4J2-3458) LocalizedMessage causes a lot of noise on the console
[
https://issues.apache.org/jira/browse/LOG4J2-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514993#comment-17514993
]
Ralph Goers edited comment on LOG4J2-3458 at 3/31/22, 12:17 AM:
This example makes no sense to me. The value of newMessage is supposed to be a
message key. Why is it a file path?
That said, it seems LocalizedMessage is using FormattedMessage to determine the
type of message formatting to use. I see it is using RegEx matching to do that.
We should probably allow the LocalizedMessageFactory to be able to be
configured with the MessageFactory to use when resolving the message rather
than relying completely on the dynamic check.
was (Author: ralph.go...@dslextreme.com):
This example makes no sense to me. The value of newMessage is supposed to be a
message key. Why is it a file path?
That said, it seems LocalizedMessage is using FormattedMessage to determine the
type of message formatting to use. It first tries to format it as a
MessageFormatMessage. If that gets an exception it tries StringFormatMessage.
It that gets an Exception it then tries ParameterizedMessage. What I don't
understand is why you would be seeing the exception from StringFormattedMessage
as that exception is caught and ignored.
> 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 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] [Comment Edited] (LOG4J2-3458) LocalizedMessage causes a lot of noise on the console
[
https://issues.apache.org/jira/browse/LOG4J2-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514993#comment-17514993
]
Ralph Goers edited comment on LOG4J2-3458 at 3/31/22, 12:11 AM:
This example makes no sense to me. The value of newMessage is supposed to be a
message key. Why is it a file path?
That said, it seems LocalizedMessage is using FormattedMessage to determine the
type of message formatting to use. It first tries to format it as a
MessageFormatMessage. If that gets an exception it tries StringFormatMessage.
It that gets an Exception it then tries ParameterizedMessage. What I don't
understand is why you would be seeing the exception from StringFormattedMessage
as that exception is caught and ignored.
was (Author: ralph.go...@dslextreme.com):
This example makes no sense to me. The value of newMessage is supposed to be a
message key. Why is it a file path?
> 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 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] [Commented] (LOG4J2-3458) LocalizedMessage causes a lot of noise on the console
[
https://issues.apache.org/jira/browse/LOG4J2-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514993#comment-17514993
]
Ralph Goers commented on LOG4J2-3458:
-
This example makes no sense to me. The value of newMessage is supposed to be a
message key. Why is it a file path?
> 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 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] [Commented] (LOG4J2-3458) LocalizedMessage causes a lot of noise on the console
[
https://issues.apache.org/jira/browse/LOG4J2-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514979#comment-17514979
]
Matt Sicker commented on LOG4J2-3458:
-
I'd say that if you're logging an exception instance where the place to go look
to debug the issue is obvious, then that's unnecessary noise. In this case, you
could remove the exception and only log its message, or perhaps include the
exception as a follow-up trace log event.
> 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 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
[
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 logg
[jira] [Created] (LOG4J2-3458) LocalizedMessage causes a lot of noise on the console
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-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514965#comment-17514965
]
Ralph Goers commented on LOG4J2-3457:
-
I have got to be missing something as I don't see any code in
CustomMultiProcessRollingAppender that actually rolls the file. All I see is a
thread that deletes a file with a .roll extension after it was modified more
than 2 seconds previously. I am sure I could be of more help if I knew exactly
what was causing the rollover and how it works.
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments:
> CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG,
> CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> In our application we require a rolling file appender which can be used
> across multiple processes targeting the same file.
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
> !CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG|width=756,height=434!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3410) Log4j 1.2 bridge throws a ClassCastException when logging a Map with non-String keys
[
https://issues.apache.org/jira/browse/LOG4J2-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514963#comment-17514963
]
ASF subversion and git services commented on LOG4J2-3410:
-
Commit 45c53f9630eafb2c04c5e6a29406f0c53d812a63 in logging-log4j2's branch
refs/heads/master from Gary Gregory
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=45c53f9 ]
[LOG4J2-3410] Log4j 1.2 bridge throws a ClassCastException when logging
a Map with non-String keys.
Conflicts:
log4j-api/src/test/java/org/apache/logging/log4j/util/SortedArrayStringMapTest.java
src/changes/changes.xml
> 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] [Commented] (LOG4J2-3407) PropertiesConfiguration.parseAppender NPE when logger refers to non-existent appender
[
https://issues.apache.org/jira/browse/LOG4J2-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514964#comment-17514964
]
ASF subversion and git services commented on LOG4J2-3407:
-
Commit e0dee7357a5e30cecdac36333c07e6e441b078b2 in logging-log4j2's branch
refs/heads/master from Kenny MacLeod
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=e0dee73 ]
LOG4J2-3407 Check for non-existent appender when parsing properties (#761)
> 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-3452) Race condition in FileUtils.mkdir()
[
https://issues.apache.org/jira/browse/LOG4J2-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Karwasz resolved LOG4J2-3452.
---
Resolution: Fixed
> Race condition in FileUtils.mkdir()
> ---
>
> Key: LOG4J2-3452
> URL: https://issues.apache.org/jira/browse/LOG4J2-3452
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.13.0
>Reporter: Stefan Vodita
>Priority: Major
>
> I noticed an error like:
> {{ERROR Unable to create file ...}}
> {{at org.apache.logging.log4j.core.util.FileUtils.mkdir(FileUtils.java:118)}}
>
> The error could be due to a race condition:
> {{Thread A: dir.exists() -> false}}
> {{Thread B: dir.exists() -> false}}
> {{Thread B: dir.mkdirs() -> succeeds}}
> {{Thread A: dir.mkdirs() -> throws exception}}
>
> I wrote a unit test which reproduces the error:
> {{public void testMkdirConcurrent() throws IOException {}}
> {{ final File file = new File("target/test/test");}}
> {{ for (int i = 0; i < 1000; i++) {}}
> {{ new Thread(() -> assertDoesNotThrow(() -> FileUtils.mkdir(file,
> true))).start();}}
> {{ org.apache.commons.io.FileUtils.deleteDirectory(file);}}
> {{}}}
>
> As a fix, we can use {{{}Files.createDirectories(){}}}, since this does the
> existence check and creation as one atomic operation.
>
> I will create a PR with the unit test and a fix.
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] ppkarwasz commented on pull request #809: LOG4J2-3452: Fix race condition in FileUtils.mkdir()
ppkarwasz commented on pull request #809: URL: https://github.com/apache/logging-log4j2/pull/809#issuecomment-1083632089 @stefanvodita, Thank you for your contribution. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LOG4J2-3452) Race condition in FileUtils.mkdir()
[
https://issues.apache.org/jira/browse/LOG4J2-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514954#comment-17514954
]
ASF subversion and git services commented on LOG4J2-3452:
-
Commit 396ec807aa277047c5119ce60fcc14bee7b9ffcc in logging-log4j2's branch
refs/heads/release-2.x from Stefan Vodita
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=396ec80 ]
LOG4J2-3452: Fix race condition in FileUtils.mkdir() (#809)
* LOG4J2-3452: Fix race condition in FileUtils.mkdir()
A race condition could appear when 2 threads were trying to create the
same directory. Both would check that the directory did not exist, then
one would create the directory and the other would throw an exception.
This was reproduced with a unit test included this commit and fixed by
using Files.createDirectories() instead of File.mkdirs(), so that the
existence check and directory creation are done as an atomic operation.
> Race condition in FileUtils.mkdir()
> ---
>
> Key: LOG4J2-3452
> URL: https://issues.apache.org/jira/browse/LOG4J2-3452
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.13.0
>Reporter: Stefan Vodita
>Priority: Major
>
> I noticed an error like:
> {{ERROR Unable to create file ...}}
> {{at org.apache.logging.log4j.core.util.FileUtils.mkdir(FileUtils.java:118)}}
>
> The error could be due to a race condition:
> {{Thread A: dir.exists() -> false}}
> {{Thread B: dir.exists() -> false}}
> {{Thread B: dir.mkdirs() -> succeeds}}
> {{Thread A: dir.mkdirs() -> throws exception}}
>
> I wrote a unit test which reproduces the error:
> {{public void testMkdirConcurrent() throws IOException {}}
> {{ final File file = new File("target/test/test");}}
> {{ for (int i = 0; i < 1000; i++) {}}
> {{ new Thread(() -> assertDoesNotThrow(() -> FileUtils.mkdir(file,
> true))).start();}}
> {{ org.apache.commons.io.FileUtils.deleteDirectory(file);}}
> {{}}}
>
> As a fix, we can use {{{}Files.createDirectories(){}}}, since this does the
> existence check and creation as one atomic operation.
>
> I will create a PR with the unit test and a fix.
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] ppkarwasz merged pull request #809: LOG4J2-3452: Fix race condition in FileUtils.mkdir()
ppkarwasz merged pull request #809: URL: https://github.com/apache/logging-log4j2/pull/809 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514949#comment-17514949
]
Romain Manni-Bucau commented on LOG4J2-2795:
To give another metrics for my computer: a real "small" application (johnzon +
cdi + yupiik-logging/JUL) starts in ~250ms (with scanning not optimized and
some startup init code) which is 30ms faster than log4j alone for a
getLogger().info() main - just enables to compare why I speak about a few
dozens of ms to init the logging.
Wonder if you evaluated to not collect plugins but just try to load them lazily
when they are referenced. Concretely, ConsoleAppender wouldnt be loaded until
it appears in some configuration etc...Also loading it using a registrar class
(kind of ServiceLoader mecanism but with a name deduced from the name
encoutered by log4j) can enable to simplify the serialization too and get back
to something closer to the previous (v1) configuration where it was loaded per
class directly (even if it still has an indirection with the resource lookup
but it is a bit better).
That + dropping most of static init would be great I think even if I can't
evaluate the gain yet.
> 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] [Updated] (LOG4J2-3456) Log4j 1.x 2.17.2 bridge - Runtime log4j property update doesn't work
[ https://issues.apache.org/jira/browse/LOG4J2-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pooja Pandey updated LOG4J2-3456: - Description: In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. With bridge 2.17.2/2.17.3-SNAPSHOT, we have found that we could not update log4j config properties at run time while same used to work with log4j1.x. It looks like there is some problem with PropertyConfigurator.configure(url) when we call it at run time to reconfigure properties programmatically at run time and it doesn't reset property value at run time. For reference, Java class files for Custom Logger, Custom Multiprocess Rolling Appender and Test program are attached along with cutom log4j properties file.[^CustomLogger.java][^customlog.properties][^RuntimeUpdateLoggingPropertiesTest.java] was: In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. With bridge 2.17.2/2.17.3-SNAPSHOT, we have noticed that we could not update log4j config properties at run time while same used to work with log4j1.x. It looks like there is some problem with PropertyConfigurator.configure(url) when we call it at run time to reconfigure properties programmatically at run time and it doesn't reset property value at run time. For reference, Java class files for Custom Logger, Custom Multiprocess Rolling Appender and Test program are attached along with cutom log4j properties file.[^CustomLogger.java][^customlog.properties][^RuntimeUpdateLoggingPropertiesTest.java] > Log4j 1.x 2.17.2 bridge - Runtime log4j property update doesn't work > > > Key: LOG4J2-3456 > URL: https://issues.apache.org/jira/browse/LOG4J2-3456 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > Attachments: CustomLogger.java, CustomLoggerFactory.java, > CustomMultiProcessRollingAppender.java, > RuntimeUpdateLoggingPropertiesTest.java, customlog.properties > > > In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. > With bridge 2.17.2/2.17.3-SNAPSHOT, we have found that we could not update > log4j config properties at run time while same used to work with log4j1.x. It > looks like there is some problem with PropertyConfigurator.configure(url) > when we call it at run time to reconfigure properties programmatically at run > time and it doesn't reset property value at run time. > > For reference, Java class files for Custom Logger, Custom Multiprocess > Rolling Appender and Test program are attached along with cutom log4j > properties > file.[^CustomLogger.java][^customlog.properties][^RuntimeUpdateLoggingPropertiesTest.java] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3456) Log4j 1.x 2.17.2 bridge - Runtime log4j property update doesn't work
[ https://issues.apache.org/jira/browse/LOG4J2-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pooja Pandey updated LOG4J2-3456: - Description: In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. With bridge 2.17.2/2.17.3-SNAPSHOT, we have noticed that we could not update log4j config properties at run time while same used to work with log4j1.x. It looks like there is some problem with PropertyConfigurator.configure(url) when we call it at run time to reconfigure properties programmatically at run time and it doesn't reset property value at run time. For reference, Java class files for Custom Logger, Custom Multiprocess Rolling Appender and Test program are attached along with cutom log4j properties file.[^CustomLogger.java][^customlog.properties][^RuntimeUpdateLoggingPropertiesTest.java] was: In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. With bridge 2.17.2/2.17/3-SNAPSHOT, we have noticed that we could not update log4j config properties at run time while same used to work with log4j1.x. It looks like there is some problem with PropertyConfigurator.configure(url) when we call it at run time to reconfigure properties programmatically at run time and it doesn't reset property value at run time. For reference, Java class files for Custom Logger, Custom Multiprocess Rolling Appender and Test program are attached along with cutom log4j properties file.[^CustomLogger.java][^customlog.properties][^RuntimeUpdateLoggingPropertiesTest.java] > Log4j 1.x 2.17.2 bridge - Runtime log4j property update doesn't work > > > Key: LOG4J2-3456 > URL: https://issues.apache.org/jira/browse/LOG4J2-3456 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > Attachments: CustomLogger.java, CustomLoggerFactory.java, > CustomMultiProcessRollingAppender.java, > RuntimeUpdateLoggingPropertiesTest.java, customlog.properties > > > In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. > With bridge 2.17.2/2.17.3-SNAPSHOT, we have noticed that we could not update > log4j config properties at run time while same used to work with log4j1.x. It > looks like there is some problem with PropertyConfigurator.configure(url) > when we call it at run time to reconfigure properties programmatically at run > time and it doesn't reset property value at run time. > > For reference, Java class files for Custom Logger, Custom Multiprocess > Rolling Appender and Test program are attached along with cutom log4j > properties > file.[^CustomLogger.java][^customlog.properties][^RuntimeUpdateLoggingPropertiesTest.java] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3455) Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
[ https://issues.apache.org/jira/browse/LOG4J2-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pooja Pandey updated LOG4J2-3455: - Description: In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. With bridge 2.17.2/2.17.3-SNAPSHOT, thread specific log level threshold doesn't work which used to work earlier with log4j1.x. We had achieved this feature by overriding getEffectiveLevel(), but now this doesn't work anymore with log4j1.x bridge since the method getEffectiveLevel() is not getting invoked to set effective level. For reference, Java class files for Custom Logger, Custom Multiprocess Rolling Appender and Test program are attached along with cutom log4j properties file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java] was: In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. With bridge 2.17.2/2.17/3-SNAPSHOT, thread specific log level threshold doesn't work which used to work earlier with log4j1.x. We had achieved this feature by overriding getEffectiveLevel(), but now this doesn't work anymore with log4j1.x bridge since the method getEffectiveLevel() is not getting invoked to set effective level. For reference, Java class files for Custom Logger, Custom Multiprocess Rolling Appender and Test program are attached along with cutom log4j properties file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java] > Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work > -- > > Key: LOG4J2-3455 > URL: https://issues.apache.org/jira/browse/LOG4J2-3455 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > Attachments: CustomLogger.java, CustomLoggerFactory.java, > CustomMultiProcessRollingAppender.java, ThreadLevelLogThresholdTest.java, > customlog.properties > > > In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. > With bridge 2.17.2/2.17.3-SNAPSHOT, thread specific log level threshold > doesn't work which used to work earlier with log4j1.x. We had achieved this > feature by overriding getEffectiveLevel(), but now this doesn't work anymore > with log4j1.x bridge since the method getEffectiveLevel() is not getting > invoked to set effective level. > > For reference, Java class files for Custom Logger, Custom Multiprocess > Rolling Appender and Test program are attached along with cutom log4j > properties > file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [logging-log4j2] stefanvodita commented on a change in pull request #809: LOG4J2-3452: Fix race condition in FileUtils.mkdir()
stefanvodita commented on a change in pull request #809:
URL: https://github.com/apache/logging-log4j2/pull/809#discussion_r838804651
##
File path:
log4j-core/src/test/java/org/apache/logging/log4j/core/util/FileUtilsTest.java
##
@@ -78,4 +86,56 @@ public void
testFileFromUriWithSpacesAndPlusCharactersInName() throws Exception
assertTrue(file.exists(), "file exists");
}
+@Nested
+class TestMkdir {
+final String path = "src/test/resources/test-dir";
Review comment:
Thanks for the suggestion! This could allow me to simplify the test
setup quite a bit.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Comment Edited] (LOG4J2-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514807#comment-17514807
]
Matt Sicker edited comment on LOG4J2-2795 at 3/30/22, 4:35 PM:
---
Well, compare the startup time of instantiating DefaultInjector (and even
running init() on it) versus the rest of the system. The DI container is the
easy part at this point. I'd expect that our implementation is faster than CDI
or Guice because it doesn't have the same huge list of features and added
indirection (interceptors, etc). At this point, I'd like to try to figure out
what remaining aspects are causing this slowdown. While I wouldn't expect this
to be much of an issue in typical applications, it would certainly be annoying
in CLI tools or cloud native micro services where you deploy super often and
startup time matters more. I know just how annoying it is to set up liveness
probes in K8s to wait for Spring Boot to start up, for example, so I know what
you mean and would love to see how else we can improve this.
I'll note in contrast, running the same thing on my machine executes in less
than 100ms, so it's gotten harder for me to find the remaining low hanging
fruit as they're all blending together at this point. If you're willing to test
out a few combinations of things, can you compare how different versions of
Java perform here? Would be nice to see how it compares with different types of
disk, too (e.g., if a cloud service is using something like EBS versus using a
local NVMe drive), to see how much of an issue this is caused by loading files
rather than executing anything redundant.
Edit: I should also note that last night, I made more optimizations to
PluginManager so that it invokes collectPlugins() at most once per category, so
that should save some time, too, though I don't expect it to be much (or if it
is a lot, hooray).
was (Author: jvz):
Well, compare the startup time of instantiating DefaultInjector (and even
running init() on it) versus the rest of the system. The DI container is the
easy part at this point. I'd expect that our implementation is faster than CDI
or Guice because it doesn't have the same huge list of features and added
indirection (interceptors, etc). At this point, I'd like to try to figure out
what remaining aspects are causing this slowdown. While I wouldn't expect this
to be much of an issue in typical applications, it would certainly be annoying
in CLI tools or cloud native micro services where you deploy super often and
startup time matters more. I know just how annoying it is to set up liveness
probes in K8s to wait for Spring Boot to start up, for example, so I know what
you mean and would love to see how else we can improve this.
I'll note in contrast, running the same thing on my machine executes in less
than 100ms, so it's gotten harder for me to find the remaining low hanging
fruit as they're all blending together at this point. If you're willing to test
out a few combinations of things, can you compare how different versions of
Java perform here? Would be nice to see how it compares with different types of
disk, too (e.g., if a cloud service is using something like EBS versus using a
local NVMe drive), to see how much of an issue this is caused by loading files
rather than executing anything redundant.
> 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-2795) Make LogManager/LoggerContext creation time reasonable
[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514807#comment-17514807
]
Matt Sicker commented on LOG4J2-2795:
-
Well, compare the startup time of instantiating DefaultInjector (and even
running init() on it) versus the rest of the system. The DI container is the
easy part at this point. I'd expect that our implementation is faster than CDI
or Guice because it doesn't have the same huge list of features and added
indirection (interceptors, etc). At this point, I'd like to try to figure out
what remaining aspects are causing this slowdown. While I wouldn't expect this
to be much of an issue in typical applications, it would certainly be annoying
in CLI tools or cloud native micro services where you deploy super often and
startup time matters more. I know just how annoying it is to set up liveness
probes in K8s to wait for Spring Boot to start up, for example, so I know what
you mean and would love to see how else we can improve this.
I'll note in contrast, running the same thing on my machine executes in less
than 100ms, so it's gotten harder for me to find the remaining low hanging
fruit as they're all blending together at this point. If you're willing to test
out a few combinations of things, can you compare how different versions of
Java perform here? Would be nice to see how it compares with different types of
disk, too (e.g., if a cloud service is using something like EBS versus using a
local NVMe drive), to see how much of an issue this is caused by loading files
rather than executing anything redundant.
> 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] [Updated] (LOG4J2-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Pandey updated LOG4J2-3457:
-
Description:
In our application we require a rolling file appender which can be used across
multiple processes targeting the same file.
I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
process rolling file appender, if not then is there any plan to support this
feature in future releases??
For reference, as per our application requirement, I am attaching sample java
class files for custom appender, custom multi process rolling appender, sample
test program with multiple threads for which we can run multiple instances to
test multi process rolling and log4j property
file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
In one of the mail chain to group Log4J Users List
, [~ralphgoers] pointed out that
{color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
used across multiple processes targeting the same file either. I’d love to know
how you avoided having the file roll multiple times (once for each
process)"_{color}.
!CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG!
was:
In our application we require a rolling file appender which can be used across
multiple processes targeting the same file.
I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
process rolling file appender, if not then is there any plan to support this
feature in future releases??
For reference, as per our application requirement, I am attaching sample java
class files for custom appender, custom multi process rolling appender, sample
test program with multiple threads for which we can run multiple instances to
test multi process rolling and log4j property
file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
In one of the mail chain to group Log4J Users List
, [~ralphgoers] pointed out that
{color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
used across multiple processes targeting the same file either. I’d love to know
how you avoided having the file roll multiple times (once for each
process)"_{color}.
!CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG!
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments:
> CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG,
> CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> In our application we require a rolling file appender which can be used
> across multiple processes targeting the same file.
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
> !CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Pandey updated LOG4J2-3457:
-
Description:
In our application we require a rolling file appender which can be used across
multiple processes targeting the same file.
I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
process rolling file appender, if not then is there any plan to support this
feature in future releases??
For reference, as per our application requirement, I am attaching sample java
class files for custom appender, custom multi process rolling appender, sample
test program with multiple threads for which we can run multiple instances to
test multi process rolling and log4j property
file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
In one of the mail chain to group Log4J Users List
, [~ralphgoers] pointed out that
{color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
used across multiple processes targeting the same file either. I’d love to know
how you avoided having the file roll multiple times (once for each
process)"_{color}.
!CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG|width=756,height=434!
was:
In our application we require a rolling file appender which can be used across
multiple processes targeting the same file.
I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
process rolling file appender, if not then is there any plan to support this
feature in future releases??
For reference, as per our application requirement, I am attaching sample java
class files for custom appender, custom multi process rolling appender, sample
test program with multiple threads for which we can run multiple instances to
test multi process rolling and log4j property
file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
In one of the mail chain to group Log4J Users List
, [~ralphgoers] pointed out that
{color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
used across multiple processes targeting the same file either. I’d love to know
how you avoided having the file roll multiple times (once for each
process)"_{color}.
!CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG!
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments:
> CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG,
> CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> In our application we require a rolling file appender which can be used
> across multiple processes targeting the same file.
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
> !CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG|width=756,height=434!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Pandey updated LOG4J2-3457:
-
Description:
In our application we require a rolling file appender which can be used across
multiple processes targeting the same file.
I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
process rolling file appender, if not then is there any plan to support this
feature in future releases??
For reference, as per our application requirement, I am attaching sample java
class files for custom appender, custom multi process rolling appender, sample
test program with multiple threads for which we can run multiple instances to
test multi process rolling and log4j property
file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
In one of the mail chain to group Log4J Users List
, [~ralphgoers] pointed out that
{color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
used across multiple processes targeting the same file either. I’d love to know
how you avoided having the file roll multiple times (once for each
process)"_{color}.
!CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG!
was:
Hi team,
Our application requires a rolling file appender which can be used across
multiple processes targeting the same file.
I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
process rolling file appender, if not then is there any plan to support this
feature in future releases??
For reference, as per our application requirement, I am attaching sample java
class files for custom appender, custom multi process rolling appender, sample
test program with multiple threads for which we can run multiple instances to
test multi process rolling and log4j property
file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
In one of the mail chain to group Log4J Users List
, [~ralphgoers] pointed out that
{color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
used across multiple processes targeting the same file either. I’d love to know
how you avoided having the file roll multiple times (once for each
process)"_{color}.
!CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG!
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments:
> CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG,
> CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> In our application we require a rolling file appender which can be used
> across multiple processes targeting the same file.
>
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
>
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
> !CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3456) Log4j 1.x 2.17.2 bridge - Runtime log4j property update doesn't work
[ https://issues.apache.org/jira/browse/LOG4J2-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pooja Pandey updated LOG4J2-3456: - Description: In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. With bridge 2.17.2/2.17/3-SNAPSHOT, we have noticed that we could not update log4j config properties at run time while same used to work with log4j1.x. It looks like there is some problem with PropertyConfigurator.configure(url) when we call it at run time to reconfigure properties programmatically at run time and it doesn't reset property value at run time. For reference, Java class files for Custom Logger, Custom Multiprocess Rolling Appender and Test program are attached along with cutom log4j properties file.[^CustomLogger.java][^customlog.properties][^RuntimeUpdateLoggingPropertiesTest.java] was: In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. With bridge 2.17.2/2.17/3-SNAPSHOT, we have noticed that we could not update log4j config properties at run time while same used to work with log4j1.x. It looks like there is some problem with PropertyConfigurator.configure(url) when we call it at run time to reconfigure properties programmatically at run time and it doesn't reset property value at run time. (Will add more details in a separate ticket) For reference, Java class files for Custom Logger, Custom Multiprocess Rolling Appender and Test program are attached along with cutom log4j properties file.[^CustomLogger.java][^customlog.properties][^RuntimeUpdateLoggingPropertiesTest.java] > Log4j 1.x 2.17.2 bridge - Runtime log4j property update doesn't work > > > Key: LOG4J2-3456 > URL: https://issues.apache.org/jira/browse/LOG4J2-3456 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > Attachments: CustomLogger.java, CustomLoggerFactory.java, > CustomMultiProcessRollingAppender.java, > RuntimeUpdateLoggingPropertiesTest.java, customlog.properties > > > In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. > With bridge 2.17.2/2.17/3-SNAPSHOT, we have noticed that we could not update > log4j config properties at run time while same used to work with log4j1.x. It > looks like there is some problem with PropertyConfigurator.configure(url) > when we call it at run time to reconfigure properties programmatically at run > time and it doesn't reset property value at run time. > > For reference, Java class files for Custom Logger, Custom Multiprocess > Rolling Appender and Test program are attached along with cutom log4j > properties > file.[^CustomLogger.java][^customlog.properties][^RuntimeUpdateLoggingPropertiesTest.java] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3455) Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
[ https://issues.apache.org/jira/browse/LOG4J2-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pooja Pandey updated LOG4J2-3455: - Description: In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. With bridge 2.17.2/2.17/3-SNAPSHOT, thread specific log level threshold doesn't work which used to work earlier with log4j1.x. We had achieved this feature by overriding getEffectiveLevel(), but now this doesn't work anymore with log4j1.x bridge since the method getEffectiveLevel() is not getting invoked to set effective level. For reference, Java class files for Custom Logger, Custom Multiprocess Rolling Appender and Test program are attached along with cutom log4j properties file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java] was: In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. With bridge 2.17.2/2.17/3-SNAPSHOT, thread specific log level threshold doesn't work which used to work earlier with log4j1.x. We had achieved this feature by overriding getEffectiveLevel(), but now this doesn't work anymore with log4j1.x bridge since the method getEffectiveLevel() is not getting invoked to set effective level. (Will add more details in a separate ticket) For reference, Java class files for Custom Logger, Custom Multiprocess Rolling Appender and Test program are attached along with cutom log4j properties file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java] > Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work > -- > > Key: LOG4J2-3455 > URL: https://issues.apache.org/jira/browse/LOG4J2-3455 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > Attachments: CustomLogger.java, CustomLoggerFactory.java, > CustomMultiProcessRollingAppender.java, ThreadLevelLogThresholdTest.java, > customlog.properties > > > In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. > With bridge 2.17.2/2.17/3-SNAPSHOT, thread specific log level threshold > doesn't work which used to work earlier with log4j1.x. We had achieved this > feature by overriding getEffectiveLevel(), but now this doesn't work anymore > with log4j1.x bridge since the method getEffectiveLevel() is not getting > invoked to set effective level. > > For reference, Java class files for Custom Logger, Custom Multiprocess > Rolling Appender and Test program are attached along with cutom log4j > properties > file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Pandey updated LOG4J2-3457:
-
Description:
Hi team,
Our application requires a rolling file appender which can be used across
multiple processes targeting the same file.
I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
process rolling file appender, if not then is there any plan to support this
feature in future releases??
For reference, as per our application requirement, I am attaching sample java
class files for custom appender, custom multi process rolling appender, sample
test program with multiple threads for which we can run multiple instances to
test multi process rolling and log4j property
file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
In one of the mail chain to group Log4J Users List
, [~ralphgoers] pointed out that
{color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
used across multiple processes targeting the same file either. I’d love to know
how you avoided having the file roll multiple times (once for each
process)"_{color}.
!CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG!
was:
Hi team,
Our application we require a rolling file appender which can be used across
multiple processes targeting the same file.
I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
process rolling file appender, if not then is there any plan to support this
feature in future releases??
For reference, as per our application requirement, I am attaching sample java
class files for custom appender, custom multi process rolling appender, sample
test program with multiple threads for which we can run multiple instances to
test multi process rolling and log4j property
file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
In one of the mail chain to group Log4J Users List
, [~ralphgoers] pointed out that
{color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
used across multiple processes targeting the same file either. I’d love to know
how you avoided having the file roll multiple times (once for each
process)"_{color}.
!CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG!
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments:
> CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG,
> CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> Hi team,
> Our application requires a rolling file appender which can be used across
> multiple processes targeting the same file.
>
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
>
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
> !CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Pandey updated LOG4J2-3457:
-
Attachment:
CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments:
> CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG,
> CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> Hi team,
> Our application we require a rolling file appender which can be used across
> multiple processes targeting the same file.
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#FF}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
>
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Pandey updated LOG4J2-3457:
-
Description:
Hi team,
Our application we require a rolling file appender which can be used across
multiple processes targeting the same file.
I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
process rolling file appender, if not then is there any plan to support this
feature in future releases??
For reference, as per our application requirement, I am attaching sample java
class files for custom appender, custom multi process rolling appender, sample
test program with multiple threads for which we can run multiple instances to
test multi process rolling and log4j property
file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
In one of the mail chain to group Log4J Users List
, [~ralphgoers] pointed out that
{color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
used across multiple processes targeting the same file either. I’d love to know
how you avoided having the file roll multiple times (once for each
process)"_{color}.
!CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG!
was:
Hi team,
Our application we require a rolling file appender which can be used across
multiple processes targeting the same file.
In one of the mail chain to group Log4J Users List
, [~ralphgoers] pointed out that
{color:#FF}_"FWIW the Log4j 2 RollingFileAppender does not support being
used across multiple processes targeting the same file either. I’d love to know
how you avoided having the file roll multiple times (once for each
process)"_{color}.
I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
process rolling file appender, if not then is there any plan to support this
feature in future releases??
For reference, as per our application requirement, I am attaching sample java
class files for custom appender, custom multi process rolling appender, sample
test program with multiple threads for which we can run multiple instances to
test multi process rolling and log4j property
file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments:
> CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG,
> CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> Hi team,
> Our application we require a rolling file appender which can be used across
> multiple processes targeting the same file.
>
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
>
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#ff}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
> !CitedText-RollingFileAppenderNoSupportForMultProcessWritingToSameFile.PNG!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (LOG4J2-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time.
Pooja Pandey created LOG4J2-3457:
Summary: Log4j 1.x 2.17.2 bridge - Does standard
RollingFileAppender supports multiple process writing to same log file at the
same time.
Key: LOG4J2-3457
URL: https://issues.apache.org/jira/browse/LOG4J2-3457
Project: Log4j 2
Issue Type: Question
Components: Log4j 1.2 bridge
Affects Versions: 2.17.2
Reporter: Pooja Pandey
Attachments: CustomLogger.java, CustomLoggerFactory.java,
CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
customlog.properties
Hi team,
Our application we require a rolling file appender which can be used across
multiple processes targeting the same file.
In one of the mail chain to group Log4J Users List
, [~ralphgoers] pointed out that
{color:#FF}_"FWIW the Log4j 2 RollingFileAppender does not support being
used across multiple processes targeting the same file either. I’d love to know
how you avoided having the file roll multiple times (once for each
process)"_{color}.
I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
process rolling file appender, if not then is there any plan to support this
feature in future releases??
For reference, as per our application requirement, I am attaching sample java
class files for custom appender, custom multi process rolling appender, sample
test program with multiple threads for which we can run multiple instances to
test multi process rolling and log4j property
file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3457) Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple process writing to same log file at the same time??
[
https://issues.apache.org/jira/browse/LOG4J2-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Pandey updated LOG4J2-3457:
-
Summary: Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender
supports multiple process writing to same log file at the same time?? (was:
Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
process writing to same log file at the same time.)
> Log4j 1.x 2.17.2 bridge - Does standard RollingFileAppender supports multiple
> process writing to same log file at the same time??
> -
>
> Key: LOG4J2-3457
> URL: https://issues.apache.org/jira/browse/LOG4J2-3457
> Project: Log4j 2
> Issue Type: Question
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Priority: Major
> Attachments: CustomLogger.java, CustomLoggerFactory.java,
> CustomMultiProcessRollingAppender.java, JavaLoggingMultiThTest.java,
> customlog.properties
>
>
> Hi team,
> Our application we require a rolling file appender which can be used across
> multiple processes targeting the same file.
> In one of the mail chain to group Log4J Users List
> , [~ralphgoers] pointed out that
> {color:#FF}_"FWIW the Log4j 2 RollingFileAppender does not support being
> used across multiple processes targeting the same file either. I’d love to
> know how you avoided having the file roll multiple times (once for each
> process)"_{color}.
>
> I wanted to check if current log4j1.x 2.17.2 bridge version supports multi
> process rolling file appender, if not then is there any plan to support this
> feature in future releases??
> For reference, as per our application requirement, I am attaching sample java
> class files for custom appender, custom multi process rolling appender,
> sample test program with multiple threads for which we can run multiple
> instances to test multi process rolling and log4j property
> file.[^CustomLogger.java][^JavaLoggingMultiThTest.java][^customlog.properties]
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3453) Filters contains invalid attributes "onMatch", "onMismatch"
[
https://issues.apache.org/jira/browse/LOG4J2-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514701#comment-17514701
]
Piotr Karwasz commented on LOG4J2-3453:
---
[~ana4],
Thanks for reporting this issue.
It's a small bug in the properties configuration, which assumes that all
filters must have an `onMatch` and `onMismatch` property. {{"Filters"}} does
not have these properties, hence the error.
Anyway this should not prevent the configuration from working correctly.
> Filters contains invalid attributes "onMatch", "onMismatch"
> ---
>
> Key: LOG4J2-3453
> URL: https://issues.apache.org/jira/browse/LOG4J2-3453
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Luning Wang
>Priority: Major
> Fix For: 2.17.2
>
>
> The following is my log4j2.properties
> {code:java}
> appender.console.filter.1.type = Filters
> appender.console.filter.1.a.type = ThresholdFilter
> appender.console.filter.1.a.level = info
> appender.console.filter.1.b.type = RegexFilter
> appender.console.filter.1.b.regex = .*Thrift error occurred during processing
> of message.*
> appender.console.filter.1.b.onMatch = deny
> appender.console.filter.1.b.onMismatch = neutral
> {code}
> When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
> `Filters contains invalid attributes "onMatch", "onMismatch"` error message.
> What is correctly conf?
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3454) how to force rolling file appender to create a new log file every time when we start the application?
[ https://issues.apache.org/jira/browse/LOG4J2-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Janardhan Naidu updated LOG4J2-3454: Description: HI Team, I am in process of migrating the log4j1 to log4j2, where we are rewriting the appenders with the help of AbstractAppender Plugin or using the property file. I have multiple questions regarding this, please help me to resolve the same. # how to force rolling file appender to create a new log file every time when we start the application? here, consider appenders are configured in property file. # We are rewriting one of the rollingfileappender using the abstractappender/abstractfileappender plugin way, But i am unable to find a method which will get executed before starting of the appender!. in log4j1, we had a method called *checkEntryConditions.* So what is the equalent api in log4j2.? FYI, we are overriding this method to set all our configurations like backup the old logfile, createnew logger, rolling etc.., # Also, we need to set the ConversionPattern based on the loggername, how we can achieve this.? in log4j1, we were extending patternLayout and overriding the format method to do the same. So how we can acheive this using log4j2? Thanks Janardhan was: HI Team, I am in process of migrating the log4j1 to log4j2, where we are rewriting the appenders with the help of AbstractAppender Plugin or using the property file. I have multiple questions regarding this, please help me to resolve the same. # how to force rolling file appender to create a new log file every time when we start the application? here, consider appenders are configured in property file. # We are rewriting one of the rollingfileappender using the abstractappender/abstractfileappender plugin way, But i am unable to find a method which will get executed before starting of the appender!. in log4j1, we had a method called *checkEntryConditions.* So what is the equalent api in log4j2.? FYI, we are overriding this method to set all our configurations like backup the old logfile, createnew logger, rolling etc.., Thanks Janardhan > how to force rolling file appender to create a new log file every time when > we start the application? > - > > Key: LOG4J2-3454 > URL: https://issues.apache.org/jira/browse/LOG4J2-3454 > Project: Log4j 2 > Issue Type: Question >Affects Versions: 2.17.2 >Reporter: Janardhan Naidu >Priority: Major > > HI Team, > > I am in process of migrating the log4j1 to log4j2, where we are rewriting the > appenders with the help of AbstractAppender Plugin or using the property > file. I have multiple questions regarding this, please help me to resolve the > same. > # how to force rolling file appender to create a new log file every time > when we start the application? here, consider appenders are configured in > property file. > # We are rewriting one of the rollingfileappender using the > abstractappender/abstractfileappender plugin way, But i am unable to find a > method which will get executed before starting of the appender!. in log4j1, > we had a method called *checkEntryConditions.* So what is the equalent api in > log4j2.? FYI, we are overriding this method to set all our configurations > like backup the old logfile, createnew logger, rolling etc.., > # Also, we need to set the ConversionPattern based on the loggername, how we > can achieve this.? in log4j1, we were extending patternLayout and overriding > the format method to do the same. So how we can acheive this using log4j2? > > Thanks > Janardhan -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3453) Filters contains invalid attributes "onMatch", "onMismatch"
[
https://issues.apache.org/jira/browse/LOG4J2-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luning Wang updated LOG4J2-3453:
Description:
The following is my log4j2.properties
{code:java}
appender.console.filter.1.type = Filters
appender.console.filter.1.a.type = ThresholdFilter
appender.console.filter.1.a.level = info
appender.console.filter.1.b.type = RegexFilter
appender.console.filter.1.b.regex = .*Thrift error occurred during processing
of message.*
appender.console.filter.1.b.onMatch = deny
appender.console.filter.1.b.onMismatch = neutral
{code}
When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
`Filters contains invalid attributes "onMatch", "onMismatch"` error message.
What is correctly conf?
was:
The following is my log4j2.properties
{code:java}
appender.console.filter.1.type = Filters
appender.console.filter.1.a.type = ThresholdFilter
appender.console.filter.1.a.level = info
# SPARK-34128: Suppress undesirable TTransportException warnings, due to
THRIFT-4805
appender.console.filter.1.b.type = RegexFilter
appender.console.filter.1.b.regex = .*Thrift error occurred during processing
of message.*
appender.console.filter.1.b.onMatch = deny
appender.console.filter.1.b.onMismatch = neutral
{code}
When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
`Filters contains invalid attributes "onMatch", "onMismatch"` error message.
What is correctly conf?
> Filters contains invalid attributes "onMatch", "onMismatch"
> ---
>
> Key: LOG4J2-3453
> URL: https://issues.apache.org/jira/browse/LOG4J2-3453
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Luning Wang
>Priority: Major
> Fix For: 2.17.2
>
>
> The following is my log4j2.properties
> {code:java}
> appender.console.filter.1.type = Filters
> appender.console.filter.1.a.type = ThresholdFilter
> appender.console.filter.1.a.level = info
> appender.console.filter.1.b.type = RegexFilter
> appender.console.filter.1.b.regex = .*Thrift error occurred during processing
> of message.*
> appender.console.filter.1.b.onMatch = deny
> appender.console.filter.1.b.onMismatch = neutral
> {code}
> When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
> `Filters contains invalid attributes "onMatch", "onMismatch"` error message.
> What is correctly conf?
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3453) Filters contains invalid attributes "onMatch", "onMismatch"
[
https://issues.apache.org/jira/browse/LOG4J2-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514670#comment-17514670
]
Luning Wang commented on LOG4J2-3453:
-
[~pkarwasz] Sorry, I copy an error conf, I have updated my conf, It will
throw a `Filters contains invalid attributes "onMatch", "onMismatch"` error
message too.
{code:java}
appender.console.filter.1.type = Filters appender.console.filter.1.a.type =
ThresholdFilter appender.console.filter.1.a.level = info
appender.console.filter.1.b.type = RegexFilter
appender.console.filter.1.b.regex = .*Thrift error occurred during processing
of message.* appender.console.filter.1.b.onMatch = deny
appender.console.filter.1.b.onMismatch = neutral {code}
> Filters contains invalid attributes "onMatch", "onMismatch"
> ---
>
> Key: LOG4J2-3453
> URL: https://issues.apache.org/jira/browse/LOG4J2-3453
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Luning Wang
>Priority: Major
> Fix For: 2.17.2
>
>
> The following is my log4j2.properties
> {code:java}
> appender.console.filter.1.type = Filters
> appender.console.filter.1.a.type = ThresholdFilter
> appender.console.filter.1.a.level = info
> appender.console.filter.1.b.type = RegexFilter
> appender.console.filter.1.b.regex = .*Thrift error occurred during processing
> of message.*
> appender.console.filter.1.b.onMatch = deny
> appender.console.filter.1.b.onMismatch = neutral
> {code}
> When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
> `Filters contains invalid attributes "onMatch", "onMismatch"` error message.
> What is correctly conf?
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3453) Filters contains invalid attributes "onMatch", "onMismatch"
[
https://issues.apache.org/jira/browse/LOG4J2-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luning Wang updated LOG4J2-3453:
Description:
The following is my log4j2.properties
{code:java}
appender.console.filter.1.type = Filters
appender.console.filter.1.a.type = ThresholdFilter
appender.console.filter.1.a.level = info
appender.console.filter.1.b.type = RegexFilter
appender.console.filter.1.b.regex = .*Thrift error occurred during processing
of message.*
appender.console.filter.1.b.onMatch = deny
appender.console.filter.1.b.onMismatch = neutral
{code}
When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
`Filters contains invalid attributes "onMatch", "onMismatch"` error message.
What is correctly conf?
was:
The following is my log4j2.properties
{code:java}
log4j2.appender.event.filter.1.type = Filters
log4j2.appender.event.filter.1.a.type = RegexFilter
log4j2.appender.event.filter.1.a.regex =
.*(C_Radon_(Level|Updated|Running)|C_Solar_(PowerTotal|PowerEast|PowerWest|TotalYield|DailyYield)|OFFLINE.*10\.13\.0\.70).*
log4j2.appender.event.filter.1.a.onMatch = DENY
log4j2.appender.event.filter.1.a.onMismatch = NEUTRAL
log4j2.appender.event.filter.1.b.type = RegexFilter
log4j2.appender.event.filter.1.b.regex = .*(C_Air_).*
log4j2.appender.event.filter.1.b.onMatch = DENY
log4j2.appender.event.filter.1.b.onMismatch = NEUTRAL {code}
When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
`Filters contains invalid attributes "onMatch", "onMismatch"` error message.
What is correctly conf?
> Filters contains invalid attributes "onMatch", "onMismatch"
> ---
>
> Key: LOG4J2-3453
> URL: https://issues.apache.org/jira/browse/LOG4J2-3453
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Luning Wang
>Priority: Major
> Fix For: 2.17.2
>
>
> The following is my log4j2.properties
> {code:java}
> appender.console.filter.1.type = Filters
> appender.console.filter.1.a.type = ThresholdFilter
> appender.console.filter.1.a.level = info
> appender.console.filter.1.b.type = RegexFilter
> appender.console.filter.1.b.regex = .*Thrift error occurred during processing
> of message.*
> appender.console.filter.1.b.onMatch = deny
> appender.console.filter.1.b.onMismatch = neutral
> {code}
> When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
> `Filters contains invalid attributes "onMatch", "onMismatch"` error message.
> What is correctly conf?
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] (LOG4J2-3453) Filters contains invalid attributes "onMatch", "onMismatch"
[ https://issues.apache.org/jira/browse/LOG4J2-3453 ]
Piotr Karwasz deleted comment on LOG4J2-3453:
---
was (Author: pkarwasz):
[~ana4],
The Log4j2 properties format does not use the {{log4j2.}} prefix.
After removing the {{log4j2.}} prefixes, your configuration fails, because you
have a trailing space after the last {{NEUTRAL}}.
> Filters contains invalid attributes "onMatch", "onMismatch"
> ---
>
> Key: LOG4J2-3453
> URL: https://issues.apache.org/jira/browse/LOG4J2-3453
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Luning Wang
>Priority: Major
> Fix For: 2.17.2
>
>
> The following is my log4j2.properties
> {code:java}
> appender.console.filter.1.type = Filters
> appender.console.filter.1.a.type = ThresholdFilter
> appender.console.filter.1.a.level = info
> # SPARK-34128: Suppress undesirable TTransportException warnings, due to
> THRIFT-4805
> appender.console.filter.1.b.type = RegexFilter
> appender.console.filter.1.b.regex = .*Thrift error occurred during processing
> of message.*
> appender.console.filter.1.b.onMatch = deny
> appender.console.filter.1.b.onMismatch = neutral
> {code}
> When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
> `Filters contains invalid attributes "onMatch", "onMismatch"` error message.
> What is correctly conf?
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3453) Filters contains invalid attributes "onMatch", "onMismatch"
[
https://issues.apache.org/jira/browse/LOG4J2-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luning Wang updated LOG4J2-3453:
Description:
The following is my log4j2.properties
{code:java}
appender.console.filter.1.type = Filters
appender.console.filter.1.a.type = ThresholdFilter
appender.console.filter.1.a.level = info
# SPARK-34128: Suppress undesirable TTransportException warnings, due to
THRIFT-4805
appender.console.filter.1.b.type = RegexFilter
appender.console.filter.1.b.regex = .*Thrift error occurred during processing
of message.*
appender.console.filter.1.b.onMatch = deny
appender.console.filter.1.b.onMismatch = neutral
{code}
When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
`Filters contains invalid attributes "onMatch", "onMismatch"` error message.
What is correctly conf?
was:
The following is my log4j2.properties
{code:java}
appender.console.filter.1.type = Filters
appender.console.filter.1.a.type = ThresholdFilter
appender.console.filter.1.a.level = info
appender.console.filter.1.b.type = RegexFilter
appender.console.filter.1.b.regex = .*Thrift error occurred during processing
of message.*
appender.console.filter.1.b.onMatch = deny
appender.console.filter.1.b.onMismatch = neutral
{code}
When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
`Filters contains invalid attributes "onMatch", "onMismatch"` error message.
What is correctly conf?
> Filters contains invalid attributes "onMatch", "onMismatch"
> ---
>
> Key: LOG4J2-3453
> URL: https://issues.apache.org/jira/browse/LOG4J2-3453
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Luning Wang
>Priority: Major
> Fix For: 2.17.2
>
>
> The following is my log4j2.properties
> {code:java}
> appender.console.filter.1.type = Filters
> appender.console.filter.1.a.type = ThresholdFilter
> appender.console.filter.1.a.level = info
> # SPARK-34128: Suppress undesirable TTransportException warnings, due to
> THRIFT-4805
> appender.console.filter.1.b.type = RegexFilter
> appender.console.filter.1.b.regex = .*Thrift error occurred during processing
> of message.*
> appender.console.filter.1.b.onMatch = deny
> appender.console.filter.1.b.onMismatch = neutral
> {code}
> When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
> `Filters contains invalid attributes "onMatch", "onMismatch"` error message.
> What is correctly conf?
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3455) Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
[ https://issues.apache.org/jira/browse/LOG4J2-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pooja Pandey updated LOG4J2-3455: - Description: In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. With bridge 2.17.2/2.17/3-SNAPSHOT, thread specific log level threshold doesn't work which used to work earlier with log4j1.x. We had achieved this feature by overriding getEffectiveLevel(), but now this doesn't work anymore with log4j1.x bridge since the method getEffectiveLevel() is not getting invoked to set effective level. (Will add more details in a separate ticket) For reference, Java class files for Custom Logger, Custom Multiprocess Rolling Appender and Test program are attached along with cutom log4j properties file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java] was: With bridge 2.17.2/2.17/3-SNAPSHOT, thread specific log level threshold doesn't work which used to work earlier with log4j1.x. We had achieved this feature by overriding getEffectiveLevel(), but now this doesn't work anymore with log4j1.x bridge since the method getEffectiveLevel() is not getting invoked to set effective level. (Will add more details in a separate ticket) For reference, Java class files for Custom Logger, Custom Multiprocess Rolling Appender and Test program are attached along with cutom log4j properties file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java] > Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work > -- > > Key: LOG4J2-3455 > URL: https://issues.apache.org/jira/browse/LOG4J2-3455 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.17.2 >Reporter: Pooja Pandey >Priority: Major > Attachments: CustomLogger.java, CustomLoggerFactory.java, > CustomMultiProcessRollingAppender.java, ThreadLevelLogThresholdTest.java, > customlog.properties > > > In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. > With bridge 2.17.2/2.17/3-SNAPSHOT, thread specific log level threshold > doesn't work which used to work earlier with log4j1.x. We had achieved this > feature by overriding getEffectiveLevel(), but now this doesn't work anymore > with log4j1.x bridge since the method getEffectiveLevel() is not getting > invoked to set effective level. (Will add more details in a separate ticket) > > For reference, Java class files for Custom Logger, Custom Multiprocess > Rolling Appender and Test program are attached along with cutom log4j > properties > file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (LOG4J2-3456) Log4j 1.x 2.17.2 bridge - Runtime log4j property update doesn't work
Pooja Pandey created LOG4J2-3456: Summary: Log4j 1.x 2.17.2 bridge - Runtime log4j property update doesn't work Key: LOG4J2-3456 URL: https://issues.apache.org/jira/browse/LOG4J2-3456 Project: Log4j 2 Issue Type: Bug Affects Versions: 2.17.2 Reporter: Pooja Pandey Attachments: CustomLogger.java, CustomLoggerFactory.java, CustomMultiProcessRollingAppender.java, RuntimeUpdateLoggingPropertiesTest.java, customlog.properties In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge. With bridge 2.17.2/2.17/3-SNAPSHOT, we have noticed that we could not update log4j config properties at run time while same used to work with log4j1.x. It looks like there is some problem with PropertyConfigurator.configure(url) when we call it at run time to reconfigure properties programmatically at run time and it doesn't reset property value at run time. (Will add more details in a separate ticket) For reference, Java class files for Custom Logger, Custom Multiprocess Rolling Appender and Test program are attached along with cutom log4j properties file.[^CustomLogger.java][^customlog.properties][^RuntimeUpdateLoggingPropertiesTest.java] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (LOG4J2-3454) how to force rolling file appender to create a new log file every time when we start the application?
Janardhan Naidu created LOG4J2-3454: --- Summary: how to force rolling file appender to create a new log file every time when we start the application? Key: LOG4J2-3454 URL: https://issues.apache.org/jira/browse/LOG4J2-3454 Project: Log4j 2 Issue Type: Question Affects Versions: 2.17.2 Reporter: Janardhan Naidu HI Team, I am in process of migrating the log4j1 to log4j2, where we are rewriting the appenders with the help of AbstractAppender Plugin or using the property file. I have multiple questions regarding this, please help me to resolve the same. # how to force rolling file appender to create a new log file every time when we start the application? here, consider appenders are configured in property file. # We are rewriting one of the rollingfileappender using the abstractappender/abstractfileappender plugin way, But i am unable to find a method which will get executed before starting of the appender!. in log4j1, we had a method called *checkEntryConditions.* So what is the equalent api in log4j2.? FYI, we are overriding this method to set all our configurations like backup the old logfile, createnew logger, rolling etc.., Thanks Janardhan -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (LOG4J2-3455) Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work
Pooja Pandey created LOG4J2-3455: Summary: Log4j 1.x 2.17.2 bridge - Thread specific Log Level Threshold doesn't work Key: LOG4J2-3455 URL: https://issues.apache.org/jira/browse/LOG4J2-3455 Project: Log4j 2 Issue Type: Bug Affects Versions: 2.17.2 Reporter: Pooja Pandey Attachments: CustomLogger.java, CustomLoggerFactory.java, CustomMultiProcessRollingAppender.java, ThreadLevelLogThresholdTest.java, customlog.properties With bridge 2.17.2/2.17/3-SNAPSHOT, thread specific log level threshold doesn't work which used to work earlier with log4j1.x. We had achieved this feature by overriding getEffectiveLevel(), but now this doesn't work anymore with log4j1.x bridge since the method getEffectiveLevel() is not getting invoked to set effective level. (Will add more details in a separate ticket) For reference, Java class files for Custom Logger, Custom Multiprocess Rolling Appender and Test program are attached along with cutom log4j properties file.[^CustomLogger.java][^customlog.properties][^ThreadLevelLogThresholdTest.java] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3453) Filters contains invalid attributes "onMatch", "onMismatch"
[
https://issues.apache.org/jira/browse/LOG4J2-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514653#comment-17514653
]
Piotr Karwasz edited comment on LOG4J2-3453 at 3/30/22, 12:11 PM:
--
[~ana4],
The Log4j2 properties format does not use the {{log4j2.}} prefix.
After removing the {{log4j2.}} prefixes, your configuration fails, because you
have a trailing space after the last {{NEUTRAL}}.
was (Author: pkarwasz):
[~ana4],
The Log4j2 properties format does not use the {{log4j2.}} prefix.
After removing the {{log4j2.}} prefixes, you configuration fails, because you
have a trailing space after the last {{NEUTRAL}}.
> Filters contains invalid attributes "onMatch", "onMismatch"
> ---
>
> Key: LOG4J2-3453
> URL: https://issues.apache.org/jira/browse/LOG4J2-3453
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Luning Wang
>Priority: Major
> Fix For: 2.17.2
>
>
> The following is my log4j2.properties
> {code:java}
> log4j2.appender.event.filter.1.type = Filters
> log4j2.appender.event.filter.1.a.type = RegexFilter
> log4j2.appender.event.filter.1.a.regex =
> .*(C_Radon_(Level|Updated|Running)|C_Solar_(PowerTotal|PowerEast|PowerWest|TotalYield|DailyYield)|OFFLINE.*10\.13\.0\.70).*
> log4j2.appender.event.filter.1.a.onMatch = DENY
> log4j2.appender.event.filter.1.a.onMismatch = NEUTRAL
> log4j2.appender.event.filter.1.b.type = RegexFilter
> log4j2.appender.event.filter.1.b.regex = .*(C_Air_).*
> log4j2.appender.event.filter.1.b.onMatch = DENY
> log4j2.appender.event.filter.1.b.onMismatch = NEUTRAL {code}
> When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
> `Filters contains invalid attributes "onMatch", "onMismatch"` error message.
> What is correctly conf?
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3453) Filters contains invalid attributes "onMatch", "onMismatch"
[
https://issues.apache.org/jira/browse/LOG4J2-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514653#comment-17514653
]
Piotr Karwasz commented on LOG4J2-3453:
---
[~ana4],
The Log4j2 properties format does not use the {{log4j2.}} prefix.
After removing the {{log4j2.}} prefixes, you configuration fails, because you
have a trailing space after the last {{NEUTRAL}}.
> Filters contains invalid attributes "onMatch", "onMismatch"
> ---
>
> Key: LOG4J2-3453
> URL: https://issues.apache.org/jira/browse/LOG4J2-3453
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Luning Wang
>Priority: Major
> Fix For: 2.17.2
>
>
> The following is my log4j2.properties
> {code:java}
> log4j2.appender.event.filter.1.type = Filters
> log4j2.appender.event.filter.1.a.type = RegexFilter
> log4j2.appender.event.filter.1.a.regex =
> .*(C_Radon_(Level|Updated|Running)|C_Solar_(PowerTotal|PowerEast|PowerWest|TotalYield|DailyYield)|OFFLINE.*10\.13\.0\.70).*
> log4j2.appender.event.filter.1.a.onMatch = DENY
> log4j2.appender.event.filter.1.a.onMismatch = NEUTRAL
> log4j2.appender.event.filter.1.b.type = RegexFilter
> log4j2.appender.event.filter.1.b.regex = .*(C_Air_).*
> log4j2.appender.event.filter.1.b.onMatch = DENY
> log4j2.appender.event.filter.1.b.onMismatch = NEUTRAL {code}
> When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
> `Filters contains invalid attributes "onMatch", "onMismatch"` error message.
> What is correctly conf?
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3453) Filters contains invalid attributes "onMatch", "onMismatch"
[
https://issues.apache.org/jira/browse/LOG4J2-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luning Wang updated LOG4J2-3453:
Description:
The following is my log4j2.properties
{code:java}
log4j2.appender.event.filter.1.type = Filters
log4j2.appender.event.filter.1.a.type = RegexFilter
log4j2.appender.event.filter.1.a.regex =
.*(C_Radon_(Level|Updated|Running)|C_Solar_(PowerTotal|PowerEast|PowerWest|TotalYield|DailyYield)|OFFLINE.*10\.13\.0\.70).*
log4j2.appender.event.filter.1.a.onMatch = DENY
log4j2.appender.event.filter.1.a.onMismatch = NEUTRAL
log4j2.appender.event.filter.1.b.type = RegexFilter
log4j2.appender.event.filter.1.b.regex = .*(C_Air_).*
log4j2.appender.event.filter.1.b.onMatch = DENY
log4j2.appender.event.filter.1.b.onMismatch = NEUTRAL {code}
When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
`Filters contains invalid attributes "onMatch", "onMismatch"` error message.
What is correctly conf?
was:
{code:java}
log4j2.appender.event.filter.1.type = Filters
log4j2.appender.event.filter.1.a.type = RegexFilter
log4j2.appender.event.filter.1.a.regex =
.*(C_Radon_(Level|Updated|Running)|C_Solar_(PowerTotal|PowerEast|PowerWest|TotalYield|DailyYield)|OFFLINE.*10\.13\.0\.70).*
log4j2.appender.event.filter.1.a.onMatch = DENY
log4j2.appender.event.filter.1.a.onMismatch = NEUTRAL
log4j2.appender.event.filter.1.b.type = RegexFilter
log4j2.appender.event.filter.1.b.regex = .*(C_Air_).*
log4j2.appender.event.filter.1.b.onMatch = DENY
log4j2.appender.event.filter.1.b.onMismatch = NEUTRAL {code}
when I set `log4j2.appender.event.filter.1.type = Filters `
It will throw a error message:`Filters contains invalid attributes "onMatch",
"onMismatch" `.
What is correctly conf?
> Filters contains invalid attributes "onMatch", "onMismatch"
> ---
>
> Key: LOG4J2-3453
> URL: https://issues.apache.org/jira/browse/LOG4J2-3453
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Luning Wang
>Priority: Major
> Fix For: 2.17.2
>
>
> The following is my log4j2.properties
> {code:java}
> log4j2.appender.event.filter.1.type = Filters
> log4j2.appender.event.filter.1.a.type = RegexFilter
> log4j2.appender.event.filter.1.a.regex =
> .*(C_Radon_(Level|Updated|Running)|C_Solar_(PowerTotal|PowerEast|PowerWest|TotalYield|DailyYield)|OFFLINE.*10\.13\.0\.70).*
> log4j2.appender.event.filter.1.a.onMatch = DENY
> log4j2.appender.event.filter.1.a.onMismatch = NEUTRAL
> log4j2.appender.event.filter.1.b.type = RegexFilter
> log4j2.appender.event.filter.1.b.regex = .*(C_Air_).*
> log4j2.appender.event.filter.1.b.onMatch = DENY
> log4j2.appender.event.filter.1.b.onMismatch = NEUTRAL {code}
> When I set 'log4j2.appender.event.filter.1.type = Filters', it will throw a
> `Filters contains invalid attributes "onMatch", "onMismatch"` error message.
> What is correctly conf?
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (LOG4J2-3453) Filters contains invalid attributes "onMatch", "onMismatch"
Luning Wang created LOG4J2-3453:
---
Summary: Filters contains invalid attributes "onMatch",
"onMismatch"
Key: LOG4J2-3453
URL: https://issues.apache.org/jira/browse/LOG4J2-3453
Project: Log4j 2
Issue Type: Bug
Reporter: Luning Wang
Fix For: 2.17.2
{code:java}
log4j2.appender.event.filter.1.type = Filters
log4j2.appender.event.filter.1.a.type = RegexFilter
log4j2.appender.event.filter.1.a.regex =
.*(C_Radon_(Level|Updated|Running)|C_Solar_(PowerTotal|PowerEast|PowerWest|TotalYield|DailyYield)|OFFLINE.*10\.13\.0\.70).*
log4j2.appender.event.filter.1.a.onMatch = DENY
log4j2.appender.event.filter.1.a.onMismatch = NEUTRAL
log4j2.appender.event.filter.1.b.type = RegexFilter
log4j2.appender.event.filter.1.b.regex = .*(C_Air_).*
log4j2.appender.event.filter.1.b.onMatch = DENY
log4j2.appender.event.filter.1.b.onMismatch = NEUTRAL {code}
when I set `log4j2.appender.event.filter.1.type = Filters `
It will throw a error message:`Filters contains invalid attributes "onMatch",
"onMismatch" `.
What is correctly conf?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
