[jira] [Updated] (LOG4J2-3193) ConfigurationFactory cannot find config file property normalized by EnvironmentPropertySource
[ https://issues.apache.org/jira/browse/LOG4J2-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Karwasz updated LOG4J2-3193: -- Fix Version/s: 2.18.0 > ConfigurationFactory cannot find config file property normalized by > EnvironmentPropertySource > - > > Key: LOG4J2-3193 > URL: https://issues.apache.org/jira/browse/LOG4J2-3193 > Project: Log4j 2 > Issue Type: Bug > Components: Configuration >Affects Versions: 2.14.1 >Reporter: David >Assignee: Piotr Karwasz >Priority: Major > Fix For: 2.18.0 > > > I am setting `LOG4J_CONFIGURATION_FILE` as an environment variable, and also > have a `log4j2.component.properties` file that specifies a different value > for `log4j2.configurationFile`. > When `PropertyUtils$Environment.reload` [handles each key value pair and > normalizes the > key|https://github.com/apache/logging-log4j2/blob/rel/2.14.1/log4j-api/src/main/java/org/apache/logging/log4j/util/PropertiesUtil.java#L466], > `EnvironmentPropertySource.getNormalForm` [normalizes the environment > variable|https://github.com/apache/logging-log4j2/blob/rel/2.14.1/log4j-api/src/main/java/org/apache/logging/log4j/util/EnvironmentPropertySource.java#L61] > to `LOG4J_CONFIGURATION_FILE` but `PropertiesPropertySource.getNormalForm` > [normalizes the property from the > file|https://github.com/apache/logging-log4j2/blob/rel/2.14.1/log4j-api/src/main/java/org/apache/logging/log4j/util/PropertiesPropertySource.java#L52] > as `log4j2.configurationFile`. So _both_ values end up in the `normalized` > Map. > Then when `ConfigurationFactory` [gets the configuration file > property|https://github.com/apache/logging-log4j2/blob/rel/2.14.1/log4j-core/src/main/java/org/apache/logging/log4j/core/config/ConfigurationFactory.java#L398] > it only looks for `log4j.configurationFile` and ignores the > LOG4J_CONFIGURATION_FILE environment variable. > This seems to contradict the > [documentation|https://logging.apache.org/log4j/2.x/manual/configuration.html#SystemProperties] > which says that environment variables should take precedence over properties > files. > If I'm not mistaken and this is truly a bug, then I'd be happy to work on a > PR if it would get it resolved more quickly. I would just need some guidance > about the proper solution. Should `EnvironmentPropertySource.getNormalForm` > be updated to produce the same style output as > `PropertyPropertySource.getNormalForm`? The [tests > indicate|https://github.com/apache/logging-log4j2/blob/rel/2.14.1/log4j-api/src/test/java/org/apache/logging/log4j/util/EnvironmentPropertySourceTest.java#L43] > that the current behavior is not an accident, so I'm unsure what ought to be > done. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (LOG4J2-3447) Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing huge data in multithreading)
[
https://issues.apache.org/jira/browse/LOG4J2-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Karwasz resolved LOG4J2-3447.
---
Resolution: Fixed
[~PoojaTheCoder],
Can you check the latest {{2.17.3-SNAPSHOT}} snapshot and close the issue if it
fixes your problem?
> Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing
> huge data in multithreading)
> --
>
> Key: LOG4J2-3447
> URL: https://issues.apache.org/jira/browse/LOG4J2-3447
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
> Attachments: JavaLoggingMultiThTest.txt
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With Log4j1.x there was no issue with multithreading but with log4j 1.x
> bridge we have noticed that in multithreading environment there is a huge
> data loss while logging, however single thread works fine. I see that in
> Category.java which Logger extends; many methods are not synchronized any
> more in log4j1.x bridge however which were synchronized in case of log4j1.x.
> I suspect this could be root causes of this multithreading problem.
> So as per my understanding synchronized class Category.java in the log4j1.x
> has become unsynchronized in log4j1.x 2.17.2 bridge. I am not sure if I am
> missing something.
> We wanted to know how to achieve successful multithreading logging using
> log4j 1.x 2.17.2 bridge.
> For reference, few methods which were synchronized earlier in log4j1.x but
> not anymore in log4j1.x bridge.
> # public void addAppender(final Appender appender)
> # public Appender getAppender(final String name)
> # public void removeAppender(final Appender appender)
> # public void removeAllAppenders()
> # In log4j 1.x bridge following method is used for logging which doesn't
> look like synchronized. -> void maybeLog(final String fqcn, final
> org.apache.logging.log4j.Level level, final Object message, final Throwable
> throwable); However in log4j1.x following method was used which looks like
> synchronized. -> void forcedLog(String fqcn, Priority level, Object message,
> Throwable t) -> void callAppenders(LoggingEvent event), where method void
> callAppenders(LoggingEvent event) looks snychronized.
>
> I am attaching sample test program as well which I have used to test
> multithreading logging in my application. (Please Note that in this test
> program, class CustomLogger is a dummy class, which you would need to replace
> with your logger). We are using Custom Rolling Appender in our application
> and following is the content of log4j properties file.
> [^JavaLoggingMultiThTest.txt]
> #Custom Rolling Appender
> log4j.appender.R=test.CustomMultiProcessRollingAppender
> log4j.appender.R.File=${user.home}/log4j-multithreading-test.log
> log4j.appender.R.RollOverOnStartup=true
> log4j.appender.R.RollOverOnSize=false
> log4j.appender.R.RollOverMaxFileSize=100MB
> log4j.appender.R.RollOverMaxBackupIndex=10
> log4j.appender.R.RollOverOnPeriodic=false
> log4j.appender.R.RollOverPeriodicStartDate=
> log4j.appender.R.RollOverPeriodicFrequency=1
> log4j.appender.R.layout=org.apache.log4j.PatternLayout
> log4j.appender.R.layout.ConversionPattern=%d %-8M [%t] - %m%n
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3447) Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing huge data in multithreading)
[
https://issues.apache.org/jira/browse/LOG4J2-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512685#comment-17512685
]
ASF subversion and git services commented on LOG4J2-3447:
-
Commit c21ffb4d0aec37d0efccd9f87482f7561ad21ce1 in logging-log4j2's branch
refs/heads/release-2.x from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=c21ffb4 ]
Changelog for LOG4J2-3447
> Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing
> huge data in multithreading)
> --
>
> Key: LOG4J2-3447
> URL: https://issues.apache.org/jira/browse/LOG4J2-3447
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
> Attachments: JavaLoggingMultiThTest.txt
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With Log4j1.x there was no issue with multithreading but with log4j 1.x
> bridge we have noticed that in multithreading environment there is a huge
> data loss while logging, however single thread works fine. I see that in
> Category.java which Logger extends; many methods are not synchronized any
> more in log4j1.x bridge however which were synchronized in case of log4j1.x.
> I suspect this could be root causes of this multithreading problem.
> So as per my understanding synchronized class Category.java in the log4j1.x
> has become unsynchronized in log4j1.x 2.17.2 bridge. I am not sure if I am
> missing something.
> We wanted to know how to achieve successful multithreading logging using
> log4j 1.x 2.17.2 bridge.
> For reference, few methods which were synchronized earlier in log4j1.x but
> not anymore in log4j1.x bridge.
> # public void addAppender(final Appender appender)
> # public Appender getAppender(final String name)
> # public void removeAppender(final Appender appender)
> # public void removeAllAppenders()
> # In log4j 1.x bridge following method is used for logging which doesn't
> look like synchronized. -> void maybeLog(final String fqcn, final
> org.apache.logging.log4j.Level level, final Object message, final Throwable
> throwable); However in log4j1.x following method was used which looks like
> synchronized. -> void forcedLog(String fqcn, Priority level, Object message,
> Throwable t) -> void callAppenders(LoggingEvent event), where method void
> callAppenders(LoggingEvent event) looks snychronized.
>
> I am attaching sample test program as well which I have used to test
> multithreading logging in my application. (Please Note that in this test
> program, class CustomLogger is a dummy class, which you would need to replace
> with your logger). We are using Custom Rolling Appender in our application
> and following is the content of log4j properties file.
> [^JavaLoggingMultiThTest.txt]
> #Custom Rolling Appender
> log4j.appender.R=test.CustomMultiProcessRollingAppender
> log4j.appender.R.File=${user.home}/log4j-multithreading-test.log
> log4j.appender.R.RollOverOnStartup=true
> log4j.appender.R.RollOverOnSize=false
> log4j.appender.R.RollOverMaxFileSize=100MB
> log4j.appender.R.RollOverMaxBackupIndex=10
> log4j.appender.R.RollOverOnPeriodic=false
> log4j.appender.R.RollOverPeriodicStartDate=
> log4j.appender.R.RollOverPeriodicFrequency=1
> log4j.appender.R.layout=org.apache.log4j.PatternLayout
> log4j.appender.R.layout.ConversionPattern=%d %-8M [%t] - %m%n
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3447) Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing huge data in multithreading)
[
https://issues.apache.org/jira/browse/LOG4J2-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512684#comment-17512684
]
ASF subversion and git services commented on LOG4J2-3447:
-
Commit 211f33bbea680d2505e8c6c84c354979a218c637 in logging-log4j2's branch
refs/heads/release-2.x from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=211f33b ]
[LOG4J2-3447] Fixes native Log4j1 appenders concurrency problems
> Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing
> huge data in multithreading)
> --
>
> Key: LOG4J2-3447
> URL: https://issues.apache.org/jira/browse/LOG4J2-3447
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
> Attachments: JavaLoggingMultiThTest.txt
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With Log4j1.x there was no issue with multithreading but with log4j 1.x
> bridge we have noticed that in multithreading environment there is a huge
> data loss while logging, however single thread works fine. I see that in
> Category.java which Logger extends; many methods are not synchronized any
> more in log4j1.x bridge however which were synchronized in case of log4j1.x.
> I suspect this could be root causes of this multithreading problem.
> So as per my understanding synchronized class Category.java in the log4j1.x
> has become unsynchronized in log4j1.x 2.17.2 bridge. I am not sure if I am
> missing something.
> We wanted to know how to achieve successful multithreading logging using
> log4j 1.x 2.17.2 bridge.
> For reference, few methods which were synchronized earlier in log4j1.x but
> not anymore in log4j1.x bridge.
> # public void addAppender(final Appender appender)
> # public Appender getAppender(final String name)
> # public void removeAppender(final Appender appender)
> # public void removeAllAppenders()
> # In log4j 1.x bridge following method is used for logging which doesn't
> look like synchronized. -> void maybeLog(final String fqcn, final
> org.apache.logging.log4j.Level level, final Object message, final Throwable
> throwable); However in log4j1.x following method was used which looks like
> synchronized. -> void forcedLog(String fqcn, Priority level, Object message,
> Throwable t) -> void callAppenders(LoggingEvent event), where method void
> callAppenders(LoggingEvent event) looks snychronized.
>
> I am attaching sample test program as well which I have used to test
> multithreading logging in my application. (Please Note that in this test
> program, class CustomLogger is a dummy class, which you would need to replace
> with your logger). We are using Custom Rolling Appender in our application
> and following is the content of log4j properties file.
> [^JavaLoggingMultiThTest.txt]
> #Custom Rolling Appender
> log4j.appender.R=test.CustomMultiProcessRollingAppender
> log4j.appender.R.File=${user.home}/log4j-multithreading-test.log
> log4j.appender.R.RollOverOnStartup=true
> log4j.appender.R.RollOverOnSize=false
> log4j.appender.R.RollOverMaxFileSize=100MB
> log4j.appender.R.RollOverMaxBackupIndex=10
> log4j.appender.R.RollOverOnPeriodic=false
> log4j.appender.R.RollOverPeriodicStartDate=
> log4j.appender.R.RollOverPeriodicFrequency=1
> log4j.appender.R.layout=org.apache.log4j.PatternLayout
> log4j.appender.R.layout.ConversionPattern=%d %-8M [%t] - %m%n
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [logging-log4j2] jvz commented on a change in pull request #808: Make ConfigurationFactory injectable
jvz commented on a change in pull request #808:
URL: https://github.com/apache/logging-log4j2/pull/808#discussion_r835695608
##
File path:
log4j-core/src/main/java/org/apache/logging/log4j/core/config/ConfigurationFactory.java
##
@@ -137,71 +119,15 @@ public ConfigurationFactory() {
*/
private static final String CLASS_PATH_SCHEME = "classpath";
-private static final String OVERRIDE_PARAM = "override";
-
-private static volatile List factories;
-
-private static volatile ConfigurationFactory configFactory;
-
-protected final StrSubstitutor substitutor = new
ConfigurationStrSubstitutor(new Interpolator());
-
-private static final Lock LOCK = new ReentrantLock();
-
-private static final String HTTPS = "https";
-private static final String HTTP = "http";
-
private static final String[] PREFIXES = {"log4j2.",
"log4j2.Configuration."};
-private static volatile AuthorizationProvider authorizationProvider;
-
-/**
- * Returns the ConfigurationFactory.
- * @return the ConfigurationFactory.
- */
+@Deprecated(since = "3.0.0", forRemoval = true)
Review comment:
Being invoked by some Spring Boot class even though our override doesn't
invoke it. Not sure what's going on, but it's also causing a test failure for
me.
--
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
[GitHub] [logging-log4j2] jvz opened a new pull request #808: Make ConfigurationFactory injectable
jvz opened a new pull request #808: URL: https://github.com/apache/logging-log4j2/pull/808 This allows for a ConfigurationFactory binding to be registered as well as generally participate in dependency injection. Signed-off-by: Matt Sicker -- 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] [Created] (LOG4J2-3448) Add nullability-related annotations for better documentation and static analysis
Matt Sicker created LOG4J2-3448:
---
Summary: Add nullability-related annotations for better
documentation and static analysis
Key: LOG4J2-3448
URL: https://issues.apache.org/jira/browse/LOG4J2-3448
Project: Log4j 2
Issue Type: Improvement
Components: API
Reporter: Matt Sicker
Nullability annotations can be used by static analysis tools, IDEs, and even
Kotlin, to better check for potential NullPointerException errors or redundant
null checks. To avoid introducing an additional dependency here, these
annotations can be defined in the API. At minimum, some form of {{@Nonnull}}
and {{@Nullable}} should be added.
Alternatively, as these are compile-time annotations anyways, it may be
possible to use a third-party annotation library here as long as it's also
compile-time only.
--
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=17512587#comment-17512587
]
Matt Sicker edited comment on LOG4J2-2795 at 3/25/22, 9:15 PM:
---
Try invoking your benchmark program with
{{-Xlog:class+init=debug:file=class.log}} and attach the results here. Based on
my own log file, I identified those above issues so far, though there could be
more.
was (Author: jvz):
Try invoking your benchmark program with {{-Xlog:class=debug:file=class.log}}
and attach the results here. Based on my own log file, I identified those above
issues so far, though there could be more.
> 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=17512587#comment-17512587
]
Matt Sicker commented on LOG4J2-2795:
-
Try invoking your benchmark program with {{-Xlog:class=debug:file=class.log}}
and attach the results here. Based on my own log file, I identified those above
issues so far, though there could be more.
> 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=17512568#comment-17512568
]
Romain Manni-Bucau commented on LOG4J2-2795:
Yes it is there on ubuntu.
> 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)
[GitHub] [logging-log4j2] dfa1 commented on pull request #770: Initial support for detached markers in SLF4J binding
dfa1 commented on pull request #770:
URL: https://github.com/apache/logging-log4j2/pull/770#issuecomment-1079376882
@rgoers tried also your last suggestion too:
> You are free to use ServiceLoader to locate the SLF4J Service Provider and
get the Marker factory and then create Markers to your hearts content."
but unfortunately it is sensitive to classpath order since SLF4J is picking
up the first provider:
```java
List providersList = findServiceProviders();
reportMultipleBindingAmbiguity(providersList);
if (providersList != null && !providersList.isEmpty()) {
PROVIDER = providersList.get(0); <-- only the first one is considered
// SLF4JServiceProvider.initialize() is intended to be called here and
nowhere else.
PROVIDER.initialize();
```
so far, my workaround is to provide my JAR with my custom layout
implementation *before* any other jar in the classpath (this is done for about
20 Dockerfiles, it feels really dirty).
--
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=17512547#comment-17512547
]
Matt Sicker commented on LOG4J2-2795:
-
On the OS you're testing this on, do you have your hostname defined in
/etc/hosts? As described on [https://logging.apache.org/log4j/2.x/build.html]
there's a fun little feature in Java which uses a reverse DNS lookup to figure
out the local hostname if it's not already pre-loaded from the hosts file.
> Make LogManager/LoggerContext creation time reasonable
> --
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
>Affects Versions: 2.13.0
>Reporter: Romain Manni-Bucau
>Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3440) Log4j 1.2 bridge getAllAppenders() returns null enumeration
[ https://issues.apache.org/jira/browse/LOG4J2-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512505#comment-17512505 ] Pablo Rogina commented on LOG4J2-3440: -- [~rgoers] thank you for the heads up. I should have clarified that the code snippet is run at a level/library where the topmost application already configured Log4j > Log4j 1.2 bridge getAllAppenders() returns null enumeration > --- > > Key: LOG4J2-3440 > URL: https://issues.apache.org/jira/browse/LOG4J2-3440 > Project: Log4j 2 > Issue Type: Bug > Components: Log4j 1.2 bridge >Affects Versions: 2.17.2 >Reporter: Pablo Rogina >Assignee: Piotr Karwasz >Priority: Major > Fix For: 2.17.3 > > > Old application using Log4j 1.2.x relies on Logger.getAllAppenders() to > decide if Log4j it's already configured (returned Enumeration has at least 1 > appender) or not (empty returned Enumeration). > Some recent code audits mandate to remove log4j v1 component(s) and to > upgrade to latest 2.17.2 release, so we're using Log4j 1.2 Bridge to comply > and not to change application code. > However, we're facing the issue describe here [1] for > Logger.getRootLogger().getAllAppenders() although with latest Log4j release > 2.17.2 the issue seems to be that data structure aai is never updated with > the proper configured appenders, given that now most of the work happens in > the Log4j v2 Core implementation, thus using LoggerContext > [1] [java - Log4j getAllAppenders() returns null enumeration - Stack > Overflow|https://stackoverflow.com/questions/32864929/log4j-getallappenders-returns-null-enumeration] > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3440) Log4j 1.2 bridge getAllAppenders() returns null enumeration
[ https://issues.apache.org/jira/browse/LOG4J2-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512502#comment-17512502 ] Ralph Goers edited comment on LOG4J2-3440 at 3/25/22, 5:43 PM: --- I'm not really sure how your test succeeds. When you reference LogManager it has a static block that will initialize Log4j. By default, it will configure the DefaultConfiguration, which has a root LoggerConfig at ERROR and a Console Appender. See [setDefault() in AbstractConfiguration|https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AbstractConfiguration.java#L723]. Log4j-spring-boot tests to see if Log4j has initialized by calling LogManagerStatus.isInitialized(). Unfortunately, that class is considered internal. The isInitialized doesn't need to be - we only want to protect the setter.I'll have to figure out how to split things so that can happen. was (Author: ralph.go...@dslextreme.com): I'm not really sure how your test succeeds. When you reference LogManager it has a static block that will initialize Log4j. By default, it will configure the DefaultConfiguration, which has a root LoggerConfig at ERROR and a Console Appender. See [setDefault() in AbstractConfiguration|https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AbstractConfiguration.java#L723]. > Log4j 1.2 bridge getAllAppenders() returns null enumeration > --- > > Key: LOG4J2-3440 > URL: https://issues.apache.org/jira/browse/LOG4J2-3440 > Project: Log4j 2 > Issue Type: Bug > Components: Log4j 1.2 bridge >Affects Versions: 2.17.2 >Reporter: Pablo Rogina >Assignee: Piotr Karwasz >Priority: Major > Fix For: 2.17.3 > > > Old application using Log4j 1.2.x relies on Logger.getAllAppenders() to > decide if Log4j it's already configured (returned Enumeration has at least 1 > appender) or not (empty returned Enumeration). > Some recent code audits mandate to remove log4j v1 component(s) and to > upgrade to latest 2.17.2 release, so we're using Log4j 1.2 Bridge to comply > and not to change application code. > However, we're facing the issue describe here [1] for > Logger.getRootLogger().getAllAppenders() although with latest Log4j release > 2.17.2 the issue seems to be that data structure aai is never updated with > the proper configured appenders, given that now most of the work happens in > the Log4j v2 Core implementation, thus using LoggerContext > [1] [java - Log4j getAllAppenders() returns null enumeration - Stack > Overflow|https://stackoverflow.com/questions/32864929/log4j-getallappenders-returns-null-enumeration] > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (LOG4J2-3440) Log4j 1.2 bridge getAllAppenders() returns null enumeration
[ https://issues.apache.org/jira/browse/LOG4J2-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512502#comment-17512502 ] Ralph Goers commented on LOG4J2-3440: - I'm not really sure how your test succeeds. When you reference LogManager it has a static block that will initialize Log4j. By default, it will configure the DefaultConfiguration, which has a root LoggerConfig at ERROR and a Console Appender. See [setDefault() in AbstractConfiguration|https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AbstractConfiguration.java#L723]. > Log4j 1.2 bridge getAllAppenders() returns null enumeration > --- > > Key: LOG4J2-3440 > URL: https://issues.apache.org/jira/browse/LOG4J2-3440 > Project: Log4j 2 > Issue Type: Bug > Components: Log4j 1.2 bridge >Affects Versions: 2.17.2 >Reporter: Pablo Rogina >Assignee: Piotr Karwasz >Priority: Major > Fix For: 2.17.3 > > > Old application using Log4j 1.2.x relies on Logger.getAllAppenders() to > decide if Log4j it's already configured (returned Enumeration has at least 1 > appender) or not (empty returned Enumeration). > Some recent code audits mandate to remove log4j v1 component(s) and to > upgrade to latest 2.17.2 release, so we're using Log4j 1.2 Bridge to comply > and not to change application code. > However, we're facing the issue describe here [1] for > Logger.getRootLogger().getAllAppenders() although with latest Log4j release > 2.17.2 the issue seems to be that data structure aai is never updated with > the proper configured appenders, given that now most of the work happens in > the Log4j v2 Core implementation, thus using LoggerContext > [1] [java - Log4j getAllAppenders() returns null enumeration - Stack > Overflow|https://stackoverflow.com/questions/32864929/log4j-getallappenders-returns-null-enumeration] > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3440) Log4j 1.2 bridge getAllAppenders() returns null enumeration
[
https://issues.apache.org/jira/browse/LOG4J2-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512467#comment-17512467
]
Pablo Rogina edited comment on LOG4J2-3440 at 3/25/22, 4:31 PM:
[~pkarwasz] > Returning all the appenders used by the associated Log4j2 logger
seems excessive
Should those be the only appenders within the whole framework?
[~ggregory] >the whole "aai" implementation feels wrong since this is now a
bridge rather than an implementation
Yes, I agree. The bridge should be like an interpreter between what's already
coded for 1.2.x API and the underlying 2.x API + implementation
So not to influence your final work, this is what I've done just as interim
solution for my issue (given the time constraints and deadlines to meet), so to
get the appenders of the root logger:
[pseudo-code]
{{if LOG4J_CORE_PRESENT }}{{{}}
{{ root = org.log4j.logging.LogManager.getRootLogger()}}
{{ ctx = root.getContext() }}
{{ config = ctx.getConfiguration()}}
{{ rootConfig = config.getRootLogger()}}
{{ appenders = rootConfig.getAppenders()}}
{{ }}}
I've tested with something like rootLogger=INFO (not specifying any appender)
and in such case rootConfig.getAppenders() returns an empty array (which is
expected for me).
was (Author: JIRAUSER286891):
[~pkarwasz] > Returning all the appenders used by the associated Log4j2 logger
seems excessive
Should those be the only appenders within the whole framework?
[~ggregory] >the whole "aai" implementation feels wrong since this is now a
bridge rather than an implementation
Yes, I agree. The bridge should be like an interpreter between what's already
coded for 1.2.x API and the underlying 2.x API + implementation
So not to influence your final work, this is what I've done just as interim
solution for my issue (given the time constraints and deadlines to meet), so to
get the appenders of the root logger:
[pseudo-code]
if LOG4J_CORE_PRESENT {
root = org.log4j.logging.LogManager.getRootLogger()
ctx = root.getContext()
config = ctx.getConfiguration()
rootConfig = config.getRootLogger()
appenders = rootConfig.getAppenders()
}
I've tested with something like rootLogger=INFO (not specifying any appender)
and in such case rootConfig.getAppenders() returns an empty array (which is
expected for me).
> Log4j 1.2 bridge getAllAppenders() returns null enumeration
> ---
>
> Key: LOG4J2-3440
> URL: https://issues.apache.org/jira/browse/LOG4J2-3440
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pablo Rogina
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
>
> Old application using Log4j 1.2.x relies on Logger.getAllAppenders() to
> decide if Log4j it's already configured (returned Enumeration has at least 1
> appender) or not (empty returned Enumeration).
> Some recent code audits mandate to remove log4j v1 component(s) and to
> upgrade to latest 2.17.2 release, so we're using Log4j 1.2 Bridge to comply
> and not to change application code.
> However, we're facing the issue describe here [1] for
> Logger.getRootLogger().getAllAppenders() although with latest Log4j release
> 2.17.2 the issue seems to be that data structure aai is never updated with
> the proper configured appenders, given that now most of the work happens in
> the Log4j v2 Core implementation, thus using LoggerContext
> [1] [java - Log4j getAllAppenders() returns null enumeration - Stack
> Overflow|https://stackoverflow.com/questions/32864929/log4j-getallappenders-returns-null-enumeration]
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3440) Log4j 1.2 bridge getAllAppenders() returns null enumeration
[
https://issues.apache.org/jira/browse/LOG4J2-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512467#comment-17512467
]
Pablo Rogina commented on LOG4J2-3440:
--
[~pkarwasz] > Returning all the appenders used by the associated Log4j2 logger
seems excessive
Should those be the only appenders within the whole framework?
[~ggregory] >the whole "aai" implementation feels wrong since this is now a
bridge rather than an implementation
Yes, I agree. The bridge should be like an interpreter between what's already
coded for 1.2.x API and the underlying 2.x API + implementation
So not to influence your final work, this is what I've done just as interim
solution for my issue (given the time constraints and deadlines to meet), so to
get the appenders of the root logger:
[pseudo-code]
if LOG4J_CORE_PRESENT {
root = org.log4j.logging.LogManager.getRootLogger()
ctx = root.getContext()
config = ctx.getConfiguration()
rootConfig = config.getRootLogger()
appenders = rootConfig.getAppenders()
}
I've tested with something like rootLogger=INFO (not specifying any appender)
and in such case rootConfig.getAppenders() returns an empty array (which is
expected for me).
> Log4j 1.2 bridge getAllAppenders() returns null enumeration
> ---
>
> Key: LOG4J2-3440
> URL: https://issues.apache.org/jira/browse/LOG4J2-3440
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pablo Rogina
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
>
> Old application using Log4j 1.2.x relies on Logger.getAllAppenders() to
> decide if Log4j it's already configured (returned Enumeration has at least 1
> appender) or not (empty returned Enumeration).
> Some recent code audits mandate to remove log4j v1 component(s) and to
> upgrade to latest 2.17.2 release, so we're using Log4j 1.2 Bridge to comply
> and not to change application code.
> However, we're facing the issue describe here [1] for
> Logger.getRootLogger().getAllAppenders() although with latest Log4j release
> 2.17.2 the issue seems to be that data structure aai is never updated with
> the proper configured appenders, given that now most of the work happens in
> the Log4j v2 Core implementation, thus using LoggerContext
> [1] [java - Log4j getAllAppenders() returns null enumeration - Stack
> Overflow|https://stackoverflow.com/questions/32864929/log4j-getallappenders-returns-null-enumeration]
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3447) Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing huge data in multithreading)
[
https://issues.apache.org/jira/browse/LOG4J2-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512451#comment-17512451
]
Pooja Pandey commented on LOG4J2-3447:
--
Thanks [~pkarwasz] for detailed explanation.
> Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing
> huge data in multithreading)
> --
>
> Key: LOG4J2-3447
> URL: https://issues.apache.org/jira/browse/LOG4J2-3447
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
> Attachments: JavaLoggingMultiThTest.txt
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With Log4j1.x there was no issue with multithreading but with log4j 1.x
> bridge we have noticed that in multithreading environment there is a huge
> data loss while logging, however single thread works fine. I see that in
> Category.java which Logger extends; many methods are not synchronized any
> more in log4j1.x bridge however which were synchronized in case of log4j1.x.
> I suspect this could be root causes of this multithreading problem.
> So as per my understanding synchronized class Category.java in the log4j1.x
> has become unsynchronized in log4j1.x 2.17.2 bridge. I am not sure if I am
> missing something.
> We wanted to know how to achieve successful multithreading logging using
> log4j 1.x 2.17.2 bridge.
> For reference, few methods which were synchronized earlier in log4j1.x but
> not anymore in log4j1.x bridge.
> # public void addAppender(final Appender appender)
> # public Appender getAppender(final String name)
> # public void removeAppender(final Appender appender)
> # public void removeAllAppenders()
> # In log4j 1.x bridge following method is used for logging which doesn't
> look like synchronized. -> void maybeLog(final String fqcn, final
> org.apache.logging.log4j.Level level, final Object message, final Throwable
> throwable); However in log4j1.x following method was used which looks like
> synchronized. -> void forcedLog(String fqcn, Priority level, Object message,
> Throwable t) -> void callAppenders(LoggingEvent event), where method void
> callAppenders(LoggingEvent event) looks snychronized.
>
> I am attaching sample test program as well which I have used to test
> multithreading logging in my application. (Please Note that in this test
> program, class CustomLogger is a dummy class, which you would need to replace
> with your logger). We are using Custom Rolling Appender in our application
> and following is the content of log4j properties file.
> [^JavaLoggingMultiThTest.txt]
> #Custom Rolling Appender
> log4j.appender.R=test.CustomMultiProcessRollingAppender
> log4j.appender.R.File=${user.home}/log4j-multithreading-test.log
> log4j.appender.R.RollOverOnStartup=true
> log4j.appender.R.RollOverOnSize=false
> log4j.appender.R.RollOverMaxFileSize=100MB
> log4j.appender.R.RollOverMaxBackupIndex=10
> log4j.appender.R.RollOverOnPeriodic=false
> log4j.appender.R.RollOverPeriodicStartDate=
> log4j.appender.R.RollOverPeriodicFrequency=1
> log4j.appender.R.layout=org.apache.log4j.PatternLayout
> log4j.appender.R.layout.ConversionPattern=%d %-8M [%t] - %m%n
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] (LOG4J2-1204) log4j2 routing file appender appending the entries of current day log in previous log file
[ https://issues.apache.org/jira/browse/LOG4J2-1204 ]
Michael Parish deleted comment on LOG4J2-1204:
was (Author: JIRAUSER287120):
Why is this ticket unassigned and unresolved?
> log4j2 routing file appender appending the entries of current day log in
> previous log file
> --
>
> Key: LOG4J2-1204
> URL: https://issues.apache.org/jira/browse/LOG4J2-1204
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.4.1
> Environment: Windows 7 Enterprise , Core i5 vPro, 4Gb RAM
>Reporter: Rajakrishnan
>Priority: Major
> Labels: newbie, patch
>
> This is my scenario: For my website I have used log4j2 for rolling log files.
> currently I am generating 3 log file which consist of 2 rolling file (trace &
> error) and 1 routing appender.
> 1) Trace log of entire date (rolling file appender)
> 2) Error log of entire date (rolling file appender)
> 3) logged users activity log for entire day (routing file appender)
> Below is my log4j2.xml using for the above scenario, which works exactly as
> per the requirement.
> {code:xml}
>
>
>
>
>
> pattern="[%-5level] [%d{-MM-dd HH:mm:ss.SSS}]
> [%logger{1}] - %msg%n" />
>
> fileName="D:/client/error [${date:-MM-dd}].log"
> filePattern="D:/lient/error-%d{-MM-dd}.log">
> pattern="[%-5level] [%d{-MM-dd HH:mm:ss.SSS}]
> [%logger{1}] - %msg%n" />
>
>
>
>
>
> fileName="D:/client/trace [${date:-MM-dd}].log"
> filePattern="D:/client/trace-%d{-MM-dd}.log">
> pattern="[%-5level] [%d{-MM-dd HH:mm:ss.SSS}]
> [%logger{1}] - %msg%n" />
>
>
>
>
>
>
>
>
> append="true"
>
> fileName="D:/userlog/${ctx:logFileName}~${date:-MM-dd}.log"
>
> filePattern="D:/userlog/${date:-MM}/%d{-MM-dd}-%i.log.gz">
> pattern="[%-5level] [%d{-MM-dd HH:mm:ss.SSS}]
> [%logger{1}] - %msg%n" />
>
> modulate="true" />
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I am new to log4j2, I somehow managed to configure the log4j xml from the
> sources in internet. Rolling file were created for every day and file
> append-er created for each user and catches the respective events in the
> respective files for the entire day, .
> Issue is :
> When date changes, events of current day were added in the previous day log
> file.
> For example the trace.log file of 1st November has the log events entries of
> 2nd November.
> This happens for file append-er too .
> For example file append-er will generate log file based on user log's in say
> log file named john-01-112015.log was created yesterday. and same user log's
> in 2nd November a new file should be rolled out as per the configuration. but
> the logs of 2nd November is added in the john-01-112015.log as said in the
> previous scenario.
> new log file should be triggerd everyday, but it fails and logs were appended
> in the existing log of the logged user.
> When the tomcat is stop started then the new file genereted, but the issue
> exist until the next stop start. we can't do stop start in production env..
> Guys in stackoverflow suggested to raise a ticket ,since it might be a
> possible bug.
> Is there anything wrong in the log4j2.xml ? guys help me to solve this issue.
> Guide me if i did anything wrong
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-1204) log4j2 routing file appender appending the entries of current day log in previous log file
[
https://issues.apache.org/jira/browse/LOG4J2-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512364#comment-17512364
]
Michael Parish commented on LOG4J2-1204:
This issue is affecting my application as well.
> log4j2 routing file appender appending the entries of current day log in
> previous log file
> --
>
> Key: LOG4J2-1204
> URL: https://issues.apache.org/jira/browse/LOG4J2-1204
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.4.1
> Environment: Windows 7 Enterprise , Core i5 vPro, 4Gb RAM
>Reporter: Rajakrishnan
>Priority: Major
> Labels: newbie, patch
>
> This is my scenario: For my website I have used log4j2 for rolling log files.
> currently I am generating 3 log file which consist of 2 rolling file (trace &
> error) and 1 routing appender.
> 1) Trace log of entire date (rolling file appender)
> 2) Error log of entire date (rolling file appender)
> 3) logged users activity log for entire day (routing file appender)
> Below is my log4j2.xml using for the above scenario, which works exactly as
> per the requirement.
> {code:xml}
>
>
>
>
>
> pattern="[%-5level] [%d{-MM-dd HH:mm:ss.SSS}]
> [%logger{1}] - %msg%n" />
>
> fileName="D:/client/error [${date:-MM-dd}].log"
> filePattern="D:/lient/error-%d{-MM-dd}.log">
> pattern="[%-5level] [%d{-MM-dd HH:mm:ss.SSS}]
> [%logger{1}] - %msg%n" />
>
>
>
>
>
> fileName="D:/client/trace [${date:-MM-dd}].log"
> filePattern="D:/client/trace-%d{-MM-dd}.log">
> pattern="[%-5level] [%d{-MM-dd HH:mm:ss.SSS}]
> [%logger{1}] - %msg%n" />
>
>
>
>
>
>
>
>
> append="true"
>
> fileName="D:/userlog/${ctx:logFileName}~${date:-MM-dd}.log"
>
> filePattern="D:/userlog/${date:-MM}/%d{-MM-dd}-%i.log.gz">
> pattern="[%-5level] [%d{-MM-dd HH:mm:ss.SSS}]
> [%logger{1}] - %msg%n" />
>
> modulate="true" />
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I am new to log4j2, I somehow managed to configure the log4j xml from the
> sources in internet. Rolling file were created for every day and file
> append-er created for each user and catches the respective events in the
> respective files for the entire day, .
> Issue is :
> When date changes, events of current day were added in the previous day log
> file.
> For example the trace.log file of 1st November has the log events entries of
> 2nd November.
> This happens for file append-er too .
> For example file append-er will generate log file based on user log's in say
> log file named john-01-112015.log was created yesterday. and same user log's
> in 2nd November a new file should be rolled out as per the configuration. but
> the logs of 2nd November is added in the john-01-112015.log as said in the
> previous scenario.
> new log file should be triggerd everyday, but it fails and logs were appended
> in the existing log of the logged user.
> When the tomcat is stop started then the new file genereted, but the issue
> exist until the next stop start. we can't do stop start in production env..
> Guys in stackoverflow suggested to raise a ticket ,since it might be a
> possible bug.
> Is there anything wrong in the log4j2.xml ? guys help me to solve this issue.
> Guide me if i did anything wrong
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-1204) log4j2 routing file appender appending the entries of current day log in previous log file
[
https://issues.apache.org/jira/browse/LOG4J2-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512353#comment-17512353
]
Michael Parish commented on LOG4J2-1204:
Why is this ticket unassigned and unresolved?
> log4j2 routing file appender appending the entries of current day log in
> previous log file
> --
>
> Key: LOG4J2-1204
> URL: https://issues.apache.org/jira/browse/LOG4J2-1204
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.4.1
> Environment: Windows 7 Enterprise , Core i5 vPro, 4Gb RAM
>Reporter: Rajakrishnan
>Priority: Major
> Labels: newbie, patch
>
> This is my scenario: For my website I have used log4j2 for rolling log files.
> currently I am generating 3 log file which consist of 2 rolling file (trace &
> error) and 1 routing appender.
> 1) Trace log of entire date (rolling file appender)
> 2) Error log of entire date (rolling file appender)
> 3) logged users activity log for entire day (routing file appender)
> Below is my log4j2.xml using for the above scenario, which works exactly as
> per the requirement.
> {code:xml}
>
>
>
>
>
> pattern="[%-5level] [%d{-MM-dd HH:mm:ss.SSS}]
> [%logger{1}] - %msg%n" />
>
> fileName="D:/client/error [${date:-MM-dd}].log"
> filePattern="D:/lient/error-%d{-MM-dd}.log">
> pattern="[%-5level] [%d{-MM-dd HH:mm:ss.SSS}]
> [%logger{1}] - %msg%n" />
>
>
>
>
>
> fileName="D:/client/trace [${date:-MM-dd}].log"
> filePattern="D:/client/trace-%d{-MM-dd}.log">
> pattern="[%-5level] [%d{-MM-dd HH:mm:ss.SSS}]
> [%logger{1}] - %msg%n" />
>
>
>
>
>
>
>
>
> append="true"
>
> fileName="D:/userlog/${ctx:logFileName}~${date:-MM-dd}.log"
>
> filePattern="D:/userlog/${date:-MM}/%d{-MM-dd}-%i.log.gz">
> pattern="[%-5level] [%d{-MM-dd HH:mm:ss.SSS}]
> [%logger{1}] - %msg%n" />
>
> modulate="true" />
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I am new to log4j2, I somehow managed to configure the log4j xml from the
> sources in internet. Rolling file were created for every day and file
> append-er created for each user and catches the respective events in the
> respective files for the entire day, .
> Issue is :
> When date changes, events of current day were added in the previous day log
> file.
> For example the trace.log file of 1st November has the log events entries of
> 2nd November.
> This happens for file append-er too .
> For example file append-er will generate log file based on user log's in say
> log file named john-01-112015.log was created yesterday. and same user log's
> in 2nd November a new file should be rolled out as per the configuration. but
> the logs of 2nd November is added in the john-01-112015.log as said in the
> previous scenario.
> new log file should be triggerd everyday, but it fails and logs were appended
> in the existing log of the logged user.
> When the tomcat is stop started then the new file genereted, but the issue
> exist until the next stop start. we can't do stop start in production env..
> Guys in stackoverflow suggested to raise a ticket ,since it might be a
> possible bug.
> Is there anything wrong in the log4j2.xml ? guys help me to solve this issue.
> Guide me if i did anything wrong
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3436) Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname
[
https://issues.apache.org/jira/browse/LOG4J2-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512292#comment-17512292
]
Piotr Karwasz edited comment on LOG4J2-3436 at 3/25/22, 12:33 PM:
--
[~ragini],
If you read the issue
[LOG4J-3359|https://issues.apache.org/jira/browse/LOG4J2-3359] I linked before,
you'll find out that version 2.17.1 didn't work correctly: that is why all your
syslog messages have a facility of "USER" and level "Notice" (those must be the
default values your server assigns to invalid packets).
A solution to your problem is waiting for review as [PR
#807|https://github.com/apache/logging-log4j2/pull/807]. You can compile the
{{log4j-1.2-api}} module from that branch and check if it solves your problem.
Remark also that the "${hostName}" placeholder you used in 2.17.1 will no
longer work. Log4j 2.17.1 erroneously used Log4j2 variable interpolation
instead of Log4j 1.x variable interpolation. From version 2.17.2 onwards the
"${...}" placeholder will only resolve to system properties or properties in
your "log4j.properties" file. Since "hostName" is neither, it will evaluate to
the empty string.
was (Author: pkarwasz):
[~ragini],
If you read the issue
[LOG4J-3359|https://issues.apache.org/jira/browse/LOG4J2-3359] I linked before,
you'll find out that version 2.17.1 didn't work correctly: that is why all your
syslog messages have a facility of "USER" and level "Notice" (those must be the
default values your server assigns to invalid packets).
A solution to your problem is waiting for review as [PR
#807|https://github.com/apache/logging-log4j2/pull/807]. You can compile the
{{log4j-1.2-api}} module from that branch and check if it solves your problem.
Remark also that the "${hostName}" placeholder you used in 2.17.1 will no
longer work. Log4j 2.17.1 erroneously used Log4j2 variable interpolation
instead of Log4j 1.x variable interpolation. From 2.17.2 the "${...}" will only
resolve to system properties or properties in your "log4j.properties" file.
> Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname
> --
>
> Key: LOG4J2-3436
> URL: https://issues.apache.org/jira/browse/LOG4J2-3436
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Log4j 1.2 bridge
> Environment: Using log4j 2 bridge API: snapshot version of 2.17.3
> log4j-1.2-api-2.17.3.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
>
> We are trying to use syslogAppender for our logging but in the logs its
> prints localhost.localdomain instead of actual hostname
> <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1
> com.test.common.logging.Test | FINE#com.test.common.logging.Level - Can
> print FINE
> <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1
> com.test.common.logging.Test | INFO#com.test.common.logging.Level - Can
> print Info
>
> Here we are using snapshot version of log4j 2.17.3
> This issue was not seen when using log4j 2.17.1
>
> Additional info:
> JDK 1.8
> -Dlog4j1.compatibility=true
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3447) Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing huge data in multithreading)
[
https://issues.apache.org/jira/browse/LOG4J2-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512347#comment-17512347
]
Piotr Karwasz commented on LOG4J2-3447:
---
There is no issue with the "standard" Log4j 1.x appenders.
For example: if you use {{"org.apache.log4j.RollingFileAppender"}} in your
configuration, the Log4j bridge will not actually use that class, but it will
create a wrapped
{{{}"org.apache.logging.log4j.core.appender.RollingFileAppender"{}}}.
*Remark:* by using custom Log4j 1.x appenders, you are missing most of Log4j2
advantages. For example, if you were to replace your "log4j.properties" file
with a Log4j2 configuration file, you could all the options provided by
[RollingFileAppender|https://logging.apache.org/log4j/2.x/manual/appenders.html#RollingFileAppender].
If you use a native Log4j2 configuration file, you can still use your Log4j 1.x
loggers, but you'll probably get an improved performance, when compared with
your custom appender.
> Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing
> huge data in multithreading)
> --
>
> Key: LOG4J2-3447
> URL: https://issues.apache.org/jira/browse/LOG4J2-3447
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
> Attachments: JavaLoggingMultiThTest.txt
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With Log4j1.x there was no issue with multithreading but with log4j 1.x
> bridge we have noticed that in multithreading environment there is a huge
> data loss while logging, however single thread works fine. I see that in
> Category.java which Logger extends; many methods are not synchronized any
> more in log4j1.x bridge however which were synchronized in case of log4j1.x.
> I suspect this could be root causes of this multithreading problem.
> So as per my understanding synchronized class Category.java in the log4j1.x
> has become unsynchronized in log4j1.x 2.17.2 bridge. I am not sure if I am
> missing something.
> We wanted to know how to achieve successful multithreading logging using
> log4j 1.x 2.17.2 bridge.
> For reference, few methods which were synchronized earlier in log4j1.x but
> not anymore in log4j1.x bridge.
> # public void addAppender(final Appender appender)
> # public Appender getAppender(final String name)
> # public void removeAppender(final Appender appender)
> # public void removeAllAppenders()
> # In log4j 1.x bridge following method is used for logging which doesn't
> look like synchronized. -> void maybeLog(final String fqcn, final
> org.apache.logging.log4j.Level level, final Object message, final Throwable
> throwable); However in log4j1.x following method was used which looks like
> synchronized. -> void forcedLog(String fqcn, Priority level, Object message,
> Throwable t) -> void callAppenders(LoggingEvent event), where method void
> callAppenders(LoggingEvent event) looks snychronized.
>
> I am attaching sample test program as well which I have used to test
> multithreading logging in my application. (Please Note that in this test
> program, class CustomLogger is a dummy class, which you would need to replace
> with your logger). We are using Custom Rolling Appender in our application
> and following is the content of log4j properties file.
> [^JavaLoggingMultiThTest.txt]
> #Custom Rolling Appender
> log4j.appender.R=test.CustomMultiProcessRollingAppender
> log4j.appender.R.File=${user.home}/log4j-multithreading-test.log
> log4j.appender.R.RollOverOnStartup=true
> log4j.appender.R.RollOverOnSize=false
> log4j.appender.R.RollOverMaxFileSize=100MB
> log4j.appender.R.RollOverMaxBackupIndex=10
> log4j.appender.R.RollOverOnPeriodic=false
> log4j.appender.R.RollOverPeriodicStartDate=
> log4j.appender.R.RollOverPeriodicFrequency=1
> log4j.appender.R.layout=org.apache.log4j.PatternLayout
> log4j.appender.R.layout.ConversionPattern=%d %-8M [%t] - %m%n
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3447) Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing huge data in multithreading)
[
https://issues.apache.org/jira/browse/LOG4J2-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512317#comment-17512317
]
Pooja Pandey commented on LOG4J2-3447:
--
Hi [~pkarwasz],
--> However, we *did* miss the case of users, like you, that use custom Log4j
1.x loggers. It will be fixed in the next release. In the mean time you can
work around the problem by adding synchronization to the {{append}} method of
your custom appender.
How would we fix the issue when a application is using custom logger but not
the custom appender because in that case since we don't have any custom
appender for which we can override append method with synchronized keyword.
> Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing
> huge data in multithreading)
> --
>
> Key: LOG4J2-3447
> URL: https://issues.apache.org/jira/browse/LOG4J2-3447
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
> Attachments: JavaLoggingMultiThTest.txt
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With Log4j1.x there was no issue with multithreading but with log4j 1.x
> bridge we have noticed that in multithreading environment there is a huge
> data loss while logging, however single thread works fine. I see that in
> Category.java which Logger extends; many methods are not synchronized any
> more in log4j1.x bridge however which were synchronized in case of log4j1.x.
> I suspect this could be root causes of this multithreading problem.
> So as per my understanding synchronized class Category.java in the log4j1.x
> has become unsynchronized in log4j1.x 2.17.2 bridge. I am not sure if I am
> missing something.
> We wanted to know how to achieve successful multithreading logging using
> log4j 1.x 2.17.2 bridge.
> For reference, few methods which were synchronized earlier in log4j1.x but
> not anymore in log4j1.x bridge.
> # public void addAppender(final Appender appender)
> # public Appender getAppender(final String name)
> # public void removeAppender(final Appender appender)
> # public void removeAllAppenders()
> # In log4j 1.x bridge following method is used for logging which doesn't
> look like synchronized. -> void maybeLog(final String fqcn, final
> org.apache.logging.log4j.Level level, final Object message, final Throwable
> throwable); However in log4j1.x following method was used which looks like
> synchronized. -> void forcedLog(String fqcn, Priority level, Object message,
> Throwable t) -> void callAppenders(LoggingEvent event), where method void
> callAppenders(LoggingEvent event) looks snychronized.
>
> I am attaching sample test program as well which I have used to test
> multithreading logging in my application. (Please Note that in this test
> program, class CustomLogger is a dummy class, which you would need to replace
> with your logger). We are using Custom Rolling Appender in our application
> and following is the content of log4j properties file.
> [^JavaLoggingMultiThTest.txt]
> #Custom Rolling Appender
> log4j.appender.R=test.CustomMultiProcessRollingAppender
> log4j.appender.R.File=${user.home}/log4j-multithreading-test.log
> log4j.appender.R.RollOverOnStartup=true
> log4j.appender.R.RollOverOnSize=false
> log4j.appender.R.RollOverMaxFileSize=100MB
> log4j.appender.R.RollOverMaxBackupIndex=10
> log4j.appender.R.RollOverOnPeriodic=false
> log4j.appender.R.RollOverPeriodicStartDate=
> log4j.appender.R.RollOverPeriodicFrequency=1
> log4j.appender.R.layout=org.apache.log4j.PatternLayout
> log4j.appender.R.layout.ConversionPattern=%d %-8M [%t] - %m%n
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3436) Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname
[
https://issues.apache.org/jira/browse/LOG4J2-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512292#comment-17512292
]
Piotr Karwasz commented on LOG4J2-3436:
---
[~ragini],
If you read the issue
[LOG4J-3359|https://issues.apache.org/jira/browse/LOG4J2-3359] I linked before,
you'll find out that version 2.17.1 didn't work correctly: that is why all your
syslog messages have a facility of "USER" and level "Notice" (those must be the
default values your server assigns to invalid packets).
A solution to your problem is waiting for review as [PR
#807|https://github.com/apache/logging-log4j2/pull/807]. You can compile the
{{log4j-1.2-api}} module from that branch and check if it solves your problem.
Remark also that the "${hostName}" placeholder you used in 2.17.1 will no
longer work. Log4j 2.17.1 erroneously used Log4j2 variable interpolation
instead of Log4j 1.x variable interpolation. From 2.17.2 the "${...}" will only
resolve to system properties or properties in your "log4j.properties" file.
> Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname
> --
>
> Key: LOG4J2-3436
> URL: https://issues.apache.org/jira/browse/LOG4J2-3436
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Log4j 1.2 bridge
> Environment: Using log4j 2 bridge API: snapshot version of 2.17.3
> log4j-1.2-api-2.17.3.jar
>Reporter: Ragini Gawande
>Assignee: Piotr Karwasz
>Priority: Blocker
>
> We are trying to use syslogAppender for our logging but in the logs its
> prints localhost.localdomain instead of actual hostname
> <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1
> com.test.common.logging.Test | FINE#com.test.common.logging.Level - Can
> print FINE
> <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1
> com.test.common.logging.Test | INFO#com.test.common.logging.Level - Can
> print Info
>
> Here we are using snapshot version of log4j 2.17.3
> This issue was not seen when using log4j 2.17.1
>
> Additional info:
> JDK 1.8
> -Dlog4j1.compatibility=true
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3447) Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing huge data in multithreading)
[
https://issues.apache.org/jira/browse/LOG4J2-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512269#comment-17512269
]
Pooja Pandey edited comment on LOG4J2-3447 at 3/25/22, 9:17 AM:
Hi [~pkarwasz] ,
--> In the mean time you can work around the problem by adding synchronization
to the {{append}} method of your custom appender.
Above suggestion worked.
Thank you so much :) :) :) :) :) :)
Thanks a lot [~pkarwasz] :) :)
was (Author: JIRAUSER285751):
Hi [~pkarwasz] ,
--> In the mean time you can work around the problem by adding synchronization
to the {{append}} method of your custom appender.
Above suggestion worked.
Thank you so so much :) :) :) :) :) :)
Thanks a lot [~pkarwasz] :) :)
> Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing
> huge data in multithreading)
> --
>
> Key: LOG4J2-3447
> URL: https://issues.apache.org/jira/browse/LOG4J2-3447
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
> Attachments: JavaLoggingMultiThTest.txt
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With Log4j1.x there was no issue with multithreading but with log4j 1.x
> bridge we have noticed that in multithreading environment there is a huge
> data loss while logging, however single thread works fine. I see that in
> Category.java which Logger extends; many methods are not synchronized any
> more in log4j1.x bridge however which were synchronized in case of log4j1.x.
> I suspect this could be root causes of this multithreading problem.
> So as per my understanding synchronized class Category.java in the log4j1.x
> has become unsynchronized in log4j1.x 2.17.2 bridge. I am not sure if I am
> missing something.
> We wanted to know how to achieve successful multithreading logging using
> log4j 1.x 2.17.2 bridge.
> For reference, few methods which were synchronized earlier in log4j1.x but
> not anymore in log4j1.x bridge.
> # public void addAppender(final Appender appender)
> # public Appender getAppender(final String name)
> # public void removeAppender(final Appender appender)
> # public void removeAllAppenders()
> # In log4j 1.x bridge following method is used for logging which doesn't
> look like synchronized. -> void maybeLog(final String fqcn, final
> org.apache.logging.log4j.Level level, final Object message, final Throwable
> throwable); However in log4j1.x following method was used which looks like
> synchronized. -> void forcedLog(String fqcn, Priority level, Object message,
> Throwable t) -> void callAppenders(LoggingEvent event), where method void
> callAppenders(LoggingEvent event) looks snychronized.
>
> I am attaching sample test program as well which I have used to test
> multithreading logging in my application. (Please Note that in this test
> program, class CustomLogger is a dummy class, which you would need to replace
> with your logger). We are using Custom Rolling Appender in our application
> and following is the content of log4j properties file.
> [^JavaLoggingMultiThTest.txt]
> #Custom Rolling Appender
> log4j.appender.R=test.CustomMultiProcessRollingAppender
> log4j.appender.R.File=${user.home}/log4j-multithreading-test.log
> log4j.appender.R.RollOverOnStartup=true
> log4j.appender.R.RollOverOnSize=false
> log4j.appender.R.RollOverMaxFileSize=100MB
> log4j.appender.R.RollOverMaxBackupIndex=10
> log4j.appender.R.RollOverOnPeriodic=false
> log4j.appender.R.RollOverPeriodicStartDate=
> log4j.appender.R.RollOverPeriodicFrequency=1
> log4j.appender.R.layout=org.apache.log4j.PatternLayout
> log4j.appender.R.layout.ConversionPattern=%d %-8M [%t] - %m%n
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3447) Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing huge data in multithreading)
[
https://issues.apache.org/jira/browse/LOG4J2-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512269#comment-17512269
]
Pooja Pandey commented on LOG4J2-3447:
--
Hi [~pkarwasz] ,
--> In the mean time you can work around the problem by adding synchronization
to the {{append}} method of your custom appender.
Above suggestion worked.
Thank you so so much :) :) :) :) :) :)
Thanks a lot [~pkarwasz] :) :)
> Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing
> huge data in multithreading)
> --
>
> Key: LOG4J2-3447
> URL: https://issues.apache.org/jira/browse/LOG4J2-3447
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
> Attachments: JavaLoggingMultiThTest.txt
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With Log4j1.x there was no issue with multithreading but with log4j 1.x
> bridge we have noticed that in multithreading environment there is a huge
> data loss while logging, however single thread works fine. I see that in
> Category.java which Logger extends; many methods are not synchronized any
> more in log4j1.x bridge however which were synchronized in case of log4j1.x.
> I suspect this could be root causes of this multithreading problem.
> So as per my understanding synchronized class Category.java in the log4j1.x
> has become unsynchronized in log4j1.x 2.17.2 bridge. I am not sure if I am
> missing something.
> We wanted to know how to achieve successful multithreading logging using
> log4j 1.x 2.17.2 bridge.
> For reference, few methods which were synchronized earlier in log4j1.x but
> not anymore in log4j1.x bridge.
> # public void addAppender(final Appender appender)
> # public Appender getAppender(final String name)
> # public void removeAppender(final Appender appender)
> # public void removeAllAppenders()
> # In log4j 1.x bridge following method is used for logging which doesn't
> look like synchronized. -> void maybeLog(final String fqcn, final
> org.apache.logging.log4j.Level level, final Object message, final Throwable
> throwable); However in log4j1.x following method was used which looks like
> synchronized. -> void forcedLog(String fqcn, Priority level, Object message,
> Throwable t) -> void callAppenders(LoggingEvent event), where method void
> callAppenders(LoggingEvent event) looks snychronized.
>
> I am attaching sample test program as well which I have used to test
> multithreading logging in my application. (Please Note that in this test
> program, class CustomLogger is a dummy class, which you would need to replace
> with your logger). We are using Custom Rolling Appender in our application
> and following is the content of log4j properties file.
> [^JavaLoggingMultiThTest.txt]
> #Custom Rolling Appender
> log4j.appender.R=test.CustomMultiProcessRollingAppender
> log4j.appender.R.File=${user.home}/log4j-multithreading-test.log
> log4j.appender.R.RollOverOnStartup=true
> log4j.appender.R.RollOverOnSize=false
> log4j.appender.R.RollOverMaxFileSize=100MB
> log4j.appender.R.RollOverMaxBackupIndex=10
> log4j.appender.R.RollOverOnPeriodic=false
> log4j.appender.R.RollOverPeriodicStartDate=
> log4j.appender.R.RollOverPeriodicFrequency=1
> log4j.appender.R.layout=org.apache.log4j.PatternLayout
> log4j.appender.R.layout.ConversionPattern=%d %-8M [%t] - %m%n
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] (LOG4J2-3447) Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing huge data in multithreading)
[ https://issues.apache.org/jira/browse/LOG4J2-3447 ]
Pooja Pandey deleted comment on LOG4J2-3447:
--
was (Author: JIRAUSER285751):
Hello [~pkarwasz],
Adding synchronization to appender methods could NOT fix the issue instead just
adding synchronized to below method fixing the issue.
class CustomLogger extends Logger {
protected CustomLogger(String name)
{ super(name); }
{color:#ff}synchronized {color}public static void LogError(String s,
Object o)
{ CustomLogger myLogger = getMyLogger(); // If logging not
enabled for specified type, return without logging the message. if (
!myLogger.isErrorEnabled() ) return;
myLogger.error("LogMessage"); }
}
> Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing
> huge data in multithreading)
> --
>
> Key: LOG4J2-3447
> URL: https://issues.apache.org/jira/browse/LOG4J2-3447
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
> Attachments: JavaLoggingMultiThTest.txt
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With Log4j1.x there was no issue with multithreading but with log4j 1.x
> bridge we have noticed that in multithreading environment there is a huge
> data loss while logging, however single thread works fine. I see that in
> Category.java which Logger extends; many methods are not synchronized any
> more in log4j1.x bridge however which were synchronized in case of log4j1.x.
> I suspect this could be root causes of this multithreading problem.
> So as per my understanding synchronized class Category.java in the log4j1.x
> has become unsynchronized in log4j1.x 2.17.2 bridge. I am not sure if I am
> missing something.
> We wanted to know how to achieve successful multithreading logging using
> log4j 1.x 2.17.2 bridge.
> For reference, few methods which were synchronized earlier in log4j1.x but
> not anymore in log4j1.x bridge.
> # public void addAppender(final Appender appender)
> # public Appender getAppender(final String name)
> # public void removeAppender(final Appender appender)
> # public void removeAllAppenders()
> # In log4j 1.x bridge following method is used for logging which doesn't
> look like synchronized. -> void maybeLog(final String fqcn, final
> org.apache.logging.log4j.Level level, final Object message, final Throwable
> throwable); However in log4j1.x following method was used which looks like
> synchronized. -> void forcedLog(String fqcn, Priority level, Object message,
> Throwable t) -> void callAppenders(LoggingEvent event), where method void
> callAppenders(LoggingEvent event) looks snychronized.
>
> I am attaching sample test program as well which I have used to test
> multithreading logging in my application. (Please Note that in this test
> program, class CustomLogger is a dummy class, which you would need to replace
> with your logger). We are using Custom Rolling Appender in our application
> and following is the content of log4j properties file.
> [^JavaLoggingMultiThTest.txt]
> #Custom Rolling Appender
> log4j.appender.R=test.CustomMultiProcessRollingAppender
> log4j.appender.R.File=${user.home}/log4j-multithreading-test.log
> log4j.appender.R.RollOverOnStartup=true
> log4j.appender.R.RollOverOnSize=false
> log4j.appender.R.RollOverMaxFileSize=100MB
> log4j.appender.R.RollOverMaxBackupIndex=10
> log4j.appender.R.RollOverOnPeriodic=false
> log4j.appender.R.RollOverPeriodicStartDate=
> log4j.appender.R.RollOverPeriodicFrequency=1
> log4j.appender.R.layout=org.apache.log4j.PatternLayout
> log4j.appender.R.layout.ConversionPattern=%d %-8M [%t] - %m%n
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3436) Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname
[ https://issues.apache.org/jira/browse/LOG4J2-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512265#comment-17512265 ] Ragini Gawande commented on LOG4J2-3436: [~pkarwasz] Any plan to get this fixed in the next log4j version to get the behavior same as 2.17.1? or any other way if you can suggest(any configuration which we can do on our side) to get this issue fixed > Log4j 2 syslogAppender prints localhost.localdomain instead of actual hostname > -- > > Key: LOG4J2-3436 > URL: https://issues.apache.org/jira/browse/LOG4J2-3436 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders, Log4j 1.2 bridge > Environment: Using log4j 2 bridge API: snapshot version of 2.17.3 > log4j-1.2-api-2.17.3.jar >Reporter: Ragini Gawande >Assignee: Piotr Karwasz >Priority: Blocker > > We are trying to use syslogAppender for our logging but in the logs its > prints localhost.localdomain instead of actual hostname > <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1 > com.test.common.logging.Test | FINE#com.test.common.logging.Level - Can > print FINE > <13>Mar 14 22:33:41 *localhost.localdomain* Main[6133] +05:30 2022 572 1 > com.test.common.logging.Test | INFO#com.test.common.logging.Level - Can > print Info > > Here we are using snapshot version of log4j 2.17.3 > This issue was not seen when using log4j 2.17.1 > > Additional info: > JDK 1.8 > -Dlog4j1.compatibility=true -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (LOG4J2-3447) Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing huge data in multithreading)
[
https://issues.apache.org/jira/browse/LOG4J2-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512253#comment-17512253
]
Pooja Pandey edited comment on LOG4J2-3447 at 3/25/22, 8:31 AM:
Hello [~pkarwasz],
Adding synchronization to appender methods could NOT fix the issue instead just
adding synchronized to below method fixing the issue.
class CustomLogger extends Logger {
protected CustomLogger(String name)
{ super(name); }
{color:#ff}synchronized {color}public static void LogError(String s,
Object o)
{ CustomLogger myLogger = getMyLogger(); // If logging not
enabled for specified type, return without logging the message. if (
!myLogger.isErrorEnabled() ) return;
myLogger.error("LogMessage"); }
}
was (Author: JIRAUSER285751):
Hello [~pkarwasz],
Adding synchronization to appender methods could NOT fix the issue instead just
adding synchronized to below method fixing the issue.
class CustomLogger extends Logger {
protected CustomLogger(String name) {
super(name);
}
{color:#FF}synchronized {color}public static void LogError(String s,
Object o) {
CustomLogger myLogger = getMyLogger();
// If logging not enabled for specified type, return without logging the
message.
if ( !myLogger.isErrorEnabled() )
return;
myLogger.error("LogMessage");
}
}
> Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing
> huge data in multithreading)
> --
>
> Key: LOG4J2-3447
> URL: https://issues.apache.org/jira/browse/LOG4J2-3447
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
> Attachments: JavaLoggingMultiThTest.txt
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With Log4j1.x there was no issue with multithreading but with log4j 1.x
> bridge we have noticed that in multithreading environment there is a huge
> data loss while logging, however single thread works fine. I see that in
> Category.java which Logger extends; many methods are not synchronized any
> more in log4j1.x bridge however which were synchronized in case of log4j1.x.
> I suspect this could be root causes of this multithreading problem.
> So as per my understanding synchronized class Category.java in the log4j1.x
> has become unsynchronized in log4j1.x 2.17.2 bridge. I am not sure if I am
> missing something.
> We wanted to know how to achieve successful multithreading logging using
> log4j 1.x 2.17.2 bridge.
> For reference, few methods which were synchronized earlier in log4j1.x but
> not anymore in log4j1.x bridge.
> # public void addAppender(final Appender appender)
> # public Appender getAppender(final String name)
> # public void removeAppender(final Appender appender)
> # public void removeAllAppenders()
> # In log4j 1.x bridge following method is used for logging which doesn't
> look like synchronized. -> void maybeLog(final String fqcn, final
> org.apache.logging.log4j.Level level, final Object message, final Throwable
> throwable); However in log4j1.x following method was used which looks like
> synchronized. -> void forcedLog(String fqcn, Priority level, Object message,
> Throwable t) -> void callAppenders(LoggingEvent event), where method void
> callAppenders(LoggingEvent event) looks snychronized.
>
> I am attaching sample test program as well which I have used to test
> multithreading logging in my application. (Please Note that in this test
> program, class CustomLogger is a dummy class, which you would need to replace
> with your logger). We are using Custom Rolling Appender in our application
> and following is the content of log4j properties file.
> [^JavaLoggingMultiThTest.txt]
> #Custom Rolling Appender
> log4j.appender.R=test.CustomMultiProcessRollingAppender
> log4j.appender.R.File=${user.home}/log4j-multithreading-test.log
> log4j.appender.R.RollOverOnStartup=true
> log4j.appender.R.RollOverOnSize=false
> log4j.appender.R.RollOverMaxFileSize=100MB
> log4j.appender.R.RollOverMaxBackupIndex=10
> log4j.appender.R.RollOverOnPeriodic=false
> log4j.appender.R.RollOverPeriodicStartDate=
> log4j.appender.R.RollOverPeriodicFrequency=1
> log4j.appender.R.layout=org.apache.log4j.PatternLayout
> log4j.appender.R.layout.ConversionPattern=%d %-8M [%t] - %m%n
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3447) Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing huge data in multithreading)
[
https://issues.apache.org/jira/browse/LOG4J2-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512253#comment-17512253
]
Pooja Pandey commented on LOG4J2-3447:
--
Hello [~pkarwasz],
Adding synchronization to appender methods could NOT fix the issue instead just
adding synchronized to below method fixing the issue.
class CustomLogger extends Logger {
protected CustomLogger(String name) {
super(name);
}
{color:#FF}synchronized {color}public static void LogError(String s,
Object o) {
CustomLogger myLogger = getMyLogger();
// If logging not enabled for specified type, return without logging the
message.
if ( !myLogger.isErrorEnabled() )
return;
myLogger.error("LogMessage");
}
}
> Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing
> huge data in multithreading)
> --
>
> Key: LOG4J2-3447
> URL: https://issues.apache.org/jira/browse/LOG4J2-3447
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
> Attachments: JavaLoggingMultiThTest.txt
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With Log4j1.x there was no issue with multithreading but with log4j 1.x
> bridge we have noticed that in multithreading environment there is a huge
> data loss while logging, however single thread works fine. I see that in
> Category.java which Logger extends; many methods are not synchronized any
> more in log4j1.x bridge however which were synchronized in case of log4j1.x.
> I suspect this could be root causes of this multithreading problem.
> So as per my understanding synchronized class Category.java in the log4j1.x
> has become unsynchronized in log4j1.x 2.17.2 bridge. I am not sure if I am
> missing something.
> We wanted to know how to achieve successful multithreading logging using
> log4j 1.x 2.17.2 bridge.
> For reference, few methods which were synchronized earlier in log4j1.x but
> not anymore in log4j1.x bridge.
> # public void addAppender(final Appender appender)
> # public Appender getAppender(final String name)
> # public void removeAppender(final Appender appender)
> # public void removeAllAppenders()
> # In log4j 1.x bridge following method is used for logging which doesn't
> look like synchronized. -> void maybeLog(final String fqcn, final
> org.apache.logging.log4j.Level level, final Object message, final Throwable
> throwable); However in log4j1.x following method was used which looks like
> synchronized. -> void forcedLog(String fqcn, Priority level, Object message,
> Throwable t) -> void callAppenders(LoggingEvent event), where method void
> callAppenders(LoggingEvent event) looks snychronized.
>
> I am attaching sample test program as well which I have used to test
> multithreading logging in my application. (Please Note that in this test
> program, class CustomLogger is a dummy class, which you would need to replace
> with your logger). We are using Custom Rolling Appender in our application
> and following is the content of log4j properties file.
> [^JavaLoggingMultiThTest.txt]
> #Custom Rolling Appender
> log4j.appender.R=test.CustomMultiProcessRollingAppender
> log4j.appender.R.File=${user.home}/log4j-multithreading-test.log
> log4j.appender.R.RollOverOnStartup=true
> log4j.appender.R.RollOverOnSize=false
> log4j.appender.R.RollOverMaxFileSize=100MB
> log4j.appender.R.RollOverMaxBackupIndex=10
> log4j.appender.R.RollOverOnPeriodic=false
> log4j.appender.R.RollOverPeriodicStartDate=
> log4j.appender.R.RollOverPeriodicFrequency=1
> log4j.appender.R.layout=org.apache.log4j.PatternLayout
> log4j.appender.R.layout.ConversionPattern=%d %-8M [%t] - %m%n
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (LOG4J2-3447) Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing huge data in multithreading)
[
https://issues.apache.org/jira/browse/LOG4J2-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512247#comment-17512247
]
Piotr Karwasz commented on LOG4J2-3447:
---
Hello [~PoojaTheCoder],
Thanks for bringing this to our attention. The Log4j 1.x bridge classes don't
contain any synchronized methods, because either they are no-ops or
synchronization is performed in native Log4j2 components.
However, we *did* miss the case of users, like you, that use custom Log4j 1.x
loggers. It will be fixed in the next release. In the mean time you can work
around the problem by adding synchronization to the {{append}} method of your
custom appender.
For the methods you cite check LOG4J2-3440: right now they are almost no-ops
(they add and remove appenders that are ignored by the logging system). I'll
take your remark into account, when working on that issue.
> Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing
> huge data in multithreading)
> --
>
> Key: LOG4J2-3447
> URL: https://issues.apache.org/jira/browse/LOG4J2-3447
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
> Attachments: JavaLoggingMultiThTest.txt
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With Log4j1.x there was no issue with multithreading but with log4j 1.x
> bridge we have noticed that in multithreading environment there is a huge
> data loss while logging, however single thread works fine. I see that in
> Category.java which Logger extends; many methods are not synchronized any
> more in log4j1.x bridge however which were synchronized in case of log4j1.x.
> I suspect this could be root causes of this multithreading problem.
> So as per my understanding synchronized class Category.java in the log4j1.x
> has become unsynchronized in log4j1.x 2.17.2 bridge. I am not sure if I am
> missing something.
> We wanted to know how to achieve successful multithreading logging using
> log4j 1.x 2.17.2 bridge.
> For reference, few methods which were synchronized earlier in log4j1.x but
> not anymore in log4j1.x bridge.
> # public void addAppender(final Appender appender)
> # public Appender getAppender(final String name)
> # public void removeAppender(final Appender appender)
> # public void removeAllAppenders()
> # In log4j 1.x bridge following method is used for logging which doesn't
> look like synchronized. -> void maybeLog(final String fqcn, final
> org.apache.logging.log4j.Level level, final Object message, final Throwable
> throwable); However in log4j1.x following method was used which looks like
> synchronized. -> void forcedLog(String fqcn, Priority level, Object message,
> Throwable t) -> void callAppenders(LoggingEvent event), where method void
> callAppenders(LoggingEvent event) looks snychronized.
>
> I am attaching sample test program as well which I have used to test
> multithreading logging in my application. (Please Note that in this test
> program, class CustomLogger is a dummy class, which you would need to replace
> with your logger). We are using Custom Rolling Appender in our application
> and following is the content of log4j properties file.
> [^JavaLoggingMultiThTest.txt]
> #Custom Rolling Appender
> log4j.appender.R=test.CustomMultiProcessRollingAppender
> log4j.appender.R.File=${user.home}/log4j-multithreading-test.log
> log4j.appender.R.RollOverOnStartup=true
> log4j.appender.R.RollOverOnSize=false
> log4j.appender.R.RollOverMaxFileSize=100MB
> log4j.appender.R.RollOverMaxBackupIndex=10
> log4j.appender.R.RollOverOnPeriodic=false
> log4j.appender.R.RollOverPeriodicStartDate=
> log4j.appender.R.RollOverPeriodicFrequency=1
> log4j.appender.R.layout=org.apache.log4j.PatternLayout
> log4j.appender.R.layout.ConversionPattern=%d %-8M [%t] - %m%n
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3447) Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing huge data in multithreading)
[
https://issues.apache.org/jira/browse/LOG4J2-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Karwasz updated LOG4J2-3447:
--
Fix Version/s: 2.17.3
> Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing
> huge data in multithreading)
> --
>
> Key: LOG4J2-3447
> URL: https://issues.apache.org/jira/browse/LOG4J2-3447
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
> Attachments: JavaLoggingMultiThTest.txt
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With Log4j1.x there was no issue with multithreading but with log4j 1.x
> bridge we have noticed that in multithreading environment there is a huge
> data loss while logging, however single thread works fine. I see that in
> Category.java which Logger extends; many methods are not synchronized any
> more in log4j1.x bridge however which were synchronized in case of log4j1.x.
> I suspect this could be root causes of this multithreading problem.
> So as per my understanding synchronized class Category.java in the log4j1.x
> has become unsynchronized in log4j1.x 2.17.2 bridge. I am not sure if I am
> missing something.
> We wanted to know how to achieve successful multithreading logging using
> log4j 1.x 2.17.2 bridge.
> For reference, few methods which were synchronized earlier in log4j1.x but
> not anymore in log4j1.x bridge.
> # public void addAppender(final Appender appender)
> # public Appender getAppender(final String name)
> # public void removeAppender(final Appender appender)
> # public void removeAllAppenders()
> # In log4j 1.x bridge following method is used for logging which doesn't
> look like synchronized. -> void maybeLog(final String fqcn, final
> org.apache.logging.log4j.Level level, final Object message, final Throwable
> throwable); However in log4j1.x following method was used which looks like
> synchronized. -> void forcedLog(String fqcn, Priority level, Object message,
> Throwable t) -> void callAppenders(LoggingEvent event), where method void
> callAppenders(LoggingEvent event) looks snychronized.
>
> I am attaching sample test program as well which I have used to test
> multithreading logging in my application. (Please Note that in this test
> program, class CustomLogger is a dummy class, which you would need to replace
> with your logger). We are using Custom Rolling Appender in our application
> and following is the content of log4j properties file.
> [^JavaLoggingMultiThTest.txt]
> #Custom Rolling Appender
> log4j.appender.R=test.CustomMultiProcessRollingAppender
> log4j.appender.R.File=${user.home}/log4j-multithreading-test.log
> log4j.appender.R.RollOverOnStartup=true
> log4j.appender.R.RollOverOnSize=false
> log4j.appender.R.RollOverMaxFileSize=100MB
> log4j.appender.R.RollOverMaxBackupIndex=10
> log4j.appender.R.RollOverOnPeriodic=false
> log4j.appender.R.RollOverPeriodicStartDate=
> log4j.appender.R.RollOverPeriodicFrequency=1
> log4j.appender.R.layout=org.apache.log4j.PatternLayout
> log4j.appender.R.layout.ConversionPattern=%d %-8M [%t] - %m%n
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (LOG4J2-3447) Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing huge data in multithreading)
[
https://issues.apache.org/jira/browse/LOG4J2-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Karwasz reassigned LOG4J2-3447:
-
Assignee: Piotr Karwasz
> Log4j 1.x 2.17.2 bridge - Synchronization issue in multithreading (Losing
> huge data in multithreading)
> --
>
> Key: LOG4J2-3447
> URL: https://issues.apache.org/jira/browse/LOG4J2-3447
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j 1.2 bridge
>Affects Versions: 2.17.2
>Reporter: Pooja Pandey
>Assignee: Piotr Karwasz
>Priority: Major
> Attachments: JavaLoggingMultiThTest.txt
>
>
> In our application we have migrated from log4j1.x to log4j1.x 2.17.2 bridge.
> With Log4j1.x there was no issue with multithreading but with log4j 1.x
> bridge we have noticed that in multithreading environment there is a huge
> data loss while logging, however single thread works fine. I see that in
> Category.java which Logger extends; many methods are not synchronized any
> more in log4j1.x bridge however which were synchronized in case of log4j1.x.
> I suspect this could be root causes of this multithreading problem.
> So as per my understanding synchronized class Category.java in the log4j1.x
> has become unsynchronized in log4j1.x 2.17.2 bridge. I am not sure if I am
> missing something.
> We wanted to know how to achieve successful multithreading logging using
> log4j 1.x 2.17.2 bridge.
> For reference, few methods which were synchronized earlier in log4j1.x but
> not anymore in log4j1.x bridge.
> # public void addAppender(final Appender appender)
> # public Appender getAppender(final String name)
> # public void removeAppender(final Appender appender)
> # public void removeAllAppenders()
> # In log4j 1.x bridge following method is used for logging which doesn't
> look like synchronized. -> void maybeLog(final String fqcn, final
> org.apache.logging.log4j.Level level, final Object message, final Throwable
> throwable); However in log4j1.x following method was used which looks like
> synchronized. -> void forcedLog(String fqcn, Priority level, Object message,
> Throwable t) -> void callAppenders(LoggingEvent event), where method void
> callAppenders(LoggingEvent event) looks snychronized.
>
> I am attaching sample test program as well which I have used to test
> multithreading logging in my application. (Please Note that in this test
> program, class CustomLogger is a dummy class, which you would need to replace
> with your logger). We are using Custom Rolling Appender in our application
> and following is the content of log4j properties file.
> [^JavaLoggingMultiThTest.txt]
> #Custom Rolling Appender
> log4j.appender.R=test.CustomMultiProcessRollingAppender
> log4j.appender.R.File=${user.home}/log4j-multithreading-test.log
> log4j.appender.R.RollOverOnStartup=true
> log4j.appender.R.RollOverOnSize=false
> log4j.appender.R.RollOverMaxFileSize=100MB
> log4j.appender.R.RollOverMaxBackupIndex=10
> log4j.appender.R.RollOverOnPeriodic=false
> log4j.appender.R.RollOverPeriodicStartDate=
> log4j.appender.R.RollOverPeriodicFrequency=1
> log4j.appender.R.layout=org.apache.log4j.PatternLayout
> log4j.appender.R.layout.ConversionPattern=%d %-8M [%t] - %m%n
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3427) ServiceLoader usage in a servlet environment
[
https://issues.apache.org/jira/browse/LOG4J2-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Karwasz updated LOG4J2-3427:
--
Fix Version/s: 2.17.3
> ServiceLoader usage in a servlet environment
>
>
> Key: LOG4J2-3427
> URL: https://issues.apache.org/jira/browse/LOG4J2-3427
> Project: Log4j 2
> Issue Type: Improvement
>Reporter: Piotr Karwasz
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
>
> It is fair to assume that a servlet container like Tomcat might contain
> multiple copies of Log4j 2.x:
> * a copy of Log4j 2.x can be used as logging provider for the entire server,
> * each web application can contain another copy of Log4j 2.x
> One of the shortcomings of {{ServiceLoader}} is that it detects services in
> both the web application's and server's classloader, but only those in the
> web application are usable: those in the server's classloader can not extend
> the service class contained in the application's classloader.
> A typical usage of {{ServiceLoader}} to find all instances of a certain
> service can therefore end up in a {{{}ServiceConfigurationError{}}}. Those
> are caught in Log4j 2.x, but usually end up in all services (also the viable
> ones) being {*}discarded{*}.
> Hence a tool is necessary to only discard those services, which are contained
> in the server's classloader.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3440) Log4j 1.2 bridge getAllAppenders() returns null enumeration
[ https://issues.apache.org/jira/browse/LOG4J2-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Karwasz updated LOG4J2-3440: -- Fix Version/s: 2.17.3 > Log4j 1.2 bridge getAllAppenders() returns null enumeration > --- > > Key: LOG4J2-3440 > URL: https://issues.apache.org/jira/browse/LOG4J2-3440 > Project: Log4j 2 > Issue Type: Bug > Components: Log4j 1.2 bridge >Affects Versions: 2.17.2 >Reporter: Pablo Rogina >Assignee: Piotr Karwasz >Priority: Major > Fix For: 2.17.3 > > > Old application using Log4j 1.2.x relies on Logger.getAllAppenders() to > decide if Log4j it's already configured (returned Enumeration has at least 1 > appender) or not (empty returned Enumeration). > Some recent code audits mandate to remove log4j v1 component(s) and to > upgrade to latest 2.17.2 release, so we're using Log4j 1.2 Bridge to comply > and not to change application code. > However, we're facing the issue describe here [1] for > Logger.getRootLogger().getAllAppenders() although with latest Log4j release > 2.17.2 the issue seems to be that data structure aai is never updated with > the proper configured appenders, given that now most of the work happens in > the Log4j v2 Core implementation, thus using LoggerContext > [1] [java - Log4j getAllAppenders() returns null enumeration - Stack > Overflow|https://stackoverflow.com/questions/32864929/log4j-getallappenders-returns-null-enumeration] > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (LOG4J2-3362) Jakarta EE 9 compatible SMTP appender
[
https://issues.apache.org/jira/browse/LOG4J2-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Karwasz updated LOG4J2-3362:
--
Fix Version/s: 2.17.3
> Jakarta EE 9 compatible SMTP appender
> -
>
> Key: LOG4J2-3362
> URL: https://issues.apache.org/jira/browse/LOG4J2-3362
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
>Affects Versions: 2.17.1
>Reporter: Andy Wilkinson
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
>
> This is a follow-on from LOG4J-2978 which addressed Jakarta EE 9
> compatibility from a web perspective.
> {{SmtpAppender}} uses {{SmtpManager}} which depends upon various
> {{javax.activation}} and {{javax.mail}} classes from Jakarta EE 8. To allow
> Log4j 2 to be used in a Jakarta EE 9 environment, an {{SmtpManager}} that
> uses classes in the new {{jakarta.activation}} and {{jakarta.mail}} packages
> is required.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (LOG4J2-3418) Proper registration of Log4j2CloudConfigLoggingSystem
[
https://issues.apache.org/jira/browse/LOG4J2-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Karwasz closed LOG4J2-3418.
-
> Proper registration of Log4j2CloudConfigLoggingSystem
> -
>
> Key: LOG4J2-3418
> URL: https://issues.apache.org/jira/browse/LOG4J2-3418
> Project: Log4j 2
> Issue Type: Bug
> Components: Spring
>Affects Versions: 2.14.0
>Reporter: Piotr Karwasz
>Assignee: Piotr Karwasz
>Priority: Major
> Fix For: 2.17.3
>
>
> The current version of {{log4j-spring-boot}} sets Java's
> {{org.springframework.boot.logging.LoggingSystem}} property to force the
> usage of the {{Log4j2CloudConfigLoggingSystem}}.
> This can potentially break applications running in the same JVM, if they use
> different logging systems.
> The artifact should use the {{spring.factories}} detection mechanism instead.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (LOG4J2-3446) AGPBI: {"kind":"error","text":"MethodHandle.invoke and MethodHandle.invokeExact are only supported starting with Android O (--min-api 26)","sources":[{}],"tool":"D8"}
[
https://issues.apache.org/jira/browse/LOG4J2-3446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Karwasz updated LOG4J2-3446:
--
Fix Version/s: (was: 2.17.2)
> AGPBI: {"kind":"error","text":"MethodHandle.invoke and
> MethodHandle.invokeExact are only supported starting with Android O
> (--min-api 26)","sources":[{}],"tool":"D8"}
> --
>
> Key: LOG4J2-3446
> URL: https://issues.apache.org/jira/browse/LOG4J2-3446
> Project: Log4j 2
> Issue Type: Bug
> Components: Build
>Affects Versions: 2.17.2
>Reporter: leiyao
>Priority: Critical
> Attachments: 微信图片_20220324111842.png
>
>
> Adding org.apache.logging.log4j:log4j-core:2.17.2 to an Android project ，but
> when I install app on device by androidstudio, the error come
> out.(MethodHandle.invoke and MethodHandle.invokeExact are only supported
> starting with Android O (--min-api 26)
> ). Could you help me?
> com.android.builder.dexing.DexArchiveBuilderException:
> com.android.builder.dexing.DexArchiveBuilderException: Failed to process
> C:\Users\leiyao7\.gradle\caches\modules-2\files-2.1\org.apache.logging.log4j\log4j-core\2.17.2\fa43ba4467f5300b16d1e0742934149bfc5ac564\log4j-core-2.17.2.jar
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:593)
> at
> java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677)
> at java.util.concurrent.ForkJoinTask.join(ForkJoinTask.java:720)
> at
> com.android.ide.common.internal.WaitableExecutor.waitForTasksWithQuickFail(WaitableExecutor.java:149)
> at
> com.android.build.gradle.internal.transforms.DexArchiveBuilderTransform.transform(DexArchiveBuilderTransform.java:420)
> at
> com.android.build.gradle.internal.pipeline.TransformTask$2.call(TransformTask.java:239)
> at
> com.android.build.gradle.internal.pipeline.TransformTask$2.call(TransformTask.java:235)
> at
> com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:102)
> at
> com.android.build.gradle.internal.pipeline.TransformTask.transform(TransformTask.java:230)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)
> at
> org.gradle.api.internal.project.taskfactory.IncrementalTaskInputsTaskAction.doExecute(IncrementalTaskInputsTaskAction.java:47)
> at
> org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:42)
> at
> org.gradle.api.internal.project.taskfactory.AbstractIncrementalTaskAction.execute(AbstractIncrementalTaskAction.java:25)
> at
> org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:28)
> at
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$3.run(ExecuteActionsTaskExecuter.java:568)
> at
> org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:402)
> at
> org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:394)
> at
> org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:165)
> at
> org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:250)
> at
> org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:158)
> at
> org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:92)
> at
> org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
> at
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:553)
> at
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:536)
> at
> org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExec
