[jira] [Commented] (LOG4NET-589) Impossible to use ProcessExit event for logging needs
[ https://issues.apache.org/jira/browse/LOG4NET-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16353447#comment-16353447 ] Aleksandr Serbin commented on LOG4NET-589: -- It might be possible to use "static finalizer" for dynamic shutdown. [Here|https://dotnet.currifex.org/dotnet/articles/sharedfinalizer/] is the article that describe this pattern. In this case, we still have the same interface as before. > Impossible to use ProcessExit event for logging needs > - > > Key: LOG4NET-589 > URL: https://issues.apache.org/jira/browse/LOG4NET-589 > Project: Log4net > Issue Type: Improvement > Components: Core >Reporter: Aleksandr Serbin >Priority: Minor > Attachments: log4net_nonworking.cs, log4net_working.cs > > > LoggerManager use ProcessExit event to run shutdown on each > repository/loggers. If the user wants to use these events (ProcessExit or > DomainUnload) also to log own data, he will meet the problem, since > LoggerManager will shutdown all loggers first (log4net_nonworking.cs). > There is a workaround when you can initialize logger in main method (showed > in log4net_working.cs), but then all code loses readability. > > * It would be great if LoggerManager won't use ProcessExit and DomainUnload > to shutdown loggers, since this event might be used in user application for > own needs. > * If you can not refuse these events, then it would be good to have a public > method to reregister those events. User will add own delegates first and then > reregister LoggerManager events. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LOG4J2-2241) log4j-slf4j-impl does not provide slf4j with the service provider with Java 9
[
https://issues.apache.org/jira/browse/LOG4J2-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16353340#comment-16353340
]
Ralph Goers commented on LOG4J2-2241:
-
It may be a good thing esthetically that I don't have to create classes in the
slf4j namespace any more, but it is never a good thing to make it difficult to
provide backward compatibility.
> log4j-slf4j-impl does not provide slf4j with the service provider with Java 9
> -
>
> Key: LOG4J2-2241
> URL: https://issues.apache.org/jira/browse/LOG4J2-2241
> Project: Log4j 2
> Issue Type: Bug
> Components: SLF4J Bridge
>Affects Versions: 2.10.0
>Reporter: Joshua Popoff
>Priority: Blocker
>
> log4j-slf4j-impl does not
> {noformat}
> provides org.slf4j.spi.SLF4JServiceProvider with
> org.apache.logging.slf4j.SLF4JServiceProvider;{noformat}
> (due to no module-info.java, and only an automatic module name, in the
> log4j-slf4j-impl project.
> When ran:
> {noformat}
> SLF4J: No SLF4J providers were found.
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#noProviders for further details.
> SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions prior
> to 1.8.
> SLF4J: Ignoring binding found at
> [jar:file://[redacted]/log4j-slf4j-impl-2.10.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#ignoredBindings for an explanation.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2241) log4j-slf4j-impl does not provide slf4j with the service provider with Java 9
[
https://issues.apache.org/jira/browse/LOG4J2-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16353339#comment-16353339
]
Joshua Popoff commented on LOG4J2-2241:
---
Yes, that is true – but it is also a good thing, due to how packages and
modules are on Java 9.
> log4j-slf4j-impl does not provide slf4j with the service provider with Java 9
> -
>
> Key: LOG4J2-2241
> URL: https://issues.apache.org/jira/browse/LOG4J2-2241
> Project: Log4j 2
> Issue Type: Bug
> Components: SLF4J Bridge
>Affects Versions: 2.10.0
>Reporter: Joshua Popoff
>Priority: Blocker
>
> log4j-slf4j-impl does not
> {noformat}
> provides org.slf4j.spi.SLF4JServiceProvider with
> org.apache.logging.slf4j.SLF4JServiceProvider;{noformat}
> (due to no module-info.java, and only an automatic module name, in the
> log4j-slf4j-impl project.
> When ran:
> {noformat}
> SLF4J: No SLF4J providers were found.
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#noProviders for further details.
> SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions prior
> to 1.8.
> SLF4J: Ignoring binding found at
> [jar:file://[redacted]/log4j-slf4j-impl-2.10.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#ignoredBindings for an explanation.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2241) log4j-slf4j-impl does not provide slf4j with the service provider with Java 9
[
https://issues.apache.org/jira/browse/LOG4J2-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16353335#comment-16353335
]
Ralph Goers commented on LOG4J2-2241:
-
We really don't have much choice since SLF4J changed the binding contract and
implementations are no longer compatible with older versions of SLF4J, which is
a real problem for a framework like Log4j that tries to be as compatible with
as much as possible.
> log4j-slf4j-impl does not provide slf4j with the service provider with Java 9
> -
>
> Key: LOG4J2-2241
> URL: https://issues.apache.org/jira/browse/LOG4J2-2241
> Project: Log4j 2
> Issue Type: Bug
> Components: SLF4J Bridge
>Affects Versions: 2.10.0
>Reporter: Joshua Popoff
>Priority: Blocker
>
> log4j-slf4j-impl does not
> {noformat}
> provides org.slf4j.spi.SLF4JServiceProvider with
> org.apache.logging.slf4j.SLF4JServiceProvider;{noformat}
> (due to no module-info.java, and only an automatic module name, in the
> log4j-slf4j-impl project.
> When ran:
> {noformat}
> SLF4J: No SLF4J providers were found.
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#noProviders for further details.
> SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions prior
> to 1.8.
> SLF4J: Ignoring binding found at
> [jar:file://[redacted]/log4j-slf4j-impl-2.10.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#ignoredBindings for an explanation.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2241) log4j-slf4j-impl does not provide slf4j with the service provider with Java 9
[
https://issues.apache.org/jira/browse/LOG4J2-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16353332#comment-16353332
]
Joshua Popoff commented on LOG4J2-2241:
---
Yes, this is running with Java 9. A module-info that contains a "provides"
would also be necessary for it to work as intended, as far as I can see.
I'm find with a second JAR just for Java 9, though it is a bit on the hacky
side.
> log4j-slf4j-impl does not provide slf4j with the service provider with Java 9
> -
>
> Key: LOG4J2-2241
> URL: https://issues.apache.org/jira/browse/LOG4J2-2241
> Project: Log4j 2
> Issue Type: Bug
> Components: SLF4J Bridge
>Affects Versions: 2.10.0
>Reporter: Joshua Popoff
>Priority: Blocker
>
> log4j-slf4j-impl does not
> {noformat}
> provides org.slf4j.spi.SLF4JServiceProvider with
> org.apache.logging.slf4j.SLF4JServiceProvider;{noformat}
> (due to no module-info.java, and only an automatic module name, in the
> log4j-slf4j-impl project.
> When ran:
> {noformat}
> SLF4J: No SLF4J providers were found.
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#noProviders for further details.
> SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions prior
> to 1.8.
> SLF4J: Ignoring binding found at
> [jar:file://[redacted]/log4j-slf4j-impl-2.10.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#ignoredBindings for an explanation.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2241) log4j-slf4j-impl does not provide slf4j with the service provider with Java 9
[
https://issues.apache.org/jira/browse/LOG4J2-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16353328#comment-16353328
]
Ralph Goers commented on LOG4J2-2241:
-
This is when running in Java 9? Unfortunately log4j-slf4j-impl supports prior
versions of SLF4J so still has the org.slf4j package in it, which it cannot do
to become a true Java 9 module. The only solution I can think of would be to
create a second jar just for Java 9 that excludes those bindings.
> log4j-slf4j-impl does not provide slf4j with the service provider with Java 9
> -
>
> Key: LOG4J2-2241
> URL: https://issues.apache.org/jira/browse/LOG4J2-2241
> Project: Log4j 2
> Issue Type: Bug
> Components: SLF4J Bridge
>Affects Versions: 2.10.0
>Reporter: Joshua Popoff
>Priority: Blocker
>
> log4j-slf4j-impl does not
> {noformat}
> provides org.slf4j.spi.SLF4JServiceProvider with
> org.apache.logging.slf4j.SLF4JServiceProvider;{noformat}
> (due to no module-info.java, and only an automatic module name, in the
> log4j-slf4j-impl project.
> When ran:
> {noformat}
> SLF4J: No SLF4J providers were found.
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#noProviders for further details.
> SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions prior
> to 1.8.
> SLF4J: Ignoring binding found at
> [jar:file://[redacted]/log4j-slf4j-impl-2.10.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#ignoredBindings for an explanation.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (LOG4J2-2241) log4j-slf4j-impl does not provide slf4j with the service provider with Java 9
Joshua Popoff created LOG4J2-2241:
-
Summary: log4j-slf4j-impl does not provide slf4j with the service
provider with Java 9
Key: LOG4J2-2241
URL: https://issues.apache.org/jira/browse/LOG4J2-2241
Project: Log4j 2
Issue Type: Bug
Components: SLF4J Bridge
Affects Versions: 2.10.0
Reporter: Joshua Popoff
log4j-slf4j-impl does not
{noformat}
provides org.slf4j.spi.SLF4JServiceProvider with
org.apache.logging.slf4j.SLF4JServiceProvider;{noformat}
(due to no module-info.java, and only an automatic module name, in the
log4j-slf4j-impl project.
When ran:
{noformat}
SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#noProviders for further details.
SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions prior to
1.8.
SLF4J: Ignoring binding found at
[jar:file://[redacted]/log4j-slf4j-impl-2.10.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#ignoredBindings for an explanation.
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (LOG4J2-2032) Curly braces in parameters are treated as placeholders
[
https://issues.apache.org/jira/browse/LOG4J2-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kostiantyn Shchepanovskyi updated LOG4J2-2032:
--
Affects Version/s: 2.10.0
> Curly braces in parameters are treated as placeholders
> --
>
> Key: LOG4J2-2032
> URL: https://issues.apache.org/jira/browse/LOG4J2-2032
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Layouts
>Affects Versions: 2.8.2, 2.9.0, 2.10.0
> Environment: Tested on Windows and Linux.
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Kostiantyn Shchepanovskyi
>Priority: Major
>
> When logging event parameter contains two consecutive opening and closing
> curly braces - {{for example {} in the middle of parameter}}, they are
> treated as a placeholder and are substituted by provided parameters starting
> from index zero.
> I suspect that it affects only async loggers.
> My configuration:
> {code:xml}
>
>
>
>
>
> %level{length=1} %date{MMdd-HHmm:ss,SSS} %logger{1.}
> %message %X [%thread]%n
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Test:
> {code:java}
> package com.playtech.live.platform.core.service;
> import org.junit.jupiter.api.Test;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> public class Log4jCurlyBracesInParameterTest {
> private static final Logger LOGGER =
> LoggerFactory.getLogger(Log4jCurlyBracesInParameterTest.class);
> @Test
> void messageWithCurlyBracesInParameter() {
> LOGGER.info("Text containing curly braces: {}", "Curly{}");
> LOGGER.info("Normal text: {}, text containing curly braces {}",
> "Normal", "Curly{}");
> }
> }
> {code}
> Expected output:
> {code}
> I 0905-1731:01,018 c.p.l.p.c.s.Log4jCurlyBracesInParameterTest Text
> containing curly braces: Curly{} {} [main]
> I 0905-1731:01,033 c.p.l.p.c.s.Log4jCurlyBracesInParameterTest Normal text:
> Normal, text containing curly braces Curly{} {} [main]
> {code}
> Actual output:
> {code}
> I 0905-1731:01,018 c.p.l.p.c.s.Log4jCurlyBracesInParameterTest Text
> containing curly braces: CurlyCurly{} {} [main]
> I 0905-1731:01,033 c.p.l.p.c.s.Log4jCurlyBracesInParameterTest Normal text:
> Normal, text containing curly braces CurlyNormal {} [main]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2032) Curly braces in parameters are treated as placeholders
[
https://issues.apache.org/jira/browse/LOG4J2-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16352751#comment-16352751
]
Kostiantyn Shchepanovskyi commented on LOG4J2-2032:
---
Looks like this issue has been introduced by
https://issues.apache.org/jira/browse/LOG4J2-1342.
{code:java}
@Override
public Message memento() {
if (message != null) {
return message;
}
final Object[] params = parameters == null ? new Object[0] :
Arrays.copyOf(parameters, parameterCount);
return new ParameterizedMessage(messageText.toString(), params);
}
{code}
Returning {{ParameterizedMessage(messageText.toString(), params)}} is wrong, as
{{messageText.toString()}} is already processed.
If we return new message with parameters and this text as format, resulting
string is invalid.
[~rem...@yahoo.com] - I would appreciate any hints how to fix this issue in
optimal way.
> Curly braces in parameters are treated as placeholders
> --
>
> Key: LOG4J2-2032
> URL: https://issues.apache.org/jira/browse/LOG4J2-2032
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Layouts
>Affects Versions: 2.8.2, 2.9.0
> Environment: Tested on Windows and Linux.
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Kostiantyn Shchepanovskyi
>Priority: Major
>
> When logging event parameter contains two consecutive opening and closing
> curly braces - {{for example {} in the middle of parameter}}, they are
> treated as a placeholder and are substituted by provided parameters starting
> from index zero.
> I suspect that it affects only async loggers.
> My configuration:
> {code:xml}
>
>
>
>
>
> %level{length=1} %date{MMdd-HHmm:ss,SSS} %logger{1.}
> %message %X [%thread]%n
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Test:
> {code:java}
> package com.playtech.live.platform.core.service;
> import org.junit.jupiter.api.Test;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
> public class Log4jCurlyBracesInParameterTest {
> private static final Logger LOGGER =
> LoggerFactory.getLogger(Log4jCurlyBracesInParameterTest.class);
> @Test
> void messageWithCurlyBracesInParameter() {
> LOGGER.info("Text containing curly braces: {}", "Curly{}");
> LOGGER.info("Normal text: {}, text containing curly braces {}",
> "Normal", "Curly{}");
> }
> }
> {code}
> Expected output:
> {code}
> I 0905-1731:01,018 c.p.l.p.c.s.Log4jCurlyBracesInParameterTest Text
> containing curly braces: Curly{} {} [main]
> I 0905-1731:01,033 c.p.l.p.c.s.Log4jCurlyBracesInParameterTest Normal text:
> Normal, text containing curly braces Curly{} {} [main]
> {code}
> Actual output:
> {code}
> I 0905-1731:01,018 c.p.l.p.c.s.Log4jCurlyBracesInParameterTest Text
> containing curly braces: CurlyCurly{} {} [main]
> I 0905-1731:01,033 c.p.l.p.c.s.Log4jCurlyBracesInParameterTest Normal text:
> Normal, text containing curly braces CurlyNormal {} [main]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (LOG4J2-2240) Is there a mechanism to reconfigure log4j2 in a predictable fashion?
Edward created LOG4J2-2240:
--
Summary: Is there a mechanism to reconfigure log4j2 in a
predictable fashion?
Key: LOG4J2-2240
URL: https://issues.apache.org/jira/browse/LOG4J2-2240
Project: Log4j 2
Issue Type: Improvement
Components: Core
Affects Versions: 2.10.0
Reporter: Edward
Hello, I'm re-posting from Stack Overflow following Remko Popma's
recommendation. This is simultaneously a question and a request for
improvement. If there is a trick I haven't discovered yet it can be used as a
workaround, however, the absence of a public API to the Configurator that would
support reconfiguration and allow (even if optionally) handling of abnormal
events appears to be a serious deficiency that could hopefully be addressed in
the near future. Thanks!
I'm looking for ways to configure/reconfigure log4j after it may, or may not
have been initialized. This should work running standalone or in a web
container.
The configuration may be represented by a configuration file at a particular
arbitrary URI. The knowledge of the URI comes from the application, not log4j
framework. The configuration may also be done programmatically (less
problematic but problematic still).
The public API is unfortunately sorely lacking so developers are forced to
write brittle code using implementation classes from log4j core. From weeks of
studying documentation and stepping through log4j code I see two ways to
accomplish reconfiguration:
Stopping the current context and re-initializing using
log4j.core.config.Configurator,
similar to the following:
{code:java}
((LoggerContext) LogManager.getContext(false)).stop();
Configurator.initialize(buildDefaultConfiguration()); //programmatically
building a configuration{code}
or
{code:java}
((LoggerContext) LogManager.getContext(false)).stop();
Configurator.initialize(null, ConfigurationSource.fromUri(loggingUri));
//passing the configuration source constructed from a known URI{code}
The first line in both examples will stop the current context if it has already
been created and started (when running in a web container for example). If
log4j has not been initialized (when running as a standalone app for example)
it will initialize log4j with the default configuration and start the context
first (as a side effect of calling getContext()), and then stop it.
If the current context is not stopped first the call to
Configurator.initialize() will have no effect. log4j will ignore your attempt
to re-initialize, will not give you any indication of it, and just simply
return the current context. This behavior is not mentioned in the "Reconfigure
Log4j Using ConfigurationBuilder with the Configurator" section of the Manual.
It simply says: "However, should any logging be attempted before
Configurator.initialize() is called then the default configuration will be used
for those log events." The default configuration will also be used for all
subsequent log events in the provided examples because calling
Configurator.initialize() will have no effect, unless the current context is
stopped first.
Setting a new configuration location on the existing context thus forcing
reconfiguration,
similar to the following:
{code:java}
((LoggerContext)
LogManager.getContext(false)).setConfigLocation(loggingUri);{code}
This works in a similar fashion: if log4j hasn't been initialized the call to
getContext() will trigger initialization and creation of the default context
that will then be reconfigured; and if it has been initialized then the current
context, whatever it may have been, will get reconfigured. The configuration
source will be created from the URI by the log4j framework.
The difference is that in the first way the context is replaced and all loggers
in the old (stopped) context will be dead. If any code on the stack holds
references to these dead loggers and tries to log to them it will be a no-op.
In the second way the context is kept but the configuration is replaced and
existing loggers are updated with the new configuration.
Both methods use core code and are therefore brittle, but both work for the
sunny day scenario (using log4j-core 2.10.0 anyway). However, neither one
appears to afford the user any control over handling any exceptional events, or
even inform the user that something went wrong. Log4j will "eat up" any
exceptions, and make its own executive decision how to handle them.
If a problem occurs after Configurator.initialize() is called log4j will create
a default configuration that effectively cuts all logging off other than errors
to the console and happily return the new context back not giving the calling
code any clue that logging has effectively been stopped.
If a problem occurs after
[GitHub] logging-log4j2 issue #146: fixes capitalization of log4j2.ContextDataInjecto...
Github user jvz commented on the issue: https://github.com/apache/logging-log4j2/pull/146 It's supposed to be lower case now with the new property naming scheme in use. It would be more useful to update existing code/docs to use the normalized property names instead IMO. ---
[jira] [Resolved] (LOG4J2-2239) Deadlock in log4j 2.10.0
[ https://issues.apache.org/jira/browse/LOG4J2-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramon Li resolved LOG4J2-2239. -- Resolution: Not A Problem Fix Version/s: 2.10.0 > Deadlock in log4j 2.10.0 > > > Key: LOG4J2-2239 > URL: https://issues.apache.org/jira/browse/LOG4J2-2239 > Project: Log4j 2 > Issue Type: Bug > Components: API >Affects Versions: 2.10.0 > Environment: OpenJDK 64-Bit Server VM (25.121-b13 mixed mode) in > docker >Reporter: Ramon Li >Priority: Major > Fix For: 2.10.0 > > Attachments: deadlock_stack.txt > > > I got a problem on our server, seems the log4j dead locked, I just attached > the thread stack in this email. > 550 threads blocked in this line: > java.lang.Thread.State: BLOCKED (on object monitor) > at > org.apache.logging.log4j.core.appender.OutputStreamManager.writeBytes(OutputStreamManager.java:360) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
