[jira] [Commented] (LOG4J2-1873) Implement UTF-8 encoding that doesn't use CharsetEncoder
[ https://issues.apache.org/jira/browse/LOG4J2-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15962607#comment-15962607 ] Remko Popma commented on LOG4J2-1873: - I'm open to ideas. We did something similar with core.util.StringEncoder for 8859-1 but that's not used on the garbage-free path. Would this be an enhancement or replacement of StringBuilderEncoder or something else entirely? > Implement UTF-8 encoding that doesn't use CharsetEncoder > > > Key: LOG4J2-1873 > URL: https://issues.apache.org/jira/browse/LOG4J2-1873 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Roman Leventov > > CharsetEncoder accepts only CharBuffers, and for the sake of being entirely > garbage-free we don't want to use CharBuffer.wrap(stringBuilder), when > encoding an event. > That forces us to make additional data copy from StringBuilder to a > thread-local CharBuffer. > This could be avoided by implementing UTF-8 encoding logic in log4j-core > itself, and not using CharsetEncoder. > This issue is specifically about UTF-8 because it is used predominantly and > it's relatively easy to implement. There are also likely some open-source > Apache 2-compatible implementations in Java out there already that we could > just copy and adapt. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1857) Listing all Loggers via JMX
[
https://issues.apache.org/jira/browse/LOG4J2-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942847#comment-15942847
]
Remko Popma commented on LOG4J2-1857:
-
Yes, good idea. I am swamped with other work. Can you provide a patch or pull
request, ideally with unit tests?
I think the natural place to put this functionality is in
{{org.apache.logging.log4j.jmx.gui.Client}} class in the {{log4j-jmx-gui}}
module, similar to the existing method
[{{getStatusLoggerAdmin}}|https://github.com/apache/logging-log4j2/blob/master/log4j-jmx-gui/src/main/java/org/apache/logging/log4j/jmx/gui/Client.java#L137].
> Listing all Loggers via JMX
> ---
>
> Key: LOG4J2-1857
> URL: https://issues.apache.org/jira/browse/LOG4J2-1857
> Project: Log4j 2
> Issue Type: Question
> Components: JMX
>Affects Versions: 2.6.1
>Reporter: Izek Greenfield
>
> How can I list all loggers via JMX / jolokia?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1857) Listing all Loggers via JMX
[
https://issues.apache.org/jira/browse/LOG4J2-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942847#comment-15942847
]
Remko Popma edited comment on LOG4J2-1857 at 3/27/17 8:41 AM:
--
Yes, good idea. I am swamped with other work. Can you provide a patch or pull
request, ideally with unit tests?
I think the natural place to put this functionality is in
{{org.apache.logging.log4j.jmx.gui.Client}} class in the {{log4j-jmx-gui}}
module, similar to the existing method [{{getStatusLoggerAdmin(String
contextName)}}|https://github.com/apache/logging-log4j2/blob/master/log4j-jmx-gui/src/main/java/org/apache/logging/log4j/jmx/gui/Client.java#L137].
was (Author: rem...@yahoo.com):
Yes, good idea. I am swamped with other work. Can you provide a patch or pull
request, ideally with unit tests?
I think the natural place to put this functionality is in
{{org.apache.logging.log4j.jmx.gui.Client}} class in the {{log4j-jmx-gui}}
module, similar to the existing method
[{{getStatusLoggerAdmin}}|https://github.com/apache/logging-log4j2/blob/master/log4j-jmx-gui/src/main/java/org/apache/logging/log4j/jmx/gui/Client.java#L137].
> Listing all Loggers via JMX
> ---
>
> Key: LOG4J2-1857
> URL: https://issues.apache.org/jira/browse/LOG4J2-1857
> Project: Log4j 2
> Issue Type: Question
> Components: JMX
>Affects Versions: 2.6.1
>Reporter: Izek Greenfield
>
> How can I list all loggers via JMX / jolokia?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1857) Listing all Loggers via JMX
[
https://issues.apache.org/jira/browse/LOG4J2-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942265#comment-15942265
]
Remko Popma edited comment on LOG4J2-1857 at 3/26/17 12:57 PM:
---
Does this work for you?
{code}
String serviceUrl = args[0]; // "host:port"
if (!serviceUrl.startsWith("service:jmx")) {
serviceUrl = "service:jmx:rmi:///jndi/rmi://" + args[0] + "/jmxrmi";
}
JMXServiceURL url = new JMXServiceURL(serviceUrl);
Properties props = System.getProperties();
Map paramMap = new HashMap<>(props.size());
for (String key : props.stringPropertyNames()) {
paramMap.put(key, props.getProperty(key));
}
JMXConnector connector = JMXConnectorFactory.connect(url, paramMap);
Client client = new Client(connector);
MBeanServerConnection mbs = client.getConnection();
for (LoggerContextAdminMBean ctx : client.getLoggerContextAdmins()) {
String search = String.format(LoggerConfigAdminMBean.PATTERN,
ctx.getName(), "*");
ObjectName pattern = new ObjectName(search);
Set found = mbs.queryNames(pattern, null);
for (ObjectName objectName : found) {
LoggerConfigAdminMBean proxy = JMX.newMBeanProxy(connection, //
objectName, //
LoggerConfigAdminMBean.class, true); // notificationBroadcaster
// TODO your logic here
}
}
{code}
was (Author: rem...@yahoo.com):
Does this work for you?
{code}
String serviceUrl = args[0]; // "host:port"
if (!serviceUrl.startsWith("service:jmx")) {
serviceUrl = "service:jmx:rmi:///jndi/rmi://" + args[0] + "/jmxrmi";
}
final JMXServiceURL url = new JMXServiceURL(serviceUrl);
final Properties props = System.getProperties();
final Map paramMap = new HashMap<>(props.size());
for (final String key : props.stringPropertyNames()) {
paramMap.put(key, props.getProperty(key));
}
final JMXConnector connector = JMXConnectorFactory.connect(url,
paramMap);
final Client client = new Client(connector);
MBeanServerConnection mbs = client.getConnection();
for (final LoggerContextAdminMBean ctx :
client.getLoggerContextAdmins()) {
String search = String.format(LoggerConfigAdminMBean.PATTERN,
ctx.getName(), "*");
ObjectName pattern = new ObjectName(search);
Set found = mbs.queryNames(pattern, null);
for (final ObjectName objectName : found) {
final LoggerConfigAdminMBean proxy =
JMX.newMBeanProxy(connection, //
objectName, //
LoggerConfigAdminMBean.class, true); // notificationBroadcaster
// TODO your logic here
}
}
{code}
> Listing all Loggers via JMX
> ---
>
> Key: LOG4J2-1857
> URL: https://issues.apache.org/jira/browse/LOG4J2-1857
> Project: Log4j 2
> Issue Type: Question
> Components: JMX
>Affects Versions: 2.6.1
>Reporter: Izek Greenfield
>
> How can I list all loggers via JMX / jolokia?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1857) Listing all Loggers via JMX
[ https://issues.apache.org/jira/browse/LOG4J2-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1857: Description: How can I list all loggers via JMX / jolokia? (was: Who I can list all logger via JMX / jolokia?) Summary: Listing all Loggers via JMX (was: List all Loger via JMx) > Listing all Loggers via JMX > --- > > Key: LOG4J2-1857 > URL: https://issues.apache.org/jira/browse/LOG4J2-1857 > Project: Log4j 2 > Issue Type: Question > Components: JMX >Affects Versions: 2.6.1 >Reporter: Izek Greenfield > > How can I list all loggers via JMX / jolokia? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1857) List all Loger via JMx
[
https://issues.apache.org/jira/browse/LOG4J2-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942265#comment-15942265
]
Remko Popma commented on LOG4J2-1857:
-
Does this work for you?
{code}
String serviceUrl = args[0]; // "host:port"
if (!serviceUrl.startsWith("service:jmx")) {
serviceUrl = "service:jmx:rmi:///jndi/rmi://" + args[0] + "/jmxrmi";
}
final JMXServiceURL url = new JMXServiceURL(serviceUrl);
final Properties props = System.getProperties();
final Map paramMap = new HashMap<>(props.size());
for (final String key : props.stringPropertyNames()) {
paramMap.put(key, props.getProperty(key));
}
final JMXConnector connector = JMXConnectorFactory.connect(url,
paramMap);
final Client client = new Client(connector);
MBeanServerConnection mbs = client.getConnection();
for (final LoggerContextAdminMBean ctx :
client.getLoggerContextAdmins()) {
String search = String.format(LoggerConfigAdminMBean.PATTERN,
ctx.getName(), "*");
ObjectName pattern = new ObjectName(search);
Set found = mbs.queryNames(pattern, null);
for (final ObjectName objectName : found) {
final LoggerConfigAdminMBean proxy =
JMX.newMBeanProxy(connection, //
objectName, //
LoggerConfigAdminMBean.class, true); // notificationBroadcaster
// TODO your logic here
}
}
{code}
> List all Loger via JMx
> --
>
> Key: LOG4J2-1857
> URL: https://issues.apache.org/jira/browse/LOG4J2-1857
> Project: Log4j 2
> Issue Type: Question
> Components: JMX
>Affects Versions: 2.6.1
>Reporter: Izek Greenfield
>
> Who I can list all logger via JMX / jolokia?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1370) Log4j2 cannot get env. variable
[ https://issues.apache.org/jira/browse/LOG4J2-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed LOG4J2-1370. --- Resolution: Resolved User reported that a they could not reproduce the issue any more after upgrading Windows. > Log4j2 cannot get env. variable > --- > > Key: LOG4J2-1370 > URL: https://issues.apache.org/jira/browse/LOG4J2-1370 > Project: Log4j 2 > Issue Type: Bug > Components: API >Affects Versions: 2.5 >Reporter: Some dude >Priority: Critical > > Please check issue here > http://stackoverflow.com/questions/36693517/log4j2-cannot-get-env-variable -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-1849) Broken FixedDateFormat tests when daylight saving time starts
[
https://issues.apache.org/jira/browse/LOG4J2-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved LOG4J2-1849.
-
Resolution: Fixed
Fix Version/s: 2.8.2
Fixed in commit c822338.
Please verify and close.
> Broken FixedDateFormat tests when daylight saving time starts
> -
>
> Key: LOG4J2-1849
> URL: https://issues.apache.org/jira/browse/LOG4J2-1849
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.8.1
>Reporter: Matt Sicker
>Assignee: Remko Popma
> Fix For: 2.8.2
>
>
> Today we started daylight saving time in the US, and the following tests
> failed:
> {noformat}
> Failed tests:
> FixedDateFormatTest.testFormatLong:162 ABSOLUTE(HH:mm:ss,SSS)/1489305608119
> expected:<0[3]:00:08,119> but was:<0[2]:00:08,119>
> FixedDateFormatTest.testFormatLongCharArrayInt:196
> ABSOLUTE(HH:mm:ss,SSS)/1489305607930 expected:<0[3]:00:07,930> but
> was:<0[2]:00:07,930>
> FixedDateFormatTest.testFormatLongCharArrayInt_goingBackInTime:214
> ABSOLUTE(HH:mm:ss,SSS)/1489381194091 expected:<2[3]:59:54,091> but
> was:<2[2]:59:54,091>
> FixedDateFormatTest.testFormatLong_goingBackInTime:178
> ABSOLUTE(HH:mm:ss,SSS)/1489381194072 expected:<2[3]:59:54,072> but
> was:<2[2]:59:54,072>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1841) Problems with consequences after LOG4J2-248
[ https://issues.apache.org/jira/browse/LOG4J2-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1841: Fix Version/s: 2.8.2 Setting fix version to prevent this issue from dropping below the horizon. > Problems with consequences after LOG4J2-248 > --- > > Key: LOG4J2-1841 > URL: https://issues.apache.org/jira/browse/LOG4J2-1841 > Project: Log4j 2 > Issue Type: Bug > Components: Boot >Affects Versions: 2.8 > Environment: Linux, Tomcat, WebApps >Reporter: Seweryn Habdank-Wojewodzki > Fix For: 2.8.2 > > > Situation till Log4j v. 2.5 (including it): > 1. One instance of embedded Jetty (programatically started) WITHOUT > definition of the log4j.configurationFile variable. > 2. WAR deployed on within this concrete instance of the embedded Jetty. > 3. WAR internally contains own log4j2.xml file. So every Log4j instance, > which is global for the WebApp, but local for the Jetty, will search and use > configuration in own class path. > Works in the way that every Web-App got own Log4j configuration and will > operate according to own definitions (appenders, layouts, loggers). > In the Log4j v. 2.6 and later in the same setup we are observing the > following: > Log4j in the applications are reporting problem that config file (log4j2.xml) > is not visible. Thus we got message, that Log4j will switch to backup mode > which will write only ERRORs in the console. > We debuged that issue and found that change made in: > https://issues.apache.org/jira/browse/LOG4J2-248 > seems to be the main reason. > We cannot asses if this change was made only with respect to some PMD warning > or it has as well some design considerations in background. > The consequence is that Web Server instance shall define > log4j.configurationFile variable, but also it means ALL WebApps within > Application Container will use one single configuration, what makes > definitely problem, as all WebApps providers must agree on ONE configuration > including appenders configuration, message Layout and so on. > Consider this report and provide solution (or workaround) or maybe just > reasonable comment for the given system setup, please :-). -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1849) Broken FixedDateFormat tests when daylight saving time starts
[
https://issues.apache.org/jira/browse/LOG4J2-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926127#comment-15926127
]
Remko Popma commented on LOG4J2-1849:
-
Thanks for the test. I will need to modify it slightly because it passes for me
(the default TimeZone for me is JST).
> Broken FixedDateFormat tests when daylight saving time starts
> -
>
> Key: LOG4J2-1849
> URL: https://issues.apache.org/jira/browse/LOG4J2-1849
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.8.1
>Reporter: Matt Sicker
>Assignee: Remko Popma
>
> Today we started daylight saving time in the US, and the following tests
> failed:
> {noformat}
> Failed tests:
> FixedDateFormatTest.testFormatLong:162 ABSOLUTE(HH:mm:ss,SSS)/1489305608119
> expected:<0[3]:00:08,119> but was:<0[2]:00:08,119>
> FixedDateFormatTest.testFormatLongCharArrayInt:196
> ABSOLUTE(HH:mm:ss,SSS)/1489305607930 expected:<0[3]:00:07,930> but
> was:<0[2]:00:07,930>
> FixedDateFormatTest.testFormatLongCharArrayInt_goingBackInTime:214
> ABSOLUTE(HH:mm:ss,SSS)/1489381194091 expected:<2[3]:59:54,091> but
> was:<2[2]:59:54,091>
> FixedDateFormatTest.testFormatLong_goingBackInTime:178
> ABSOLUTE(HH:mm:ss,SSS)/1489381194072 expected:<2[3]:59:54,072> but
> was:<2[2]:59:54,072>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1849) Broken FixedDateFormat tests when daylight saving time starts
[
https://issues.apache.org/jira/browse/LOG4J2-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924232#comment-15924232
]
Remko Popma commented on LOG4J2-1849:
-
I've started to look at this. The idea of FixedDateFormat is that by supporting
a subset of the SimpleDateFormat functionality we could get significant
performance gains. Of course daylight savings jumps need to be supported.
FixedDateFormat currently stores the TimeZone but does not do anything with it.
There is some pre-calculation that happens once every day to format the date
portion. I'm thinking to add logic there to look ahead at the hours of the
coming day and pre-calculate the DST savings as well.
If you're interested in making more contributions, I would really appreciate
more repeatable test cases since our current tests only failed on the day that
a DST change occurred.
> Broken FixedDateFormat tests when daylight saving time starts
> -
>
> Key: LOG4J2-1849
> URL: https://issues.apache.org/jira/browse/LOG4J2-1849
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.8.1
>Reporter: Matt Sicker
>Assignee: Remko Popma
>
> Today we started daylight saving time in the US, and the following tests
> failed:
> {noformat}
> Failed tests:
> FixedDateFormatTest.testFormatLong:162 ABSOLUTE(HH:mm:ss,SSS)/1489305608119
> expected:<0[3]:00:08,119> but was:<0[2]:00:08,119>
> FixedDateFormatTest.testFormatLongCharArrayInt:196
> ABSOLUTE(HH:mm:ss,SSS)/1489305607930 expected:<0[3]:00:07,930> but
> was:<0[2]:00:07,930>
> FixedDateFormatTest.testFormatLongCharArrayInt_goingBackInTime:214
> ABSOLUTE(HH:mm:ss,SSS)/1489381194091 expected:<2[3]:59:54,091> but
> was:<2[2]:59:54,091>
> FixedDateFormatTest.testFormatLong_goingBackInTime:178
> ABSOLUTE(HH:mm:ss,SSS)/1489381194072 expected:<2[3]:59:54,072> but
> was:<2[2]:59:54,072>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-1849) Broken FixedDateFormat tests when daylight saving time starts
[
https://issues.apache.org/jira/browse/LOG4J2-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma reassigned LOG4J2-1849:
---
Assignee: Remko Popma
> Broken FixedDateFormat tests when daylight saving time starts
> -
>
> Key: LOG4J2-1849
> URL: https://issues.apache.org/jira/browse/LOG4J2-1849
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.8.1
>Reporter: Matt Sicker
>Assignee: Remko Popma
>
> Today we started daylight saving time in the US, and the following tests
> failed:
> {noformat}
> Failed tests:
> FixedDateFormatTest.testFormatLong:162 ABSOLUTE(HH:mm:ss,SSS)/1489305608119
> expected:<0[3]:00:08,119> but was:<0[2]:00:08,119>
> FixedDateFormatTest.testFormatLongCharArrayInt:196
> ABSOLUTE(HH:mm:ss,SSS)/1489305607930 expected:<0[3]:00:07,930> but
> was:<0[2]:00:07,930>
> FixedDateFormatTest.testFormatLongCharArrayInt_goingBackInTime:214
> ABSOLUTE(HH:mm:ss,SSS)/1489381194091 expected:<2[3]:59:54,091> but
> was:<2[2]:59:54,091>
> FixedDateFormatTest.testFormatLong_goingBackInTime:178
> ABSOLUTE(HH:mm:ss,SSS)/1489381194072 expected:<2[3]:59:54,072> but
> was:<2[2]:59:54,072>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906209#comment-15906209 ] Remko Popma edited comment on LOG4J2-1359 at 3/11/17 2:09 PM: -- Is it possible to compile only one class with Java 9 and the rest with Java 7? Maybe have a module with Java 9-only functionality? We currently delay walking the stack until we need to. Can we do something similar with capturing the stack? That is, only capture it when a) we're logging synchronously and one of the pattern converters asks for the caller location, or b) we're logging asynchronously and we're configured to capture a stack snapshot before handing over the log event details to the background thread? I don't understand what the openjdk devs are suggesting concretely. Can you give an example, or point me to something (a specific API, or an example, or an email) that would clarify? was (Author: rem...@yahoo.com): Is it possible to compile only one class with Java 9 and the rest with Java 7? Maybe have a module with Java 9-only functionality? We currently delay walking the stack until we need to. Can we do something similar with capturing the stack? That is, only capture it when a) we're logging synchronously and one of the pattern converters asks for the caller location, or b) we're logging asynchronously and we're configured to capture a stack snapshot before handing over the log event details to the background thread? I don't understand what the openjdk devs are suggesting concretely. Can you point me to something (a specific API, or an example, or an email) that would clarify? > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906209#comment-15906209 ] Remko Popma edited comment on LOG4J2-1359 at 3/11/17 2:05 PM: -- Is it possible to compile only one class with Java 9 and the rest with Java 7? Maybe have a module with Java 9-only functionality? We currently delay walking the stack until we need to. Can we do something similar with capturing the stack? That is, only capture it when a) we're logging synchronously and one of the pattern converters asks for the caller location, or b) we're logging asynchronously and we're configured to capture a stack snapshot before handing over the log event details to the background thread? I don't understand what the openjdk devs are suggesting concretely. Can you point me to something (a specific API, or an example, or an email) that would clarify? was (Author: rem...@yahoo.com): Is it possible to compile only one class with Java 9 and the rest with Java 7? We currently delay walking the stack until we need to. Can we do something similar with capturing the stack? That is, only capture it when a) we're logging synchronously and one of the pattern converters asks for the caller location, or b) we're logging asynchronously and we're configured to capture a stack snapshot before handing over the log event details to the background thread? I don't understand what the openjdk devs are suggesting concretely. Can you point me to something (a specific API, or an example, or an email) that would clarify? > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906209#comment-15906209 ] Remko Popma commented on LOG4J2-1359: - Is it possible to compile only one class with Java 9 and the rest with Java 7? We currently delay walking the stack until we need to. Can we do something similar with capturing the stack? That is, only capture it when a) we're logging synchronously and one of the pattern converters asks for the caller location, or b) we're logging asynchronously and we're configured to capture a stack snapshot before handing over the log event details to the background thread? I don't understand what the openjdk devs are suggesting concretely. Can you point me to something (a specific API, or an example, or an email) that would clarify? > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1844) Not the correct value of the month in the log
[
https://issues.apache.org/jira/browse/LOG4J2-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15905468#comment-15905468
]
Remko Popma edited comment on LOG4J2-1844 at 3/10/17 5:46 PM:
--
I believe the specified pattern is wrong and should be {{%d\{-MM-dd
HH:mm:ss.SSS\}}} instead: lowercase {{mm}} stands for "minutes", uppercase
{{MM}} is needed if you want to express months.
Please close if this solves the problem, or re-open if I misunderstood.
was (Author: rem...@yahoo.com):
I believe the specified pattern is wrong and should be {{ %d\{-MM-dd
HH:mm:ss.SSS\}}} instead: lowercase {{mm}} stands for "minutes", uppercase
{{MM}} is needed if you want to express months.
Please close if this solves the problem, or re-open if I misunderstood.
> Not the correct value of the month in the log
> -
>
> Key: LOG4J2-1844
> URL: https://issues.apache.org/jira/browse/LOG4J2-1844
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.8.1
> Environment: windows RUS (v.7 and 8.1 is accurate)
> eclipse 4.5.2
> java jdk 1.8.0_74
>Reporter: Vasiliy Ponomarenko
>Assignee: Remko Popma
> Labels: month
>
> if pattern contains Month like {{%d\{-mm-dd HH:mm:ss.SSS\}}}
> log has wrong Month value
> Window 8.1 like Month value = 19 or 34 or 35 or 36
> 2017-19-10 16:19:05.535 \[main\] for date 2017-03-10
> Window 7 like Month value = current value - 1
> 2017-02-10 16:19:05.535 \[main\] for date 2017-03-10
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-1844) Not the correct value of the month in the log
[
https://issues.apache.org/jira/browse/LOG4J2-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved LOG4J2-1844.
-
Resolution: Not A Problem
I believe the specified pattern is wrong and should be {{ %d\{-MM-dd
HH:mm:ss.SSS\}}} instead: lowercase {{mm}} stands for "minutes", uppercase
{{MM}} is needed if you want to express months.
Please close if this solves the problem, or re-open if I misunderstood.
> Not the correct value of the month in the log
> -
>
> Key: LOG4J2-1844
> URL: https://issues.apache.org/jira/browse/LOG4J2-1844
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.8.1
> Environment: windows RUS (v.7 and 8.1 is accurate)
> eclipse 4.5.2
> java jdk 1.8.0_74
>Reporter: Vasiliy Ponomarenko
>Assignee: Remko Popma
> Labels: month
>
> if pattern contains Month like {{%d\{-mm-dd HH:mm:ss.SSS\}}}
> log has wrong Month value
> Window 8.1 like Month value = 19 or 34 or 35 or 36
> 2017-19-10 16:19:05.535 \[main\] for date 2017-03-10
> Window 7 like Month value = current value - 1
> 2017-02-10 16:19:05.535 \[main\] for date 2017-03-10
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1844) Not the correct value of the month in the log
[
https://issues.apache.org/jira/browse/LOG4J2-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1844:
Description:
if pattern contains Month like {{%d\{-mm-dd HH:mm:ss.SSS\}}}
log has wrong Month value
Window 8.1 like Month value = 19 or 34 or 35 or 36
2017-19-10 16:19:05.535 \[main\] for date 2017-03-10
Window 7 like Month value = current value - 1
2017-02-10 16:19:05.535 \[main\] for date 2017-03-10
was:
if pattern contains Month like %d{-mm-dd HH:mm:ss.SSS}
log has wrong Month value
Window 8.1 like Month value = 19 or 34 or 35 or 36
2017-19-10 16:19:05.535 [main] for date 2017-03-10
Window 7 like Month value = current value - 1
2017-02-10 16:19:05.535 [main] for date 2017-03-10
> Not the correct value of the month in the log
> -
>
> Key: LOG4J2-1844
> URL: https://issues.apache.org/jira/browse/LOG4J2-1844
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.8.1
> Environment: windows RUS (v.7 and 8.1 is accurate)
> eclipse 4.5.2
> java jdk 1.8.0_74
>Reporter: Vasiliy Ponomarenko
>Assignee: Remko Popma
> Labels: month
>
> if pattern contains Month like {{%d\{-mm-dd HH:mm:ss.SSS\}}}
> log has wrong Month value
> Window 8.1 like Month value = 19 or 34 or 35 or 36
> 2017-19-10 16:19:05.535 \[main\] for date 2017-03-10
> Window 7 like Month value = current value - 1
> 2017-02-10 16:19:05.535 \[main\] for date 2017-03-10
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-1844) Not the correct value of the month in the log
[
https://issues.apache.org/jira/browse/LOG4J2-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma reassigned LOG4J2-1844:
---
Assignee: Remko Popma
> Not the correct value of the month in the log
> -
>
> Key: LOG4J2-1844
> URL: https://issues.apache.org/jira/browse/LOG4J2-1844
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.8.1
> Environment: windows RUS (v.7 and 8.1 is accurate)
> eclipse 4.5.2
> java jdk 1.8.0_74
>Reporter: Vasiliy Ponomarenko
>Assignee: Remko Popma
> Labels: month
>
> if pattern contains Month like %d{-mm-dd HH:mm:ss.SSS}
> log has wrong Month value
> Window 8.1 like Month value = 19 or 34 or 35 or 36
> 2017-19-10 16:19:05.535 [main] for date 2017-03-10
> Window 7 like Month value = current value - 1
> 2017-02-10 16:19:05.535 [main] for date 2017-03-10
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1841) Problems with consequences after LOG4J2-248
[ https://issues.apache.org/jira/browse/LOG4J2-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15903193#comment-15903193 ] Remko Popma commented on LOG4J2-1841: - Sounds like we should roll back LOG4J2-248. Matt, what do you think? > Problems with consequences after LOG4J2-248 > --- > > Key: LOG4J2-1841 > URL: https://issues.apache.org/jira/browse/LOG4J2-1841 > Project: Log4j 2 > Issue Type: Bug > Components: Boot >Affects Versions: 2.8 > Environment: Linux, Tomcat, WebApps >Reporter: Seweryn Habdank-Wojewodzki > > Situation till Log4j v. 2.5 (including it): > 1. One instance of embedded Jetty (programatically started) WITHOUT > definition of the log4j.configurationFile variable. > 2. WAR deployed on within this concrete instance of the embedded Jetty. > 3. WAR internally contains own log4j2.xml file. So every Log4j instance, > which is global for the WebApp, but local for the Jetty, will search and use > configuration in own class path. > Works in the way that every Web-App got own Log4j configuration and will > operate according to own definitions (appenders, layouts, loggers). > In the Log4j v. 2.6 and later in the same setup we are observing the > following: > Log4j in the applications are reporting problem that config file (log4j2.xml) > is not visible. Thus we got message, that Log4j will switch to backup mode > which will write only ERRORs in the console. > We debuged that issue and found that change made in: > https://issues.apache.org/jira/browse/LOG4J2-248 > seems to be the main reason. > We cannot asses if this change was made only with respect to some PMD warning > or it has as well some design considerations in background. > The consequence is that Web Server instance shall define > log4j.configurationFile variable, but also it means ALL WebApps will use one > single configuration, what makes definitely problem, as all WebApps providers > must agree on ONE configuration including appenders configuration, message > Layout and so on. > Consider this report and provide solution (or workaround) or maybe just > reasonable comment for the given system setup, please :-). -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1259) Log4j threads are leaking on Tomcat shutdown
[
https://issues.apache.org/jira/browse/LOG4J2-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15895092#comment-15895092
]
Remko Popma commented on LOG4J2-1259:
-
Do you want to provide a patch for the Log4j2 manual?
> Log4j threads are leaking on Tomcat shutdown
>
>
> Key: LOG4J2-1259
> URL: https://issues.apache.org/jira/browse/LOG4J2-1259
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.5
>Reporter: Misagh Moayyed
>
> Running log4j2 v2.5 with disruptor 3.3.x. AsyncLoggers configured. log4j-web
> also included in the web application deployed in Tomcat 8. The context
> listener is correctly starting up and shutting down, catalina.properties does
> not include the log4j*.jar entry. Yet I see:
> {code}
> 20-Jan-2016 14:59:26.322 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-Log4j2Scheduled-5] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> 20-Jan-2016 14:59:26.336 WARNING [localhost-startStop-2]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [cas-server-webapp-4.3.0-SNAPSHOT] appears to have started a
> thread named [Log4j2-AsyncLoggerConfig-6] but has failed to stop it. This is
> very likely to create a memory leak. Stack trace of thread:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)
>
> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1761) Support for standard java queues for the async logger
[ https://issues.apache.org/jira/browse/LOG4J2-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15891237#comment-15891237 ] Remko Popma edited comment on LOG4J2-1761 at 3/1/17 10:58 PM: -- You can get some of the advantages by using AsyncAppender. You can select the queue implementation when you use AsyncAppender. Async Loggers are faster than AsyncAppender in multithreaded scenarios because of the Disruptor. Building Async Loggers without the Disruptor would be pointless. If you don't want to use the Disruptor please use AsyncAppender. About the overflow, you may be right (I haven't checked). How often can this happen? Assuming you are logging 100 million events per second, how long does it take to overflow a 64 bit long? was (Author: rem...@yahoo.com): You can get some of the advantages by using AsyncAppender. You can select the queue implementation when you use AsyncAppender. AsyncAppender Loggers are faster in multithreaded scenarios because of the Disruptor. If you don't want to use it please use AsyncAppender. About the overflow, you may be right (I haven't checked). How often can this happen? Assuming you are logging 100 million events per second, how long does it take to overflow a 64 bit long? > Support for standard java queues for the async logger > - > > Key: LOG4J2-1761 > URL: https://issues.apache.org/jira/browse/LOG4J2-1761 > Project: Log4j 2 > Issue Type: Improvement > Components: Core >Affects Versions: 2.7 >Reporter: Kim Northrop >Priority: Minor > Attachments: AsyncLogEvent.java, AsyncLoggerWithQueueContext.java, > AsyncLoggerWithQueueContextSelector.java, AsyncLoggerWithQueue.java, > QueueWrapperCLQ.java, QueueWrapper.java, QueueWrapperLBQ.java, > QueueWrapperLTQ.java > > > Please add support for standard java queues (LinkedTransferQueue, > ArrayBlockingQueue, LinkedBlockingQueue, ConcurrentLinkedQueue) to the async > logger. I will attach some classes for usage with System properties > (Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerWithQueueContextSelector, > LoggerQueue.Capacity=, LoggerQueue.Type= LinkedTransferQueue, ConcurrentLinkedQueue, LinkedBlockingQueue>). Since most > of these queues allocate new nodes for new elements I have not implemented > usage of thread locals for the log events. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1761) Support for standard java queues for the async logger
[ https://issues.apache.org/jira/browse/LOG4J2-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15891237#comment-15891237 ] Remko Popma commented on LOG4J2-1761: - You can get some of the advantages by using AsyncAppender. You can select the queue implementation when you use AsyncAppender. AsyncAppender Loggers are faster in multithreaded scenarios because of the Disruptor. If you don't want to use it please use AsyncAppender. About the overflow, you may be right (I haven't checked). How often can this happen? Assuming you are logging 100 million events per second, how long does it take to overflow a 64 bit long? > Support for standard java queues for the async logger > - > > Key: LOG4J2-1761 > URL: https://issues.apache.org/jira/browse/LOG4J2-1761 > Project: Log4j 2 > Issue Type: Improvement > Components: Core >Affects Versions: 2.7 >Reporter: Kim Northrop >Priority: Minor > Attachments: AsyncLogEvent.java, AsyncLoggerWithQueueContext.java, > AsyncLoggerWithQueueContextSelector.java, AsyncLoggerWithQueue.java, > QueueWrapperCLQ.java, QueueWrapper.java, QueueWrapperLBQ.java, > QueueWrapperLTQ.java > > > Please add support for standard java queues (LinkedTransferQueue, > ArrayBlockingQueue, LinkedBlockingQueue, ConcurrentLinkedQueue) to the async > logger. I will attach some classes for usage with System properties > (Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerWithQueueContextSelector, > LoggerQueue.Capacity=, LoggerQueue.Type= LinkedTransferQueue, ConcurrentLinkedQueue, LinkedBlockingQueue>). Since most > of these queues allocate new nodes for new elements I have not implemented > usage of thread locals for the log events. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1829) Delete log files older than x days and max size of a log file should be y(MB)
[ https://issues.apache.org/jira/browse/LOG4J2-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15889858#comment-15889858 ] Remko Popma commented on LOG4J2-1829: - Have you seen the Custom Delete action supported by the Rollover File appender: https://logging.apache.org/log4j/2.x/manual/appenders.html#CustomDeleteOnRollover > Delete log files older than x days and max size of a log file should be y(MB) > - > > Key: LOG4J2-1829 > URL: https://issues.apache.org/jira/browse/LOG4J2-1829 > Project: Log4j 2 > Issue Type: Bug >Reporter: Senthilraja > > I need log4j to handle the following requirements(both). > 1) I want my log files to be created with maximum size of 100MB, exceeding > that size a new file should be created. > 2) I need to mention number of days to maintain the log files. If the > specified days have crossed, the older log files should be deleted. > Whether both the requirements can be handled in same log4j configuration. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1797) Add asynchronous/non-blocking SPIs for appenders
[
https://issues.apache.org/jira/browse/LOG4J2-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884093#comment-15884093
]
Remko Popma commented on LOG4J2-1797:
-
Would it be possible to use the LMAX ExceptionHandler interface (or introduce
our own interface which has match the signature of {{handleEventException}} so
we can have one impl that satisfies both interfaces)? I also like the idea of
having a {{handleOnShutdownException}} method.
Here is what the LMAX interface looks like, javadocs and all:
{code}
/**
* Callback handler for uncaught exceptions in the event processing cycle of
the {@link BatchEventProcessor}
*/
public interface ExceptionHandler {
/**
* Strategy for handling uncaught exceptions when processing an
event.
*
* If the strategy wishes to terminate further processing by the {@link
BatchEventProcessor}
* then it should throw a {@link RuntimeException}.
*
* @param ex the exception that propagated from the {@link
EventHandler}.
* @param sequence of the event which cause the exception.
* @param eventbeing processed when the exception occurred. This can
be null.
void handleEventException(Throwable ex, long sequence, T event);
/**
* Callback to notify of an exception during {@link
LifecycleAware#onStart()}
* @param ex throw during the starting process.
*/
void handleOnStartException(Throwable ex);
/**
* Callback to notify of an exception during {@link
LifecycleAware#onShutdown()}
* @param ex throw during the shutdown process.
*/
void handleOnShutdownException(Throwable ex);
}
{code}
> Add asynchronous/non-blocking SPIs for appenders
>
>
> Key: LOG4J2-1797
> URL: https://issues.apache.org/jira/browse/LOG4J2-1797
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
>Reporter: Matt Sicker
>
> Some appenders (e.g., Kafka and Cassandra) support using an asynchronous SPI
> with callbacks (to make them non-blocking). In a Scala-based API, this could
> be easily handled with the Future class, and with Java 8, this could be
> easily handled with a CompleteableFuture class. However, if this API
> improvement is desired for Java 7, then we'd need to create a basic callback
> API that would ideally be easy to update to CompleteableFuture later on.
> In theory, such an SPI could also be adapted to use the Flow classes in Java
> 9. This may be an interesting API to follow as we could use the Reactive
> Streams standard API or a compatible API.
> Some main things that would be desirable in such an SPI would include
> asynchronous error handling (e.g., to trigger a failover appender). This
> should be adapted to work well with the generic AsyncAppender and AsyncLogger
> as well.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1807) [core] Add and implement LogEvent.toImmutable()
[
https://issues.apache.org/jira/browse/LOG4J2-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884087#comment-15884087
]
Remko Popma commented on LOG4J2-1807:
-
Looking at the code, I would suggest:
* removing the non-static Log4jLogEvent.createMemento() method. It is currently
not used, and it may create confusion for users: should they call
{{toImmutable}} or {{createMemento}}?
* removing the static Log4jLogEvent.createMemento(LogEvent) method. Current
callers (there's only 2) can be updated to call the {{createMemento(LogEvent
event, boolean includeLocation)}} method instead.
> [core] Add and implement LogEvent.toImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
> Issue Type: New Feature
>Affects Versions: 2.8.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Attachments: logging-log4j2.patch
>
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
> * Returns an immutable version of this log event, which MAY BE a copy of
> this event.
> *
> * @return an immutable version of this log event
> */
> LogEvent asImmutable();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1820) Log4j 2.8 can lose exceptions when a security manager is present
[ https://issues.apache.org/jira/browse/LOG4J2-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876449#comment-15876449 ] Remko Popma commented on LOG4J2-1820: - Hi Jason, I'm traveling and may not get around to looking at this for some time. Perhaps someone else in the community can take a look? > Log4j 2.8 can lose exceptions when a security manager is present > > > Key: LOG4J2-1820 > URL: https://issues.apache.org/jira/browse/LOG4J2-1820 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Jason Tedor > Attachments: > 0001-Handle-security-exception-on-getting-class-loader.patch > > > When Log4j is rendering an exception, it can attempt to access a class loader > that it does not have permissions to access when a security manager is > present. > I have a patch and a failing test case for this; I will submit it shortly. > This is similar to LOG4J2-1560. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1760) AsyncAppender with LinkedTransferQueue.offer()
[ https://issues.apache.org/jira/browse/LOG4J2-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1760: Fix Version/s: 2.8.1 > AsyncAppender with LinkedTransferQueue.offer() > -- > > Key: LOG4J2-1760 > URL: https://issues.apache.org/jira/browse/LOG4J2-1760 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.7 >Reporter: Addison Walterson >Assignee: Remko Popma >Priority: Minor > Fix For: 2.8.1 > > > I suggest that the AsyncAppender can use a LinkedTransferQueue for which > offer() is used to enqueue messages because tryTransfer() only succeeds if > the receiving thread waits for a message which means that the queue has > length 0. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-1760) AsyncAppender with LinkedTransferQueue.offer()
[ https://issues.apache.org/jira/browse/LOG4J2-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma reassigned LOG4J2-1760: --- Assignee: Remko Popma > AsyncAppender with LinkedTransferQueue.offer() > -- > > Key: LOG4J2-1760 > URL: https://issues.apache.org/jira/browse/LOG4J2-1760 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.7 >Reporter: Addison Walterson >Assignee: Remko Popma >Priority: Minor > Fix For: 2.8.1 > > > I suggest that the AsyncAppender can use a LinkedTransferQueue for which > offer() is used to enqueue messages because tryTransfer() only succeeds if > the receiving thread waits for a message which means that the queue has > length 0. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1563) Log4j 2.6.2 can lose exceptions when a security manager is present
[ https://issues.apache.org/jira/browse/LOG4J2-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15872993#comment-15872993 ] Remko Popma commented on LOG4J2-1563: - I Saw you raised LOG4J2-1820 for the new issue. Perfect, thanks! > Log4j 2.6.2 can lose exceptions when a security manager is present > -- > > Key: LOG4J2-1563 > URL: https://issues.apache.org/jira/browse/LOG4J2-1563 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.6.2 >Reporter: Jason Tedor >Assignee: Gary Gregory > Fix For: 2.7 > > Attachments: > 0001-Unify-handling-of-throwables-when-loading-class.patch, > 0002-Remove-policy-in-throwable-proxy-security-test.patch, > throwable-proxy-security-exception-2.6.2.patch > > > When Log4j is rendering an exception, it can attempt to load classes that it > does not have permissions to load when a security manager is present. > I have a patch and a failing test case for this; I will submit it shortly. > This is the backport for LOG4J2-1560. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1807) [core] Add and implement LogEvent.toImmutable()
[
https://issues.apache.org/jira/browse/LOG4J2-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15872545#comment-15872545
]
Remko Popma commented on LOG4J2-1807:
-
They have different usages. From memory: the Builder is used in the critical
path for non-garbagefree logging (so needs to be fast), while the
serialize-deserialize implementation is used by some appenders like the SMTP
appender. I believe both implementations have existed for a long time. It may
be possible to unify them but we would need to be very sure there's no side
effect anywhere...
> [core] Add and implement LogEvent.toImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
> Issue Type: New Feature
>Affects Versions: 2.8.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Attachments: logging-log4j2.patch
>
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
> * Returns an immutable version of this log event, which MAY BE a copy of
> this event.
> *
> * @return an immutable version of this log event
> */
> LogEvent asImmutable();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1807) [core] Add and implement LogEvent.toImmutable()
[
https://issues.apache.org/jira/browse/LOG4J2-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15871191#comment-15871191
]
Remko Popma commented on LOG4J2-1807:
-
Gary, will do. I'll try to make time in the next few weeks.
> [core] Add and implement LogEvent.toImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
> Issue Type: New Feature
>Affects Versions: 2.8.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Attachments: logging-log4j2.patch
>
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
> * Returns an immutable version of this log event, which MAY BE a copy of
> this event.
> *
> * @return an immutable version of this log event
> */
> LogEvent asImmutable();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1816) Fix minOccur in log4j-config.xsd
[ https://issues.apache.org/jira/browse/LOG4J2-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed LOG4J2-1816. --- Resolution: Fixed Pull request accepted in commit 2cb9949. Keep 'em coming! > Fix minOccur in log4j-config.xsd > > > Key: LOG4J2-1816 > URL: https://issues.apache.org/jira/browse/LOG4J2-1816 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Remko Popma >Assignee: Remko Popma > Fix For: 2.8.1 > > > StackOverflow pull request #58: > https://github.com/apache/logging-log4j2/pull/58/files/8290a8812e51c60df507c52803d211b7523d948c -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1816) Fix minOccur in log4j-config.xsd
Remko Popma created LOG4J2-1816: --- Summary: Fix minOccur in log4j-config.xsd Key: LOG4J2-1816 URL: https://issues.apache.org/jira/browse/LOG4J2-1816 Project: Log4j 2 Issue Type: Bug Affects Versions: 2.8 Reporter: Remko Popma Assignee: Remko Popma Fix For: 2.8.1 StackOverflow pull request #58: https://github.com/apache/logging-log4j2/pull/58/files/8290a8812e51c60df507c52803d211b7523d948c -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1814) Wrapper Generate$ExtendedLogger name inconvenient on Linux
[
https://issues.apache.org/jira/browse/LOG4J2-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15865220#comment-15865220
]
Remko Popma commented on LOG4J2-1814:
-
That is what I had in mind. Sorry I wasn't clear.
> Wrapper Generate$ExtendedLogger name inconvenient on Linux
> ---
>
> Key: LOG4J2-1814
> URL: https://issues.apache.org/jira/browse/LOG4J2-1814
> Project: Log4j 2
> Issue Type: Improvement
>Reporter: Remko Popma
>Assignee: Remko Popma
>
> The $ExtendedLogger is interpreted as an environment variable.
> {code}
> $ java -cp log4j-core-2.8.jar
> org.apache.logging.log4j.core.tools.Generate$ExtendedLogger \
> com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 >
> com/mycomp/ExtLogger.java
> Error: Main method not found in class
> org.apache.logging.log4j.core.tools.Generate, please define the main method
> {code}
> The workaround is to quote the class name:
> {code}
> $ java -cp log4j-core-2.8.jar
> "org.apache.logging.log4j.core.tools.Generate$ExtendedLogger" \
> com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 >
> com/mycomp/ExtLogger.java
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1814) Wrapper Generate$ExtendedLogger name inconvenient on Linux
[
https://issues.apache.org/jira/browse/LOG4J2-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15865065#comment-15865065
]
Remko Popma commented on LOG4J2-1814:
-
Also, improve the docs to clarify usage
(http://stackoverflow.com/q/42192625/1446916).
> Wrapper Generate$ExtendedLogger name inconvenient on Linux
> ---
>
> Key: LOG4J2-1814
> URL: https://issues.apache.org/jira/browse/LOG4J2-1814
> Project: Log4j 2
> Issue Type: Improvement
>Reporter: Remko Popma
>Assignee: Remko Popma
>
> The $ExtendedLogger is interpreted as an environment variable.
> {code}
> $ java -cp log4j-core-2.8.jar
> org.apache.logging.log4j.core.tools.Generate$ExtendedLogger \
> com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 >
> com/mycomp/ExtLogger.java
> Error: Main method not found in class
> org.apache.logging.log4j.core.tools.Generate, please define the main method
> {code}
> The workaround is to quote the class name:
> {code}
> $ java -cp log4j-core-2.8.jar
> "org.apache.logging.log4j.core.tools.Generate$ExtendedLogger" \
> com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 >
> com/mycomp/ExtLogger.java
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1814) Wrapper Generate$ExtendedLogger name inconvenient on Linux
[
https://issues.apache.org/jira/browse/LOG4J2-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1814:
Description:
The $ExtendedLogger is interpreted as an environment variable.
{code}
$ java -cp log4j-core-2.8.jar
org.apache.logging.log4j.core.tools.Generate$ExtendedLogger \
com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 >
com/mycomp/ExtLogger.java
Error: Main method not found in class
org.apache.logging.log4j.core.tools.Generate, please define the main method
{code}
The workaround is to quote the class name:
{code}
$ java -cp log4j-core-2.8.jar
"org.apache.logging.log4j.core.tools.Generate$ExtendedLogger" \
com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 >
com/mycomp/ExtLogger.java
{code}
was:
The $ExtendedLogger is interpreted as an environment variable.
{code}
$ java -cp log4j-core-2.8.jar
org.apache.logging.log4j.core.tools.Generate$ExtendedLogger \
> com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 >
> com/mycomp/ExtLogger.java
Error: Main method not found in class
org.apache.logging.log4j.core.tools.Generate, please define the main method
{code}
The workaround is to quote the class name:
{code}
$ java -cp log4j-core-2.8.jar
"org.apache.logging.log4j.core.tools.Generate$ExtendedLogger" \
> com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 >
> com/mycomp/ExtLogger.java
{code}
> Wrapper Generate$ExtendedLogger name inconvenient on Linux
> ---
>
> Key: LOG4J2-1814
> URL: https://issues.apache.org/jira/browse/LOG4J2-1814
> Project: Log4j 2
> Issue Type: Improvement
>Reporter: Remko Popma
>Assignee: Remko Popma
>
> The $ExtendedLogger is interpreted as an environment variable.
> {code}
> $ java -cp log4j-core-2.8.jar
> org.apache.logging.log4j.core.tools.Generate$ExtendedLogger \
> com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 >
> com/mycomp/ExtLogger.java
> Error: Main method not found in class
> org.apache.logging.log4j.core.tools.Generate, please define the main method
> {code}
> The workaround is to quote the class name:
> {code}
> $ java -cp log4j-core-2.8.jar
> "org.apache.logging.log4j.core.tools.Generate$ExtendedLogger" \
> com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 >
> com/mycomp/ExtLogger.java
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1814) Wrapper Generate$ExtendedLogger name inconvenient on Linux
[
https://issues.apache.org/jira/browse/LOG4J2-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1814:
Description:
The $ExtendedLogger is interpreted as an environment variable.
{code}
$ java -cp log4j-core-2.8.jar
org.apache.logging.log4j.core.tools.Generate$ExtendedLogger \
> com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 >
> com/mycomp/ExtLogger.java
Error: Main method not found in class
org.apache.logging.log4j.core.tools.Generate, please define the main method
{code}
The workaround is to quote the class name:
{code}
$ java -cp log4j-core-2.8.jar
"org.apache.logging.log4j.core.tools.Generate$ExtendedLogger" \
> com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 >
> com/mycomp/ExtLogger.java
{code}
was:The $ExtendedLogger is interpreted as an environment variable.
> Wrapper Generate$ExtendedLogger name inconvenient on Linux
> ---
>
> Key: LOG4J2-1814
> URL: https://issues.apache.org/jira/browse/LOG4J2-1814
> Project: Log4j 2
> Issue Type: Improvement
>Reporter: Remko Popma
>Assignee: Remko Popma
>
> The $ExtendedLogger is interpreted as an environment variable.
> {code}
> $ java -cp log4j-core-2.8.jar
> org.apache.logging.log4j.core.tools.Generate$ExtendedLogger \
> > com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 >
> > com/mycomp/ExtLogger.java
> Error: Main method not found in class
> org.apache.logging.log4j.core.tools.Generate, please define the main method
> {code}
> The workaround is to quote the class name:
> {code}
> $ java -cp log4j-core-2.8.jar
> "org.apache.logging.log4j.core.tools.Generate$ExtendedLogger" \
> > com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 >
> > com/mycomp/ExtLogger.java
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1814) Wrapper Generate$ExtendedLogger name inconvenient on Linux
[ https://issues.apache.org/jira/browse/LOG4J2-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1814: External issue URL: https://gist.github.com/sdwsk/47b86d243023b1583d340889a89639f6 > Wrapper Generate$ExtendedLogger name inconvenient on Linux > --- > > Key: LOG4J2-1814 > URL: https://issues.apache.org/jira/browse/LOG4J2-1814 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Remko Popma >Assignee: Remko Popma > > The $ExtendedLogger is interpreted as an environment variable. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1814) Wrapper Generate$ExtendedLogger name inconvenient on Linux
Remko Popma created LOG4J2-1814: --- Summary: Wrapper Generate$ExtendedLogger name inconvenient on Linux Key: LOG4J2-1814 URL: https://issues.apache.org/jira/browse/LOG4J2-1814 Project: Log4j 2 Issue Type: Improvement Reporter: Remko Popma Assignee: Remko Popma The $ExtendedLogger is interpreted as an environment variable. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1808) java.lang.NoSuchMethodError: org.apache.logging.log4j.ThreadContext.getThreadContextMap()
[
https://issues.apache.org/jira/browse/LOG4J2-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15863818#comment-15863818
]
Remko Popma commented on LOG4J2-1808:
-
Glad to hear that.
> java.lang.NoSuchMethodError:
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()
> -
>
> Key: LOG4J2-1808
> URL: https://issues.apache.org/jira/browse/LOG4J2-1808
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.8
> Environment: Google AppEngine local development server
>Reporter: Lukasz Lenart
>
> {noformat}
> [INFO] Feb 04, 2017 4:38:37 PM com.google.apphosting.utils.jetty.JettyLogger
> warn
> [INFO] WARNING: failed
> com.google.appengine.tools.development.DevAppEngineWebAppContext@454577f3{/,/Users/lukaszlenart/Projects/Private/gruuf-webapp/target/gruuf-webapp-1.0-SNAPSHOT}:
> java.lang.NoSuchMethodError:
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()Lorg/apache/logging/log4j/spi/ReadOnlyThreadContextMap;
> [INFO] Feb 04, 2017 4:38:37 PM com.google.apphosting.utils.jetty.JettyLogger
> warn
> [INFO] WARNING: failed JettyContainerService$ApiProxyHandler@53c6160c:
> java.lang.NoSuchMethodError:
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()Lorg/apache/logging/log4j/spi/ReadOnlyThreadContextMap;
> [INFO] Feb 04, 2017 4:38:37 PM com.google.apphosting.utils.jetty.JettyLogger
> warn
> [INFO] WARNING: Error starting handlers
> [INFO] java.lang.NoSuchMethodError:
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()Lorg/apache/logging/log4j/spi/ReadOnlyThreadContextMap;
> [INFO]at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createDefaultInjector(ContextDataInjectorFactory.java:83)
> [INFO]at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createInjector(ContextDataInjectorFactory.java:67)
> [INFO]at
> org.apache.logging.log4j.core.lookup.ContextMapLookup.(ContextMapLookup.java:34)
> [INFO]at
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:117)
> [INFO]at
> org.apache.logging.log4j.core.config.AbstractConfiguration.(AbstractConfiguration.java:125)
> [INFO]at
> org.apache.logging.log4j.core.config.NullConfiguration.(NullConfiguration.java:32)
> [INFO]at
> org.apache.logging.log4j.core.LoggerContext.(LoggerContext.java:77)
> [INFO]at
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.createContext(ClassLoaderContextSelector.java:171)
> [INFO]at
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoaderContextSelector.java:145)
> [INFO]at
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:70)
> [INFO]at
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:57)
> [INFO]at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:147)
> [INFO]at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> [INFO]at
> org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> [INFO]at
> org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
> [INFO]at
> org.apache.struts2.tiles.StrutsTilesListener.(StrutsTilesListener.java:34)
> [INFO]at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> [INFO]at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> [INFO]at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [INFO]at
> java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> [INFO]at java.lang.Class.newInstance(Class.java:383)
> [INFO]at
> org.mortbay.jetty.webapp.WebXmlConfiguration.newListenerInstance(WebXmlConfiguration.java:650)
> [INFO]at
> org.mortbay.jetty.webapp.WebXmlConfiguration.initListener(WebXmlConfiguration.java:631)
> [INFO]at
> org.mortbay.jetty.webapp.WebXmlConfiguration.initWebXmlElement(WebXmlConfiguration.java:368)
> [INFO]at
> org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:289)
> [INFO]at
> org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:222)
> [INFO]at
> org.mortbay.jetty.webapp.WebXmlConfiguration.configureWebApp(WebXmlConfiguration.java:180)
> [INFO]at
> org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1247)
> [INFO]at
> org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
>
[jira] [Commented] (LOG4J2-1813) Provide shorter and more intuitive way to switch on Log4j internal debug logging
[
https://issues.apache.org/jira/browse/LOG4J2-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15863065#comment-15863065
]
Remko Popma commented on LOG4J2-1813:
-
That is certainly an improvement and I like the initiative.
I would like to give the {{-Dlog4j2.debug}} switch special treatment: note that
no value is required, just specifying the property is the equivalent of
{{-Dlog4j2.simplelog.StatusLogger.level=TRACE}}, plus it should persist even if
the configuration file has a different value in its {{status}} attribute.
> Provide shorter and more intuitive way to switch on Log4j internal debug
> logging
>
>
> Key: LOG4J2-1813
> URL: https://issues.apache.org/jira/browse/LOG4J2-1813
> Project: Log4j 2
> Issue Type: Improvement
> Components: Configurators
>Affects Versions: 2.8
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> People find it difficult to troubleshoot Log4j 2 configuration issues. Many
> people don't know what the "status" attribute is for at the beginning of the
> configuration:
> {code}
> ...
> {code}
> In addition, the above setting does not take effect until the configuration
> file is found. If users have trouble making Log4j 2 find their configuration
> file, the above does not help.
> In such cases, users can enable internal status logging by setting system
> property {{org.apache.logging.log4j.simplelog.StatusLogger.level}} to
> {{TRACE}}.
> This is problematic because:
> * It is not well-known (documented in the FAQ and on the configuration page
> but many people don't know about this feature)
> * The name is a bit... lengthy :-)
> * Apparently people don't intuitively grasp that "status logging" means the
> internal log4j 2 debug logging facility.
> * It is confusing that there are two phases (before config file found and
> after), and the status logger level can be different and needs to be
> specified separately
> I propose we add a short, intuitive system property that results in _all_
> internal Log4j 2 status logging to be printed to the console. When set, this
> property should even override the configuration status attribute in my
> opinion.
> Something like {{-Dlog4j2.debug}} (without even requiring a value) would be
> good, but I'm open to any suggestions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1811) Log4j 2 configuration/usage ergonomics
[ https://issues.apache.org/jira/browse/LOG4J2-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15862663#comment-15862663 ] Remko Popma edited comment on LOG4J2-1811 at 2/12/17 6:00 AM: -- I agree the documentation is very good and certainly thorough. On the other hand, I have seen comments on StackOverflow indicating that for some users the sheer volume of documentation is a bit intimidating and makes it potentially harder to find what they are looking for. What I have in mind for this ticket is to make small "nudges", changes that make Log4j 2 more intuitive to use and configure. Hopefully that makes documentation less necessary. was (Author: rem...@yahoo.com): I agree our documentation is very good and certainly thorough. On the other hand, I have seen comments on StackOverflow indicating that for some users the sheer volume of documentation is a bit intimidating and makes it potentially harder to find what they are looking for. What I have in mind for this ticket is to make small "nudges", changes that make Log4j 2 more intuitive to use and configure. Hopefully that makes documentation less necessary. > Log4j 2 configuration/usage ergonomics > -- > > Key: LOG4J2-1811 > URL: https://issues.apache.org/jira/browse/LOG4J2-1811 > Project: Log4j 2 > Issue Type: Epic > Components: Configurators, Core >Reporter: Remko Popma > > The vast majority of StackOverflow Log4j 2 questions is related to > configuration. The Log4j 2 site offers an extensive manual but apparently > many questions remain. > This ticket aims to make Log4j 2 easier to configure and use. This can take > many forms: > * adding documentation > * making documentation easier to find > * detecting and addressing inconsistencies > * facilitating debugging > * showing richer error messages that help users diagnose problems > * ... etc > I am making this an epic so the effort can span multiple releases and include > many big or small changes. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1811) Log4j 2 configuration/usage ergonomics
[ https://issues.apache.org/jira/browse/LOG4J2-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15862663#comment-15862663 ] Remko Popma commented on LOG4J2-1811: - I agree our documentation is very good and certainly thorough. On the other hand, I have seen comments on StackOverflow indicating that for some users the sheer volume of documentation is a bit intimidating and makes it potentially harder to find what they are looking for. What I have in mind for this ticket is to make small "nudges", changes that make Log4j 2 more intuitive to use and configure. Hopefully that makes documentation less necessary. > Log4j 2 configuration/usage ergonomics > -- > > Key: LOG4J2-1811 > URL: https://issues.apache.org/jira/browse/LOG4J2-1811 > Project: Log4j 2 > Issue Type: Epic > Components: Configurators, Core >Reporter: Remko Popma > > The vast majority of StackOverflow Log4j 2 questions is related to > configuration. The Log4j 2 site offers an extensive manual but apparently > many questions remain. > This ticket aims to make Log4j 2 easier to configure and use. This can take > many forms: > * adding documentation > * making documentation easier to find > * detecting and addressing inconsistencies > * facilitating debugging > * showing richer error messages that help users diagnose problems > * ... etc > I am making this an epic so the effort can span multiple releases and include > many big or small changes. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1813) Provide shorter and more intuitive way to switch on Log4j internal debug logging
[
https://issues.apache.org/jira/browse/LOG4J2-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1813:
Description:
People find it difficult to troubleshoot Log4j 2 configuration issues. Many
people don't know what the "status" attribute is for at the beginning of the
configuration:
{code}
...
{code}
In addition, the above setting does not take effect until the configuration
file is found. If users have trouble making Log4j 2 find their configuration
file, the above does not help.
In such cases, users can enable internal status logging by setting system
property {{org.apache.logging.log4j.simplelog.StatusLogger.level}} to {{TRACE}}.
This is problematic because:
* It is not well-known (documented in the FAQ and on the configuration page but
many people don't know about this feature)
* The name is a bit... lengthy :-)
* Apparently people don't intuitively grasp that "status logging" means the
internal log4j 2 debug logging facility.
* It is confusing that there are two phases (before config file found and
after), and the status logger level can be different and needs to be specified
separately
I propose we add a short, intuitive system property that results in _all_
internal Log4j 2 status logging to be printed to the console. When set, this
property should even override the configuration status attribute in my opinion.
Something like {{-Dlog4j2.debug}} (without even requiring a value) would be
good, but I'm open to any suggestions.
was:
People find it difficult to troubleshoot Log4j 2 configuration issues. Many
people don't know what the "status" attribute is for at the beginning of the
configuration:
{code}
...
{code}
In addition, the above setting does not take effect until the configuration
file is found. If users have trouble making Log4j 2 find their configuration
file, the above does not help.
In such cases, users can enable internal status logging by setting system
property {{org.apache.logging.log4j.simplelog.StatusLogger.level}} to {{TRACE}}.
This is problematic because:
* It is not well-known (documented in the FAQ and on the configuration page but
many people don't know about this feature)
* The name is a bit... lengthy :-)
* Apparently people don't intuitively grasp that "status logging" means the
internal log4j 2 debug logging facility.
* It is confusing that there are two phases (before config file found and
after), and the status logger level can be different and needs to be specified
separately
I propose we add a short, intuitive system property that results in _all_
internal Log4j 2 status logging to be printed to the console. When set, this
property should even override the configuration status attribute in my opinion.
Something like {{-Dlog4j2.debug}} would be good, but I'm open to any
suggestions.
> Provide shorter and more intuitive way to switch on Log4j internal debug
> logging
>
>
> Key: LOG4J2-1813
> URL: https://issues.apache.org/jira/browse/LOG4J2-1813
> Project: Log4j 2
> Issue Type: Improvement
> Components: Configurators
>Affects Versions: 2.8
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> People find it difficult to troubleshoot Log4j 2 configuration issues. Many
> people don't know what the "status" attribute is for at the beginning of the
> configuration:
> {code}
> ...
> {code}
> In addition, the above setting does not take effect until the configuration
> file is found. If users have trouble making Log4j 2 find their configuration
> file, the above does not help.
> In such cases, users can enable internal status logging by setting system
> property {{org.apache.logging.log4j.simplelog.StatusLogger.level}} to
> {{TRACE}}.
> This is problematic because:
> * It is not well-known (documented in the FAQ and on the configuration page
> but many people don't know about this feature)
> * The name is a bit... lengthy :-)
> * Apparently people don't intuitively grasp that "status logging" means the
> internal log4j 2 debug logging facility.
> * It is confusing that there are two phases (before config file found and
> after), and the status logger level can be different and needs to be
> specified separately
> I propose we add a short, intuitive system property that results in _all_
> internal Log4j 2 status logging to be printed to the console. When set, this
> property should even override the configuration status attribute in my
> opinion.
> Something like {{-Dlog4j2.debug}} (without even requiring a value) would be
> good, but I'm open to any suggestions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail:
[jira] [Created] (LOG4J2-1813) Provide shorter and more intuitive way to switch on Log4j internal debug logging
Remko Popma created LOG4J2-1813:
---
Summary: Provide shorter and more intuitive way to switch on Log4j
internal debug logging
Key: LOG4J2-1813
URL: https://issues.apache.org/jira/browse/LOG4J2-1813
Project: Log4j 2
Issue Type: Improvement
Components: Configurators
Affects Versions: 2.8
Reporter: Remko Popma
Assignee: Remko Popma
Fix For: 2.8.1
People find it difficult to troubleshoot Log4j 2 configuration issues. Many
people don't know what the "status" attribute is for at the beginning of the
configuration:
{code}
...
{code}
In addition, the above setting does not take effect until the configuration
file is found. If users have trouble making Log4j 2 find their configuration
file, the above does not help.
In such cases, users can enable internal status logging by setting system
property {{org.apache.logging.log4j.simplelog.StatusLogger.level}} to {{TRACE}}.
This is problematic because:
* It is not well-known (documented in the FAQ and on the configuration page but
many people don't know about this feature)
* The name is a bit... lengthy :-)
* Apparently people don't intuitively grasp that "status logging" means the
internal log4j 2 debug logging facility.
* It is confusing that there are two phases (before config file found and
after), and the status logger level can be different and needs to be specified
separately
I propose we add a short, intuitive system property that results in _all_
internal Log4j 2 status logging to be printed to the console. When set, this
property should even override the configuration status attribute in my opinion.
Something like {{-Dlog4j2.debug}} would be good, but I'm open to any
suggestions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1812) Improve error message when log4j 2 configuration file not found
[
https://issues.apache.org/jira/browse/LOG4J2-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1812:
Description:
When configuration fails because no Log4j 2 configuration file is found, the
following message is logged to the console at ERROR level:
{code}
No log4j2 configuration file found. Using default configuration: logging only
errors to the console.
{code}
We should be able to improve this. One idea is to add this:
{code}
No log4j2 configuration file found. Using default configuration: logging only
errors to the console. Set system property
'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show Log4j2
internal initialization logging.
{code}
Another idea is to dump the contents of the StatusLogger ring buffer to the
console.
was:
When configuration fails because no Log4j 2 configuration file is found, the
following message is logged to the console at ERROR level:
{code}
No log4j2 configuration file found. Using default configuration: logging only
errors to the console.
{code}
We should be able to improve this. One idea is to add this:
{code}
No log4j2 configuration file found. Using default configuration: logging only
errors to the console. Set system property
'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show Log4j2
initialization internal logging.
{code}
Another idea is to dump the contents of the StatusLogger ring buffer to the
console.
> Improve error message when log4j 2 configuration file not found
> ---
>
> Key: LOG4J2-1812
> URL: https://issues.apache.org/jira/browse/LOG4J2-1812
> Project: Log4j 2
> Issue Type: Improvement
> Components: Configurators
>Affects Versions: 2.3, 2.4, 2.5, 2.6, 2.7, 2.8
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> When configuration fails because no Log4j 2 configuration file is found, the
> following message is logged to the console at ERROR level:
> {code}
> No log4j2 configuration file found. Using default configuration: logging only
> errors to the console.
> {code}
> We should be able to improve this. One idea is to add this:
> {code}
> No log4j2 configuration file found. Using default configuration: logging only
> errors to the console. Set system property
> 'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show
> Log4j2 internal initialization logging.
> {code}
> Another idea is to dump the contents of the StatusLogger ring buffer to the
> console.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1812) Improve error message when log4j 2 configuration file not found
[
https://issues.apache.org/jira/browse/LOG4J2-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15862652#comment-15862652
]
Remko Popma commented on LOG4J2-1812:
-
Added above text to the error message in commit 2467ef5.
Please let me know what people think of the idea to dump the StatusLogger ring
buffer.
> Improve error message when log4j 2 configuration file not found
> ---
>
> Key: LOG4J2-1812
> URL: https://issues.apache.org/jira/browse/LOG4J2-1812
> Project: Log4j 2
> Issue Type: Improvement
> Components: Configurators
>Affects Versions: 2.3, 2.4, 2.5, 2.6, 2.7, 2.8
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> When configuration fails because no Log4j 2 configuration file is found, the
> following message is logged to the console at ERROR level:
> {code}
> No log4j2 configuration file found. Using default configuration: logging only
> errors to the console.
> {code}
> We should be able to improve this. One idea is to add this:
> {code}
> No log4j2 configuration file found. Using default configuration: logging only
> errors to the console. Set system property
> 'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show
> Log4j2 initialization internal logging.
> {code}
> Another idea is to dump the contents of the StatusLogger ring buffer to the
> console.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1812) Improve error message when log4j 2 configuration file not found
Remko Popma created LOG4J2-1812:
---
Summary: Improve error message when log4j 2 configuration file not
found
Key: LOG4J2-1812
URL: https://issues.apache.org/jira/browse/LOG4J2-1812
Project: Log4j 2
Issue Type: Improvement
Components: Configurators
Affects Versions: 2.8, 2.7, 2.6, 2.5, 2.4, 2.3
Reporter: Remko Popma
Assignee: Remko Popma
Fix For: 2.8.1
When configuration fails because no Log4j 2 configuration file is found, the
following message is logged to the console at ERROR level:
{code}
No log4j2 configuration file found. Using default configuration: logging only
errors to the console.
{code}
We should be able to improve this. One idea is to add this:
{code}
No log4j2 configuration file found. Using default configuration: logging only
errors to the console. Set system property
'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show Log4j2
initialization internal logging.
{code}
Another idea is to dump the contents of the StatusLogger ring buffer to the
console.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1811) Log4j 2 configuration/usage ergonomics
Remko Popma created LOG4J2-1811: --- Summary: Log4j 2 configuration/usage ergonomics Key: LOG4J2-1811 URL: https://issues.apache.org/jira/browse/LOG4J2-1811 Project: Log4j 2 Issue Type: Epic Components: Configurators, Core Reporter: Remko Popma The vast majority of StackOverflow Log4j 2 questions is related to configuration. The Log4j 2 site offers an extensive manual but apparently many questions remain. This ticket aims to make Log4j 2 easier to configure and use. This can take many forms: * adding documentation * making documentation easier to find * detecting and addressing inconsistencies * facilitating debugging * showing richer error messages that help users diagnose problems * ... etc I am making this an epic so the effort can span multiple releases and include many big or small changes. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1678) (GC) Avoid allocating temporary objects in ThreadContextMapFilter
[ https://issues.apache.org/jira/browse/LOG4J2-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15861335#comment-15861335 ] Remko Popma commented on LOG4J2-1678: - Can you provide details on why you think there's a problem? > (GC) Avoid allocating temporary objects in ThreadContextMapFilter > - > > Key: LOG4J2-1678 > URL: https://issues.apache.org/jira/browse/LOG4J2-1678 > Project: Log4j 2 > Issue Type: Improvement > Components: Filters >Affects Versions: 2.7 >Reporter: Remko Popma >Assignee: Remko Popma > Fix For: 2.8 > > > Make ThreadContextMapFilter garbage-free. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1809) Add global configuration environment SPI
[ https://issues.apache.org/jira/browse/LOG4J2-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853416#comment-15853416 ] Remko Popma commented on LOG4J2-1809: - Where will this interface be used? Inside PropertiesUtil? > Add global configuration environment SPI > > > Key: LOG4J2-1809 > URL: https://issues.apache.org/jira/browse/LOG4J2-1809 > Project: Log4j 2 > Issue Type: New Feature > Components: API >Reporter: Matt Sicker >Assignee: Matt Sicker > > Create a service provider interface for global configuration property > sources. Currently, we support two built in sources: properties loaded from a > classpath resource file named "log4j2.component.properties" and from system > properties. This feature will abstract those two sources into an SPI with > default implementations of those two sources as well as environment variables. > This SPI should be specified through the standard > [ServiceLoader|https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html] > API so as to make this simpler to support for users in any environment. > Related to LOG4J2-1431. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1808) java.lang.NoSuchMethodError: org.apache.logging.log4j.ThreadContext.getThreadContextMap()
[
https://issues.apache.org/jira/browse/LOG4J2-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853001#comment-15853001
]
Remko Popma commented on LOG4J2-1808:
-
The method {{ThreadContext.getThreadContextMap()}} was added in 2.8. The only
way I can imagine this error would happen is that an older version of the
log4j-api module (say, log4j-api-2.7.jar) is also on the classpath, and it is
loaded _before_ the log4j-api-2.8.jar.
Can you verify the full classpath of the application? Alternatively, to verify
which jar file the class is loaded from, you can do:
{code}
System.out.println("ThreadContext from: " + ThreadContext.class.getResource("/"
+ ThreadContext.class.getName().replace('.', '/') + ".class"));
{code}
> java.lang.NoSuchMethodError:
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()
> -
>
> Key: LOG4J2-1808
> URL: https://issues.apache.org/jira/browse/LOG4J2-1808
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.8
> Environment: Google AppEngine local development server
>Reporter: Lukasz Lenart
>
> {noformat}
> [INFO] Feb 04, 2017 4:38:37 PM com.google.apphosting.utils.jetty.JettyLogger
> warn
> [INFO] WARNING: failed
> com.google.appengine.tools.development.DevAppEngineWebAppContext@454577f3{/,/Users/lukaszlenart/Projects/Private/gruuf-webapp/target/gruuf-webapp-1.0-SNAPSHOT}:
> java.lang.NoSuchMethodError:
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()Lorg/apache/logging/log4j/spi/ReadOnlyThreadContextMap;
> [INFO] Feb 04, 2017 4:38:37 PM com.google.apphosting.utils.jetty.JettyLogger
> warn
> [INFO] WARNING: failed JettyContainerService$ApiProxyHandler@53c6160c:
> java.lang.NoSuchMethodError:
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()Lorg/apache/logging/log4j/spi/ReadOnlyThreadContextMap;
> [INFO] Feb 04, 2017 4:38:37 PM com.google.apphosting.utils.jetty.JettyLogger
> warn
> [INFO] WARNING: Error starting handlers
> [INFO] java.lang.NoSuchMethodError:
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()Lorg/apache/logging/log4j/spi/ReadOnlyThreadContextMap;
> [INFO]at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createDefaultInjector(ContextDataInjectorFactory.java:83)
> [INFO]at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createInjector(ContextDataInjectorFactory.java:67)
> [INFO]at
> org.apache.logging.log4j.core.lookup.ContextMapLookup.(ContextMapLookup.java:34)
> [INFO]at
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:117)
> [INFO]at
> org.apache.logging.log4j.core.config.AbstractConfiguration.(AbstractConfiguration.java:125)
> [INFO]at
> org.apache.logging.log4j.core.config.NullConfiguration.(NullConfiguration.java:32)
> [INFO]at
> org.apache.logging.log4j.core.LoggerContext.(LoggerContext.java:77)
> [INFO]at
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.createContext(ClassLoaderContextSelector.java:171)
> [INFO]at
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoaderContextSelector.java:145)
> [INFO]at
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:70)
> [INFO]at
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:57)
> [INFO]at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:147)
> [INFO]at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> [INFO]at
> org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> [INFO]at
> org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
> [INFO]at
> org.apache.struts2.tiles.StrutsTilesListener.(StrutsTilesListener.java:34)
> [INFO]at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> [INFO]at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> [INFO]at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [INFO]at
> java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> [INFO]at java.lang.Class.newInstance(Class.java:383)
> [INFO]at
> org.mortbay.jetty.webapp.WebXmlConfiguration.newListenerInstance(WebXmlConfiguration.java:650)
> [INFO]at
> org.mortbay.jetty.webapp.WebXmlConfiguration.initListener(WebXmlConfiguration.java:631)
> [INFO]at
>
[jira] [Commented] (LOG4J2-1807) [core] Add and implement LogEvent.asImmutable()
[
https://issues.apache.org/jira/browse/LOG4J2-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15850940#comment-15850940
]
Remko Popma commented on LOG4J2-1807:
-
Yes that should be fine. The LogEvent interface regularly changes when we add
more features.
(Perhaps we should put a javadoc note on that interface to that effect.)
> [core] Add and implement LogEvent.asImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Attachments: logging-log4j2.patch
>
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
> * Returns an immutable version of this log event, which MAY BE a copy of
> this event.
> *
> * @return an immutable version of this log event
> */
> LogEvent asImmutable();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1807) [core] Add and implement LogEvent.asImmutable()
[
https://issues.apache.org/jira/browse/LOG4J2-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15850768#comment-15850768
]
Remko Popma commented on LOG4J2-1807:
-
Should it be {{toImmutable}} since the convention is that {{asSomething}}
provides a "something" _view_ that changes when the underlying value is
changed, whereas {{toSomething}} transforms an object into something
independent from the original value?
> [core] Add and implement LogEvent.asImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
> * Returns an immutable version of this log event, which MAY BE a copy of
> this event.
> *
> * @return an immutable version of this log event
> */
> LogEvent asImmutable();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1806) Fix javadoc for DefaultRolloverStrategy::purgeAscending
[ https://issues.apache.org/jira/browse/LOG4J2-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed LOG4J2-1806. --- Resolution: Fixed Fixed in master in commit 12f91eb. > Fix javadoc for DefaultRolloverStrategy::purgeAscending > --- > > Key: LOG4J2-1806 > URL: https://issues.apache.org/jira/browse/LOG4J2-1806 > Project: Log4j 2 > Issue Type: Bug > Components: Documentation >Reporter: Remko Popma >Assignee: Remko Popma > Fix For: 2.8.1 > > > See https://github.com/apache/logging-log4j2/pull/41 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1806) Fix javadoc for DefaultRolloverStrategy::purgeAscending
Remko Popma created LOG4J2-1806: --- Summary: Fix javadoc for DefaultRolloverStrategy::purgeAscending Key: LOG4J2-1806 URL: https://issues.apache.org/jira/browse/LOG4J2-1806 Project: Log4j 2 Issue Type: Bug Components: Documentation Reporter: Remko Popma Assignee: Remko Popma Fix For: 2.8.1 See https://github.com/apache/logging-log4j2/pull/41 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-1799) Error determining the current charset
[
https://issues.apache.org/jira/browse/LOG4J2-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved LOG4J2-1799.
-
Resolution: Fixed
Fix Version/s: 2.8.1
Fixed in master. Please verify and close.
> Error determining the current charset
> -
>
> Key: LOG4J2-1799
> URL: https://issues.apache.org/jira/browse/LOG4J2-1799
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vadim Lotarev
>Assignee: Remko Popma
>Priority: Blocker
> Fix For: 2.8.1
>
>
> Switching to the latest release I've immediately got the following error:
> {code}
> Unable to inject fields into builder class for plugin type class
> org.apache.logging.log4j.core.appender.ConsoleAppender, element Consol
> e. java.nio.charset.UnsupportedCharsetException: sun.stdout.encoding
> {code}
> In the PropertiesUtil I see the following:
> {code:java}
> public Charset getCharsetProperty(final String name, final Charset
> defaultValue) {
> final String prop = getStringProperty(name);
> return prop == null ? defaultValue : Charset.forName(name);
> }
> {code}
> Shouldn't {{prop}} be used in {{Charset.forName(name)}} instead of {{name}}?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-1799) Error determining the current charset
[
https://issues.apache.org/jira/browse/LOG4J2-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma reassigned LOG4J2-1799:
---
Assignee: Remko Popma
> Error determining the current charset
> -
>
> Key: LOG4J2-1799
> URL: https://issues.apache.org/jira/browse/LOG4J2-1799
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vadim Lotarev
>Assignee: Remko Popma
>Priority: Blocker
>
> Switching to the latest release I've immediately got the following error:
> {code}
> Unable to inject fields into builder class for plugin type class
> org.apache.logging.log4j.core.appender.ConsoleAppender, element Consol
> e. java.nio.charset.UnsupportedCharsetException: sun.stdout.encoding
> {code}
> In the PropertiesUtil I see the following:
> {code:java}
> public Charset getCharsetProperty(final String name, final Charset
> defaultValue) {
> final String prop = getStringProperty(name);
> return prop == null ? defaultValue : Charset.forName(name);
> }
> {code}
> Shouldn't {{prop}} be used in {{Charset.forName(name)}} instead of {{name}}?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1805) FixedDateFormat improvements
[
https://issues.apache.org/jira/browse/LOG4J2-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma closed LOG4J2-1805.
---
Resolution: Fixed
Fixed in master in commit d52ce48.
> FixedDateFormat improvements
>
>
> Key: LOG4J2-1805
> URL: https://issues.apache.org/jira/browse/LOG4J2-1805
> Project: Log4j 2
> Issue Type: Improvement
> Components: Pattern Converters
>Affects Versions: 2.6
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> *Proposed changes:*
> * improve thread-safety of {{FixedDateFormat::updateMidnightMillis}}
> * expose {{FixedDateFormat::millisSinceMidnight}} as a public method
> In multi-threaded scenarios where time does not move forward monotonically,
> the implementation of {{FixedDateFormat::updateMidnightMillis}} can result in
> corrupted time stamps. In a project I am involved in we have a custom
> PatternConverter that uses FixedDateFormat to format the "event time". In
> these (artificial) tests, event time does not always move forward, so the
> {{updateMidnightMillis}} is called concurrently with varying values. This is
> not a production issue, but the implementation can be improved to be
> thread-safe without impacting performance by using double-checked locking.
> Making {{FixedDateFormat::millisSinceMidnight}} public would provide a
> performant and convenient way to strip off the date component. Useful for
> systems that are on Java 7 or for systems on Java 8 that don't want to
> construct a {{LocalTime}} object every time this value is required.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1803) JMH generated benchmark classes not included in jar
[
https://issues.apache.org/jira/browse/LOG4J2-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma closed LOG4J2-1803.
---
Resolution: Fixed
Fix Version/s: 2.8.1
I confirmed Ralph's fix works, closing the issue. Thanks, Ralph!
> JMH generated benchmark classes not included in jar
> ---
>
> Key: LOG4J2-1803
> URL: https://issues.apache.org/jira/browse/LOG4J2-1803
> Project: Log4j 2
> Issue Type: Bug
> Components: Core, Performance Benchmarks
>Affects Versions: 2.8
>Reporter: Remko Popma
>Assignee: Ralph Goers
> Fix For: 2.8.1
>
>
> Some time after the 2.7 release, the JMH benchmarks stopped working. When
> trying to execute them, this error occurs:
> {code}
> java.lang.IllegalArgumentException: Benchmark does not match a class
> at org.openjdk.jmh.util.ClassUtils.loadClass(ClassUtils.java:90)
> at org.openjdk.jmh.runner.BaseRunner.runBenchmark(BaseRunner.java:198)
> at org.openjdk.jmh.runner.BaseRunner.runBenchmarks(BaseRunner.java:95)
> at org.openjdk.jmh.runner.ForkedRunner.run(ForkedRunner.java:51)
> at org.openjdk.jmh.runner.ForkedMain.main(ForkedMain.java:68)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.logging.log4j.perf.jmh.generated.FileAppenderBenchmark_julFile
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:195)
> at org.openjdk.jmh.util.ClassUtils.loadClass(ClassUtils.java:72)
> ... 4 more
> {code}
> When I build the project, the classes generated by JMH under
> log4j-perf/target/generated-sources/annotations are not included in the
> shaded benchmarks.jar or in log4j-perf-2.8.1-SNAPSHOT.jar...
> The cause seems to be a change in the master pom:
> the {{maven-compiler-plugin}} plugin now has the below section which was not
> there in 2.7.
> If I take it out and build only log4j-perf, the benchmarks run without error.
> (But building all modules fails: some problem in log4j-core...)
> {code}
>
>
>
> default-compile
>
> compile
>
> compile
>
> none
>
>
>
>
> process-plugins
>
> compile
>
> process-classes
>
> only
>
>
>
> {code}
> From the log4j-dev mailing list:
> {quote}
> That maven-compiler-plugin config was originally only included in log4j-core
> in order to allow the PluginProcessor annotation processor to re-run against
> log4j-core without needing to split it into its own jar. I'm not sure why
> it's configured for everything now.
> {quote}
> Potentially related: somebody reported on StackOverflow that [their custom
> plugin no longer loads with
> 2.8|http://stackoverflow.com/questions/41938128/log4j-2-8-cannot-load-custom-converters-in-osgi-environment].
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-1803) JMH generated benchmark classes not included in jar
[
https://issues.apache.org/jira/browse/LOG4J2-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma reassigned LOG4J2-1803:
---
Assignee: Ralph Goers
> JMH generated benchmark classes not included in jar
> ---
>
> Key: LOG4J2-1803
> URL: https://issues.apache.org/jira/browse/LOG4J2-1803
> Project: Log4j 2
> Issue Type: Bug
> Components: Core, Performance Benchmarks
>Affects Versions: 2.8
>Reporter: Remko Popma
>Assignee: Ralph Goers
>
> Some time after the 2.7 release, the JMH benchmarks stopped working. When
> trying to execute them, this error occurs:
> {code}
> java.lang.IllegalArgumentException: Benchmark does not match a class
> at org.openjdk.jmh.util.ClassUtils.loadClass(ClassUtils.java:90)
> at org.openjdk.jmh.runner.BaseRunner.runBenchmark(BaseRunner.java:198)
> at org.openjdk.jmh.runner.BaseRunner.runBenchmarks(BaseRunner.java:95)
> at org.openjdk.jmh.runner.ForkedRunner.run(ForkedRunner.java:51)
> at org.openjdk.jmh.runner.ForkedMain.main(ForkedMain.java:68)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.logging.log4j.perf.jmh.generated.FileAppenderBenchmark_julFile
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:195)
> at org.openjdk.jmh.util.ClassUtils.loadClass(ClassUtils.java:72)
> ... 4 more
> {code}
> When I build the project, the classes generated by JMH under
> log4j-perf/target/generated-sources/annotations are not included in the
> shaded benchmarks.jar or in log4j-perf-2.8.1-SNAPSHOT.jar...
> The cause seems to be a change in the master pom:
> the {{maven-compiler-plugin}} plugin now has the below section which was not
> there in 2.7.
> If I take it out and build only log4j-perf, the benchmarks run without error.
> (But building all modules fails: some problem in log4j-core...)
> {code}
>
>
>
> default-compile
>
> compile
>
> compile
>
> none
>
>
>
>
> process-plugins
>
> compile
>
> process-classes
>
> only
>
>
>
> {code}
> From the log4j-dev mailing list:
> {quote}
> That maven-compiler-plugin config was originally only included in log4j-core
> in order to allow the PluginProcessor annotation processor to re-run against
> log4j-core without needing to split it into its own jar. I'm not sure why
> it's configured for everything now.
> {quote}
> Potentially related: somebody reported on StackOverflow that [their custom
> plugin no longer loads with
> 2.8|http://stackoverflow.com/questions/41938128/log4j-2-8-cannot-load-custom-converters-in-osgi-environment].
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1805) FixedDateFormat improvements
[
https://issues.apache.org/jira/browse/LOG4J2-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15849569#comment-15849569
]
Remko Popma commented on LOG4J2-1805:
-
They're not: this is about the FixedDateFormat, not about the commons-lang
FastDateFormat.
FixedDateFormat is our custom high performance and garbage free formatter for
the fixed formats we have names for in the docs for the %d converter. The
commons-lang stuff is called FastDateFormat and is used for any format that
doesn't match the predefined fixed formats.
The names can get a bit confusing, I agree.
> FixedDateFormat improvements
>
>
> Key: LOG4J2-1805
> URL: https://issues.apache.org/jira/browse/LOG4J2-1805
> Project: Log4j 2
> Issue Type: Improvement
> Components: Pattern Converters
>Affects Versions: 2.6
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> *Proposed changes:*
> * improve thread-safety of {{FixedDateFormat::updateMidnightMillis}}
> * expose {{FixedDateFormat::millisSinceMidnight}} as a public method
> In multi-threaded scenarios where time does not move forward monotonically,
> the implementation of {{FixedDateFormat::updateMidnightMillis}} can result in
> corrupted time stamps. In a project I am involved in we have a custom
> PatternConverter that uses FixedDateFormat to format the "event time". In
> these (artificial) tests, event time does not always move forward, so the
> {{updateMidnightMillis}} is called concurrently with varying values. This is
> not a production issue, but the implementation can be improved to be
> thread-safe without impacting performance by using double-checked locking.
> Making {{FixedDateFormat::millisSinceMidnight}} public would provide a
> performant and convenient way to strip off the date component. Useful for
> systems that are on Java 7 or for systems on Java 8 that don't want to
> construct a {{LocalTime}} object every time this value is required.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1805) FixedDateFormat improvements
Remko Popma created LOG4J2-1805:
---
Summary: FixedDateFormat improvements
Key: LOG4J2-1805
URL: https://issues.apache.org/jira/browse/LOG4J2-1805
Project: Log4j 2
Issue Type: Improvement
Components: Pattern Converters
Affects Versions: 2.6
Reporter: Remko Popma
Assignee: Remko Popma
Fix For: 2.8.1
*Proposed changes:*
* improve thread-safety of {{FixedDateFormat::updateMidnightMillis}}
* expose {{FixedDateFormat::millisSinceMidnight}} as a public method
In multi-threaded scenarios where time does not move forward monotonically, the
implementation of {{FixedDateFormat::updateMidnightMillis}} can result in
corrupted time stamps. In a project I am involved in we have a custom
PatternConverter that uses FixedDateFormat to format the "event time". In these
(artificial) tests, event time does not always move forward, so the
{{updateMidnightMillis}} is called concurrently with varying values. This is
not a production issue, but the implementation can be improved to be
thread-safe without impacting performance by using double-checked locking.
Making {{FixedDateFormat::millisSinceMidnight}} public would provide a
performant and convenient way to strip off the date component. Useful for
systems that are on Java 7 or for systems on Java 8 that don't want to
construct a {{LocalTime}} object every time this value is required.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1261) Replace usage of deprecated LMAX Disruptor APIs
[
https://issues.apache.org/jira/browse/LOG4J2-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1261:
Affects Version/s: 2.6
> Replace usage of deprecated LMAX Disruptor APIs
> ---
>
> Key: LOG4J2-1261
> URL: https://issues.apache.org/jira/browse/LOG4J2-1261
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.6
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Remko Popma
> Fix For: 2.8.1
>
> Attachments: LOG4J2_1261_changes_to_use_new_Disruptor_API.patch
>
>
> We get the following compiler warning due to our usage for deprecated LMAX
> Disruptor APIs:
> {noformat}
> [WARN]
> E:\vcs\git\apache\logging\logging-log4j2\log4j-core\src\main\java\org\apache\logging\log4j\core\async\AsyncLoggerDisruptor.java:[88,20]
> [deprecation]
> Disruptor(EventFactory,int,Executor,ProducerType,WaitStrategy) in
> Disruptor has been deprecated
> [WARN] where T is a type-variable:
> T extends Object declared in class Disruptor
> E:\vcs\git\apache\logging\logging-log4j2\log4j-core\src\main\java\org\apache\logging\log4j\core\async\AsyncLoggerDisruptor.java:[88,20]
> [deprecation]
> Disruptor(EventFactory,int,Executor,ProducerType,WaitStrategy) in
> Disruptor has been deprecated
> [WARN] where T is a type-variable:
> T extends Object declared in class Disruptor
> E:\vcs\git\apache\logging\logging-log4j2\log4j-core\src\main\java\org\apache\logging\log4j\core\async\AsyncLoggerDisruptor.java:[93,17]
> [deprecation] handleExceptionsWith(ExceptionHandler) in Disruptor
> has been deprecated
> [WARN] where T is a type-variable:
> T extends Object declared in class Disruptor
> E:\vcs\git\apache\logging\logging-log4j2\log4j-core\src\main\java\org\apache\logging\log4j\core\async\AsyncLoggerConfigDisruptor.java:[165,20]
> [deprecation]
> Disruptor(EventFactory,int,Executor,ProducerType,WaitStrategy) in
> Disruptor has been deprecated
> [WARN] where T is a type-variable:
> T extends Object declared in class Disruptor
> E:\vcs\git\apache\logging\logging-log4j2\log4j-core\src\main\java\org\apache\logging\log4j\core\async\AsyncLoggerConfigDisruptor.java:[165,20]
> [deprecation]
> Disruptor(EventFactory,int,Executor,ProducerType,WaitStrategy) in
> Disruptor has been deprecated
> [WARN] where T is a type-variable:
> T extends Object declared in class Disruptor
> E:\vcs\git\apache\logging\logging-log4j2\log4j-core\src\main\java\org\apache\logging\log4j\core\async\AsyncLoggerConfigDisruptor.java:[169,17]
> [deprecation] handleExceptionsWith(ExceptionHandler) in Disruptor
> has been deprecated
> [WARN] where T is a type-variable:
> T extends Object declared in class Disruptor
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1261) Replace usage of deprecated LMAX Disruptor APIs
[
https://issues.apache.org/jira/browse/LOG4J2-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1261:
Fix Version/s: 2.8.1
> Replace usage of deprecated LMAX Disruptor APIs
> ---
>
> Key: LOG4J2-1261
> URL: https://issues.apache.org/jira/browse/LOG4J2-1261
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Remko Popma
> Fix For: 2.8.1
>
> Attachments: LOG4J2_1261_changes_to_use_new_Disruptor_API.patch
>
>
> We get the following compiler warning due to our usage for deprecated LMAX
> Disruptor APIs:
> {noformat}
> [WARN]
> E:\vcs\git\apache\logging\logging-log4j2\log4j-core\src\main\java\org\apache\logging\log4j\core\async\AsyncLoggerDisruptor.java:[88,20]
> [deprecation]
> Disruptor(EventFactory,int,Executor,ProducerType,WaitStrategy) in
> Disruptor has been deprecated
> [WARN] where T is a type-variable:
> T extends Object declared in class Disruptor
> E:\vcs\git\apache\logging\logging-log4j2\log4j-core\src\main\java\org\apache\logging\log4j\core\async\AsyncLoggerDisruptor.java:[88,20]
> [deprecation]
> Disruptor(EventFactory,int,Executor,ProducerType,WaitStrategy) in
> Disruptor has been deprecated
> [WARN] where T is a type-variable:
> T extends Object declared in class Disruptor
> E:\vcs\git\apache\logging\logging-log4j2\log4j-core\src\main\java\org\apache\logging\log4j\core\async\AsyncLoggerDisruptor.java:[93,17]
> [deprecation] handleExceptionsWith(ExceptionHandler) in Disruptor
> has been deprecated
> [WARN] where T is a type-variable:
> T extends Object declared in class Disruptor
> E:\vcs\git\apache\logging\logging-log4j2\log4j-core\src\main\java\org\apache\logging\log4j\core\async\AsyncLoggerConfigDisruptor.java:[165,20]
> [deprecation]
> Disruptor(EventFactory,int,Executor,ProducerType,WaitStrategy) in
> Disruptor has been deprecated
> [WARN] where T is a type-variable:
> T extends Object declared in class Disruptor
> E:\vcs\git\apache\logging\logging-log4j2\log4j-core\src\main\java\org\apache\logging\log4j\core\async\AsyncLoggerConfigDisruptor.java:[165,20]
> [deprecation]
> Disruptor(EventFactory,int,Executor,ProducerType,WaitStrategy) in
> Disruptor has been deprecated
> [WARN] where T is a type-variable:
> T extends Object declared in class Disruptor
> E:\vcs\git\apache\logging\logging-log4j2\log4j-core\src\main\java\org\apache\logging\log4j\core\async\AsyncLoggerConfigDisruptor.java:[169,17]
> [deprecation] handleExceptionsWith(ExceptionHandler) in Disruptor
> has been deprecated
> [WARN] where T is a type-variable:
> T extends Object declared in class Disruptor
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1760) AsyncAppender with LinkedTransferQueue.offer()
[
https://issues.apache.org/jira/browse/LOG4J2-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15849157#comment-15849157
]
Remko Popma edited comment on LOG4J2-1760 at 2/2/17 12:15 AM:
--
Thanks for the clarification. I looked at the code and I agree there is a
problem: in the current code when {{tryTransfer}} fails (because the
background thread is busy with the previous event), the current event will be
delegated to the {{AsyncQueueFullPolicy}}. The default policy bypasses the
queue and appends directly to the underlying appender. Effectively the max
queue size is zero.
This can be improved. As an alternative, when {{tryTransfer}} returns true,
AsyncAppender could inspect the queue size and only delegate to the
AsyncQueueFullPolicy when the size exceeds the configured max, otherwise
enqueue the event with {{offer}}. I need to check the semantics for
LinkedTransferQueue::size, some imprecision is acceptable but performance
impact is not.
Meanwhile, you can work around the issue by configuring the
AsyncQueueFullPolicy to enqueue the event: set system property
{{log4j2.AsyncQueueFullPolicy}} to {{Discard}} and set
{{log4j2.DiscardThreshold}} to a value that doesn't discard any events. (Away
from pc, don't remember if it's ALL or NONE.)
was (Author: rem...@yahoo.com):
Thanks for the clarification. I looked at the code and I agree there is a
problem: in the current code when {{tryTransfer}} fails (because the
background thread is busy with the previous event), the current event will be
delegated to the {{AsyncQueueFullPolicy}}. The default policy bypasses the
queue and appends directly to the underlying appender. Effectively the queue
size is zero.
This can be improved. As an alternative, when {{tryTransfer}} returns true,
AsyncAppender could inspect the queue size and only delegate to the
AsyncQueueFullPolicy when the size exceeds the configured max, otherwise
enqueue the event with {{offer}}. I need to check the semantics for
LinkedTransferQueue::size, some imprecision is acceptable but performance
impact is not.
Meanwhile, you can work around the issue by configuring the
AsyncQueueFullPolicy to enqueue the event: set system property
{{log4j2.AsyncQueueFullPolicy}} to {{Discard}} and set
{{log4j2.DiscardThreshold}} to a value that doesn't discard any events. (Away
from pc, don't remember if it's ALL or NONE.)
> AsyncAppender with LinkedTransferQueue.offer()
> --
>
> Key: LOG4J2-1760
> URL: https://issues.apache.org/jira/browse/LOG4J2-1760
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
>Affects Versions: 2.7
>Reporter: Addison Walterson
>Priority: Minor
>
> I suggest that the AsyncAppender can use a LinkedTransferQueue for which
> offer() is used to enqueue messages because tryTransfer() only succeeds if
> the receiving thread waits for a message which means that the queue has
> length 0.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1760) AsyncAppender with LinkedTransferQueue.offer()
[
https://issues.apache.org/jira/browse/LOG4J2-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15849157#comment-15849157
]
Remko Popma edited comment on LOG4J2-1760 at 2/2/17 12:14 AM:
--
Thanks for the clarification. I looked at the code and I agree there is a
problem: in the current code when {{tryTransfer}} fails (because the
background thread is busy with the previous event), the current event will be
delegated to the {{AsyncQueueFullPolicy}}. The default policy bypasses the
queue and appends directly to the underlying appender. Effectively the queue
size is zero.
This can be improved. As an alternative, when {{tryTransfer}} returns true,
AsyncAppender could inspect the queue size and only delegate to the
AsyncQueueFullPolicy when the size exceeds the configured max, otherwise
enqueue the event with {{offer}}. I need to check the semantics for
LinkedTransferQueue::size, some imprecision is acceptable but performance
impact is not.
Meanwhile, you can work around the issue by configuring the
AsyncQueueFullPolicy to enqueue the event: set system property
{{log4j2.AsyncQueueFullPolicy}} to {{Discard}} and set
{{log4j2.DiscardThreshold}} to a value that doesn't discard any events. (Away
from pc, don't remember if it's ALL or NONE.)
was (Author: rem...@yahoo.com):
Thanks for the clarification. I looked at the code and I agree there is a
problem: in the current code when {{tryTransfer}} fails (because the
background thread is busy with the previous event), the current event will be
delegated to the {{AsyncQueueFullPolicy}}. The default policy bypasses the
queue and appends directly to the underlying appender.
This can be improved. As an alternative, when {{tryTransfer}} returns true,
AsyncAppender could inspect the queue size and only delegate to the
AsyncQueueFullPolicy when the size exceeds the configured max, otherwise
enqueue the event with {{offer}}. I need to check the semantics for
LinkedTransferQueue::size, some imprecision is acceptable but performance
impact is not.
Meanwhile, you can work around the issue by configuring the
AsyncQueueFullPolicy to enqueue the event: set system property
{{log4j2.AsyncQueueFullPolicy}} to {{Discard}} and set
{{log4j2.DiscardThreshold}} to a value that doesn't discard any events. (Away
from pc, don't remember if it's ALL or NONE.)
> AsyncAppender with LinkedTransferQueue.offer()
> --
>
> Key: LOG4J2-1760
> URL: https://issues.apache.org/jira/browse/LOG4J2-1760
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
>Affects Versions: 2.7
>Reporter: Addison Walterson
>Priority: Minor
>
> I suggest that the AsyncAppender can use a LinkedTransferQueue for which
> offer() is used to enqueue messages because tryTransfer() only succeeds if
> the receiving thread waits for a message which means that the queue has
> length 0.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1760) AsyncAppender with LinkedTransferQueue.offer()
[
https://issues.apache.org/jira/browse/LOG4J2-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15849157#comment-15849157
]
Remko Popma commented on LOG4J2-1760:
-
Thanks for the clarification. I looked at the code and I agree there is a
problem: in the current code when {{tryTransfer}} fails (because the
background thread is busy with the previous event), the current event will be
delegated to the {{AsyncQueueFullPolicy}}. The default policy bypasses the
queue and appends directly to the underlying appender.
This can be improved. As an alternative, when {{tryTransfer}} returns true,
AsyncAppender could inspect the queue size and only delegate to the
AsyncQueueFullPolicy when the size exceeds the configured max, otherwise
enqueue the event with {{offer}}. I need to check the semantics for
LinkedTransferQueue::size, some imprecision is acceptable but performance
impact is not.
Meanwhile, you can work around the issue by configuring the
AsyncQueueFullPolicy to enqueue the event: set system property
{{log4j2.AsyncQueueFullPolicy}} to {{Discard}} and set
{{log4j2.DiscardThreshold}} to a value that doesn't discard any events. (Away
from pc, don't remember if it's ALL or NONE.)
> AsyncAppender with LinkedTransferQueue.offer()
> --
>
> Key: LOG4J2-1760
> URL: https://issues.apache.org/jira/browse/LOG4J2-1760
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
>Affects Versions: 2.7
>Reporter: Addison Walterson
>Priority: Minor
>
> I suggest that the AsyncAppender can use a LinkedTransferQueue for which
> offer() is used to enqueue messages because tryTransfer() only succeeds if
> the receiving thread waits for a message which means that the queue has
> length 0.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] (LOG4J2-1803) JMH generated benchmark classes not included in jar
Title: Message Title
Remko Popma updated an issue
Log4j 2 / LOG4J2-1803
JMH generated benchmark classes not included in jar
Change By:
Remko Popma
Some time after the 2.7 release, the JMH benchmarks stopped working. When trying to execute them, this error occurs:{code}java.lang.IllegalArgumentException: Benchmark does not match a class at org.openjdk.jmh.util.ClassUtils.loadClass(ClassUtils.java:90) at org.openjdk.jmh.runner.BaseRunner.runBenchmark(BaseRunner.java:198) at org.openjdk.jmh.runner.BaseRunner.runBenchmarks(BaseRunner.java:95) at org.openjdk.jmh.runner.ForkedRunner.run(ForkedRunner.java:51) at org.openjdk.jmh.runner.ForkedMain.main(ForkedMain.java:68)Caused by: java.lang.ClassNotFoundException: org.apache.logging.log4j.perf.jmh.generated.FileAppenderBenchmark_julFile at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:425) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:195) at org.openjdk.jmh.util.ClassUtils.loadClass(ClassUtils.java:72) ... 4 more{code} When I build the project, the classes generated by JMH under log4j-perf/target/generated-sources/annotations are not included in the shaded benchmarks.jar or in log4j-perf-2.8.1-SNAPSHOT.jar... The cause seems to be a change in the master pom:the {{maven-compiler-plugin}} plugin now has the below section which was not there in 2.7. If I take it out and build only log4j-perf, the benchmarks run without error. (But building all modules fails: some problem in log4j-core...){code} default-compile compilecompile none process-plugins compileprocess-classes only{code}From the log4j-dev mailing list:{quote}That maven-compiler-plugin config was originally only included in log4j-core in order to allow the PluginProcessor annotation processor to re-run against log4j-core without needing to split it into its own jar. I'm not sure why it's configured for everything now.{quote}Potentially related: somebody reported on StackOverflow that [their custom plugin no longer loads with 2.8|http://stackoverflow.com/questions/41938128/log4j-2-8-cannot-load-custom-converters-in-osgi-environment].
Add Comment
[jira] (LOG4J2-1803) JMH generated benchmark classes not included in jar
Title: Message Title Remko Popma updated an issue Log4j 2 / LOG4J2-1803 JMH generated benchmark classes not included in jar Change By: Remko Popma Summary: JMH benchmarks fail to run generated benchmark classes not included in jar Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
[jira] (LOG4J2-1803) JMH benchmarks fail to run
Title: Message Title Remko Popma created an issue Log4j 2 / LOG4J2-1803 JMH benchmarks fail to run Issue Type: Bug Affects Versions: 2.8 Assignee: Unassigned Components: Core, Performance Benchmarks Created: 30/Jan/17 18:37 Priority: Major Reporter: Remko Popma Some time after the 2.7 release, the JMH benchmarks stopped working. When trying to execute them, this error occurs: java.lang.IllegalArgumentException: Benchmark does not match a class at org.openjdk.jmh.util.ClassUtils.loadClass(ClassUtils.java:90) at org.openjdk.jmh.runner.BaseRunner.runBenchmark(BaseRunner.java:198) at org.openjdk.jmh.runner.BaseRunner.runBenchmarks(BaseRunner.java:95) at org.openjdk.jmh.runner.ForkedRunner.run(ForkedRunner.java:51) at org.openjdk.jmh.runner.ForkedMain.main(ForkedMain.java:68) Caused by: java.lang.ClassNotFoundException: org.apache.logging.log4j.perf.jmh.generated.FileAppenderBenchmark_julFile at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:425) at
[jira] [Created] (LOG4J2-1801) Add more detail to WARN Ignoring log event after log4j was shut down
Remko Popma created LOG4J2-1801:
---
Summary: Add more detail to WARN Ignoring log event after log4j
was shut down
Key: LOG4J2-1801
URL: https://issues.apache.org/jira/browse/LOG4J2-1801
Project: Log4j 2
Issue Type: Improvement
Components: Core
Affects Versions: 2.8
Reporter: Remko Popma
Assignee: Remko Popma
Currently, AsyncLoggerConfigDisruptor::enqueueEvent,
AsyncLoggerDisruptor::tryPublish and
AsyncLoggerDisruptor::enqueueLogMessageInfo catch exceptions when logging
occurs after the context has been stopped.
These errors are currently handled by logging to the status logger:
{code}
LOGGER.warn("Ignoring log event after log4j was shut down.", contextName);
{code}
This can be improved by adding more details from the LogEvent that is being
dropped:
{code}
LOGGER.warn("Ignoring log event after log4j was shut down: {} [{}] {}",
event.getLevel(),
event.getLoggerName(), event.getMessage().getFormattedMessage()
+ (event.getThrown() == null ? "" :
Throwables.toStringList(event.getThrown(;
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1603) Redo hashCode() and equals() methods in org.apache.logging.log4j.core.net.ssl classes.
[
https://issues.apache.org/jira/browse/LOG4J2-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1603:
Fix Version/s: (was: 2.8)
2.8.1
> Redo hashCode() and equals() methods in org.apache.logging.log4j.core.net.ssl
> classes.
> --
>
> Key: LOG4J2-1603
> URL: https://issues.apache.org/jira/browse/LOG4J2-1603
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.6.2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.8.1
>
>
> We have a few FindBugs warnings about {{hashCode()}} and {{equals(Object)}}
> methods in the package {{org.apache.logging.log4j.core.net.ssl}} classes.
> The first problem is that not all classes implement these method where some
> of the code expects it to like an {{equals()}} method calling another
> {{equals()}} method but there is not one and the behavior of
> {{Object.equals()}} kicks in.
> This change make it obvious where there are still issues: the behavior
> described above will only happen when the code path ends up in a JRE class
> which itself depends on {{Object.equals()}}, so you still get a FindBugs
> warning about that but it is no longer a warning about a class in our code.
> We can revisit how to best implement {{equals()}} for those classes later.
> It is possible that the warning is a false positive since the JRE could be
> using a subclass of the class FindBugs complains about.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1594) Add support for adding and removing Filters via JMX
[ https://issues.apache.org/jira/browse/LOG4J2-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1594: Fix Version/s: (was: 2.8) 2.8.1 > Add support for adding and removing Filters via JMX > --- > > Key: LOG4J2-1594 > URL: https://issues.apache.org/jira/browse/LOG4J2-1594 > Project: Log4j 2 > Issue Type: New Feature > Components: Filters, JMX >Reporter: Remko Popma > Fix For: 2.8.1 > > > Add support for adding and removing Filters via JMX. > * LoggerConfigs > * Appenders > * Configuration > Ideally also support adding new elements to CompositeFilters. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1395) Add "direct" option to ConsoleAppender for increased performance
[ https://issues.apache.org/jira/browse/LOG4J2-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1395: Fix Version/s: (was: 2.8) 2.8.1 > Add "direct" option to ConsoleAppender for increased performance > > > Key: LOG4J2-1395 > URL: https://issues.apache.org/jira/browse/LOG4J2-1395 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.5, 2.6, 2.6.1 >Reporter: Mikael Ståldal >Assignee: Mikael Ståldal > Fix For: 2.8.1 > > Attachments: app.zip, ggregory-hardware.txt > > > The ConsoleAppender is much slower than the FileAppender. > It would be nice to improve the performance of the ConsoleAppender. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-915) Wrong timestamp of filename when SizeBasedTriggering and TimeBasedTrigger used simultaniously with RollingFileAppender
[ https://issues.apache.org/jira/browse/LOG4J2-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-915: --- Fix Version/s: (was: 2.8) 2.8.1 > Wrong timestamp of filename when SizeBasedTriggering and TimeBasedTrigger > used simultaniously with RollingFileAppender > -- > > Key: LOG4J2-915 > URL: https://issues.apache.org/jira/browse/LOG4J2-915 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.1 >Reporter: Daniel Stuckert > Fix For: 2.8.1 > > Attachments: JIRA_915.diff > > > When using the SizedBasedTrigger and TimeBasedTrigger simultaniously the > timestamp for the filename generated by the SizeBasedTrigger is not the > current time but the next timestamp calculated by the TimeBasedTrigger. > The bug can be reproduced with the sample configuration in the manual. > Likely cause of the problem is that the TimeBasedTrigger sets the time of the > next rollover and the SizeBasedTrigger uses the set time. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1498) [Java 9] fix dependency on old JDK versioning scheme
[
https://issues.apache.org/jira/browse/LOG4J2-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1498:
Fix Version/s: (was: 2.8)
2.8.1
> [Java 9] fix dependency on old JDK versioning scheme
>
>
> Key: LOG4J2-1498
> URL: https://issues.apache.org/jira/browse/LOG4J2-1498
> Project: Log4j 2
> Issue Type: Bug
> Components: Core, Layouts
>Affects Versions: 2.6.2
>Reporter: Remko Popma
> Fix For: 2.8.1
>
>
> AbstractStringLayout currently has this code:
> {code}
> // LOG4J2-1151: If the built-in JDK 8 encoders are available we should
> use them.
> private static boolean isPreJava8() {
> final String version = System.getProperty("java.version");
> final String[] parts = version.split("\\.");
> try {
> final int major = Integer.parseInt(parts[1]);
> return major < 8;
> } catch (final Exception ex) {
> return true;
> }
> }
> {code}
> With Java 9, this will not work correctly. (Impact is very small, but
> anyway...)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1477) @NonNull support (for @NonNullByDefault or similar)
[
https://issues.apache.org/jira/browse/LOG4J2-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1477:
Fix Version/s: (was: 2.8)
2.8.1
> @NonNull support (for @NonNullByDefault or similar)
> ---
>
> Key: LOG4J2-1477
> URL: https://issues.apache.org/jira/browse/LOG4J2-1477
> Project: Log4j 2
> Issue Type: Wish
> Components: API
>Affects Versions: 2.6.2
> Environment: any
>Reporter: Bojan Antonović
> Fix For: 2.8.1
>
>
> Eclipse (and other tools) offer non-null checks by annotation processing.
> One of the possibilities to enable this is to add the annotation
> @org.eclipse.jdt.annotation.NonNullByDefault in your package-info.java file.
> Example:
> @org.eclipse.jdt.annotation.NonNullByDefault
> package foo;
> A frequent problem is reported when using a logger:
> private static final Logger LOGGER = LogManager.getLogger(Bla.class);
> for which Eclipse says:
> Null type safety (type annotations): The expression of type 'Logger' needs
> unchecked conversion to conform to '@NonNull Logger' Bla.java (...)
> This can by bypassed by putting a @SuppressWarnings("null") over the
> expression, but this has to be done in every class, and may be the *only*
> line of code with this workaround.
> Problems:
> - There are other annotations for non-null (javax.annotation.Nonnull) and
> many other frameworks, like the Checker Framework.
> - I don't want to be a judge which one to choose.
> - Deeper support may require a dependency on Java 8.
> - If you want to do it framework wide, this can be a huge task.
> - As some tools are not mature (IMHO), it will need experiments.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1576) Better automated backwards compatibility checking
[
https://issues.apache.org/jira/browse/LOG4J2-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1576:
Fix Version/s: (was: 2.8)
2.8.1
> Better automated backwards compatibility checking
> -
>
> Key: LOG4J2-1576
> URL: https://issues.apache.org/jira/browse/LOG4J2-1576
> Project: Log4j 2
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Remko Popma
> Fix For: 2.8.1
>
>
> I have trouble running Clirr on a machine that only has Java 8 (ran into the
> "Invalid byte tag in constant pool" problem) so I started to look at
> alternatives. These two seem promising:
> * [javacmp|https://siom79.github.io/japicmp/]
> * [Revapi|http://revapi.org/]
> h4. Revapi Configuration
> More docs are [here|http://revapi.org/getting-started.html]. Very quick:
> $\{root}/pom.xml
> {code}
>
> org.revapi
> revapi-maven-plugin
> 0.5.1
>
>
> org.revapi
> revapi-java
> 0.10.1
>
>
>
>
>
>
> api-check
> check
>
>
>
> {code}
> $\{root}/log4j-api/pom.xml and $\{root}/log4j-core/pom.xml
> {code}
>
> org.revapi
> revapi-maven-plugin
> 0.5.1
>
>
> ${project.groupId}:${project.artifactId}:2.6.2
>
>
>
> ${project.groupId}:${project.artifactId}:${project.version}
>
>
>
>
> api-check
> check
>
>
>
> {code}
> $\{root}/log4j-bom/pom.xml
> {code}
>
> org.revapi
> revapi-maven-plugin
> 0.5.1
>
>
> org.revapi
> revapi-java
> 0.10.1
>
>
>
> {code}
> h4. Revapi Maven Plugin
> Docs are [here|http://revapi.org/modules/revapi-maven-plugin/index.html].
> After running {{mvn revapi:check}}, it finds a lot. There is a mechanism to
> suppress findings in a fine-grained way.
> {noformat}
> [ERROR] java.class.removed: class
> org.apache.logging.log4j.core.async.DaemonThreadFactory: Class was removed.
> [ERROR] java.field.constantValueChanged: field
> org.apache.logging.log4j.core.layout.PatternLayout.TTCC_CONVERSION_PATTERN:
> Constant field changed value from '%r [%t] %p %c %x - %m%n' to '%r [%t] %p %c
> %notEmpty{%x }- %m%n'.
> [ERROR] java.field.removed: field
> org.apache.logging.log4j.core.appender.rolling.DefaultRolloverStrategy.LOGGER:
> Field removed from class.
> [ERROR] java.field.removed: field
> org.apache.logging.log4j.core.util.Constants.UTF_8: Field removed from class.
> [ERROR] java.generics.formalTypeParameterAdded: class
> org.apache.logging.log4j.core.appender.ConsoleAppender.Builder: A new formal
> type parameter added to element: 'B extends
> org.apache.logging.log4j.core.appender.ConsoleAppender.Builder org.apache.logging.log4j.core.appender.ConsoleAppender.Builder>'.
> [ERROR] java.generics.formalTypeParameterAdded: method
> org.apache.logging.log4j.core.appender.ConsoleAppender.Builder
> org.apache.logging.log4j.core.appender.ConsoleAppender::newBuilder(): A new
> formal type parameter added to element: 'B extends
> org.apache.logging.log4j.core.appender.ConsoleAppender.Builder org.apache.logging.log4j.core.appender.ConsoleAppender.Builder>'.
> [ERROR] java.method.addedToInterface: method boolean
> org.apache.logging.log4j.core.LifeCycle::stop(long,
> java.util.concurrent.TimeUnit): Method was added to an interface.
> [ERROR] java.method.addedToInterface: method java.lang.String
> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder extends
> org.apache.logging.log4j.core.config.Configuration>::toXmlConfiguration():
> Method was added to an interface.
> [ERROR] java.method.addedToInterface: method
> org.apache.logging.log4j.core.LoggerContext
> org.apache.logging.log4j.core.config.Configuration::getLoggerContext():
> Method was added to an interface.
> [ERROR] java.method.addedToInterface: method
> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder
> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder extends
> org.apache.logging.log4j.core.config.Configuration>::setDestination(java.lang.String):
> Method was added to an interface.
> [ERROR] java.method.addedToInterface: method
> org.apache.logging.log4j.spi.ContextData
> org.apache.logging.log4j.core.LogEvent::getContextData(): Method was added to
> an interface.
> [ERROR] java.method.addedToInterface: method void
> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder extends
> org.apache.logging.log4j.core.config.Configuration>::setLoggerContext(org.apache.logging.log4j.core.LoggerContext):
> Method was added to an interface.
> [ERROR] java.method.addedToInterface: method void
> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder extends
> org.apache.logging.log4j.core.config.Configuration>::writeXmlConfiguration(java.io.OutputStream)
>
[jira] [Updated] (LOG4J2-1410) Add new LiteTimeoutBlockingWaitStrategy for Async Loggers
[ https://issues.apache.org/jira/browse/LOG4J2-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1410: Fix Version/s: (was: 2.8) 2.8.1 > Add new LiteTimeoutBlockingWaitStrategy for Async Loggers > - > > Key: LOG4J2-1410 > URL: https://issues.apache.org/jira/browse/LOG4J2-1410 > Project: Log4j 2 > Issue Type: New Feature > Components: Core >Affects Versions: 2.6 >Reporter: Remko Popma >Assignee: Remko Popma > Fix For: 2.8.1 > > > Discussion on the Mechanical Sympathy mailing list [brought to > light|https://groups.google.com/d/msg/mechanical-sympathy/klefjRqlpQE/0wpjUkE9AwAJ] > an interesting aspect of using the Disruptor under light loads: if the > background thread has no work to do because the queue is empty, it will > block, and await a signal that more work has been put onto the queue. > Sending this signal is done in the application thread when a new log event is > enqueued. This is done by obtaining the shared Lock and calling > Condition.signal(). Now, if multiple application threads try to do this > signalling at the same time, one of them will be suspended by the OS. This > may be costly, and unnecessary, because waking up the background thread twice > is wasteful. > The Disruptor contains the > [LiteBlockingWaitStrategy|https://github.com/LMAX-Exchange/disruptor/blob/master/src/main/java/com/lmax/disruptor/LiteBlockingWaitStrategy.java] > for this. > Log4j uses the > [TimeoutBlockingWaitStrategy|https://github.com/LMAX-Exchange/disruptor/blob/master/src/main/java/com/lmax/disruptor/TimeoutBlockingWaitStrategy.java] > by default since we had a report of a deadlock with BlockingWaitStrategy on > Solaris (LOG4J2-1221). > This ticket proposes to create a custom wait strategy that combines > LiteBlockingWaitStrategy with TimeoutBlockingWaitStrategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1341) (GC) Avoid allocating temporary objects in Pattern Converters for PatternLayout
[
https://issues.apache.org/jira/browse/LOG4J2-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1341:
Fix Version/s: (was: 2.8)
2.8.1
> (GC) Avoid allocating temporary objects in Pattern Converters for
> PatternLayout
> ---
>
> Key: LOG4J2-1341
> URL: https://issues.apache.org/jira/browse/LOG4J2-1341
> Project: Log4j 2
> Issue Type: Improvement
> Components: Pattern Converters
>Affects Versions: 2.5
>Reporter: Remko Popma
> Fix For: 2.8.1
>
>
> *To do*
> The following pattern converters can be modified to avoid creating temporary
> objects in their {{format}} method:
> * -all done-
> *Investigate*
> The following pattern converters may be difficult to modify since they rely
> on JDK components that create temporary objects:
> * (-) ExtendedThrowablePatternConverter
> * (-) RegexReplacementConverter
> * (-) RootThrowablePatternConverter
> * (-) ThrowablePatternConverter
> * (-) UuidPatternConverter
> * (-) ClassNamePatternConverter (location information requires creating
> StackTraceElements)
> * (-) FileLocationPatternConverter
> * (-) FullLocationPatternConverter
> * (-) LineLocationPatternConverter
> * (-) MethodLocationPatternConverter
> *Done*
> The following pattern converters already do not allocate temporary objects in
> their format method:
> * (/) AbstractStyleNameConverter (since 2.8)
> * (/) HighlightConverter (since 2.7, thanks to Richard Zschech)
> * (/) StyleConverter (since 2.7, thanks to Richard Zschech)
> * (/) DatePatternConverter
> * (/) EqualsIgnoreCaseReplacementConverter (since 2.8)
> * (/) EqualsReplacementConverter (since 2.8)
> * (/) EncodingPatternConverter (since 2.8)
> * (/) IntegerPatternConverter (since 2.8)
> * (/) LevelPatternConverter
> * (/) LineSeparatorPatternConverter
> * (/) LiteralPatternConverter (unless literal contains '${')
> * (/) LoggerPatternConverter
> * (/) MapPatternConverter (since 2.8 - note that constructing a MapMessage is
> not garbage-free)
> * (/) MarkerPatternConverter (since 2.8)
> * (/) MarkerSimpleNamePatternConverter
> * (/) MaxLengthConverter (since 2.8)
> * (/) MdcPatternConverter (since 2.7)
> * (/) MessagePatternConverter (unless a Jansi or HTML renderer is configured
> or message has '${' lookups)
> * (/) NamePatternConverter
> * (/) NanoTimePatternConverter
> * (/) NdcPatternConverter (since 2.8 ContextStack implementations implement
> the StringBuilderFormattable interface - note that the ThreadContext stack is
> cloned for each log event and is not garbage-free)
> * (/) RelativeTimePatternConverter (since 2.8)
> * (/) SequenceNumberPatternConverter (since 2.8)
> * (/) ThreadIdPatternConverter
> * (/) ThreadNamePatternConverter
> * (/) ThreadPriorityPatternConverter
> * (/) VariablesNotEmptyReplacementConverter (since 2.8)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1130) CsvLogEventLayout NanoTime timestamp is always zero.
[
https://issues.apache.org/jira/browse/LOG4J2-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1130:
Fix Version/s: (was: 2.8)
2.8.1
> CsvLogEventLayout NanoTime timestamp is always zero.
>
>
> Key: LOG4J2-1130
> URL: https://issues.apache.org/jira/browse/LOG4J2-1130
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.4
>Reporter: Remko Popma
> Fix For: 2.8.1
>
>
> CsvLogEventLayout generates NanoTime timestamps but these are always zero.
> To fix this, add the below code to the CsvLogEventLayout constructor:
> {code}
> // LOG4J2-1074 Switch to actual clock if nanosecond timestamps are
> required in config.
> // LoggerContext will notify known NanoClockFactory users that the
> configuration has changed.
> NanoClockFactory.setMode(NanoClockFactory.Mode.System);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1381) Documentation for LoggerNameLevelRewritePolicy is wrong
[
https://issues.apache.org/jira/browse/LOG4J2-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1381:
Fix Version/s: (was: 2.8)
2.8.1
> Documentation for LoggerNameLevelRewritePolicy is wrong
> ---
>
> Key: LOG4J2-1381
> URL: https://issues.apache.org/jira/browse/LOG4J2-1381
> Project: Log4j 2
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 2.5
>Reporter: Remko Popma
> Fix For: 2.8.1
>
>
> The docs for [LoggerNameLevelRewritePolicy
> |http://logging.apache.org/log4j/2.x/manual/appenders.html#RewriteAppender]
> are wrong:
> * property {{loggerName}} (both in the parameter table and in the example
> configuration): looking at the code, this should be {{logger}} instead.
> * property {{LevelPair}} (in the parameter table) should be {{KeyValuePair}}
> instead. The example configuration is correct here.
> (Or should the code be modified to match the docs instead?)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1086) SizeBasedTriggeringPolicy is not working properly
[
https://issues.apache.org/jira/browse/LOG4J2-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1086:
Fix Version/s: (was: 2.8)
2.8.1
> SizeBasedTriggeringPolicy is not working properly
> -
>
> Key: LOG4J2-1086
> URL: https://issues.apache.org/jira/browse/LOG4J2-1086
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.3, 2.4.1
> Environment: Windows 7 OS Websphere 8.5.5.6
>Reporter: Sharat
>Assignee: Ralph Goers
>Priority: Minor
> Labels: features
> Fix For: 2.8.1
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> {code}
>
>
>
> filePattern="/logs/test-%i.log">
>
> %d %-5p %class{36} (%M:%L)
> -%msg%xEx%n
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1521) StringIndexOutOfBoundsException thrown when rolling logs
[
https://issues.apache.org/jira/browse/LOG4J2-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1521:
Fix Version/s: (was: 2.8)
2.8.1
> StringIndexOutOfBoundsException thrown when rolling logs
>
>
> Key: LOG4J2-1521
> URL: https://issues.apache.org/jira/browse/LOG4J2-1521
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.6.2
> Environment: Windows 10 Pro 64-bit (10.0, Build 14393)
> (14393.rs1_release.160715-1616)
> java version "1.8.0_73"
> Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode)
>Reporter: Johno Crawford
> Fix For: 2.8.1
>
>
> When prototyping with log4j I ran into an issue with rolling log files.
> {noformat}
> 2016-08-16 08:26:25,304 main ERROR An exception occurred processing Appender
> TABLE1-appender java.lang.StringIndexOutOfBoundsException: String index out
> of range: -1
> at
> java.lang.AbstractStringBuilder.setCharAt(AbstractStringBuilder.java:380)
> at java.lang.StringBuilder.setCharAt(StringBuilder.java:76)
> at
> org.apache.logging.log4j.core.util.datetime.FastDatePrinter$PaddedNumberField.appendTo(FastDatePrinter.java:895)
> at
> org.apache.logging.log4j.core.util.datetime.FastDatePrinter$PaddedNumberField.appendTo(FastDatePrinter.java:880)
> at
> org.apache.logging.log4j.core.util.datetime.FastDatePrinter.applyRules(FastDatePrinter.java:479)
> at
> org.apache.logging.log4j.core.util.datetime.FastDatePrinter.format(FastDatePrinter.java:454)
> at
> org.apache.logging.log4j.core.util.datetime.FastDatePrinter.format(FastDatePrinter.java:442)
> at
> org.apache.logging.log4j.core.util.datetime.FastDateFormat.format(FastDateFormat.java:427)
> at
> org.apache.logging.log4j.core.pattern.DatePatternConverter$PatternFormatter.formatToBuffer(DatePatternConverter.java:70)
> at
> org.apache.logging.log4j.core.pattern.DatePatternConverter.formatWithoutAllocation(DatePatternConverter.java:259)
> at
> org.apache.logging.log4j.core.pattern.DatePatternConverter.format(DatePatternConverter.java:251)
> at
> org.apache.logging.log4j.core.pattern.DatePatternConverter.format(DatePatternConverter.java:238)
> at
> org.apache.logging.log4j.core.pattern.DatePatternConverter.format(DatePatternConverter.java:290)
> at
> org.apache.logging.log4j.core.pattern.DatePatternConverter.format(DatePatternConverter.java:299)
> at
> org.apache.logging.log4j.core.appender.rolling.PatternProcessor.formatFileName(PatternProcessor.java:248)
> at
> org.apache.logging.log4j.core.appender.rolling.PatternProcessor.formatFileName(PatternProcessor.java:233)
> at
> org.apache.logging.log4j.core.appender.rolling.DefaultRolloverStrategy.purgeAscending(DefaultRolloverStrategy.java:323)
> at
> org.apache.logging.log4j.core.appender.rolling.DefaultRolloverStrategy.purge(DefaultRolloverStrategy.java:306)
> at
> org.apache.logging.log4j.core.appender.rolling.DefaultRolloverStrategy.rollover(DefaultRolloverStrategy.java:524)
> at
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:220)
> at
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:155)
> at
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.checkRollover(RollingFileManager.java:150)
> at
> org.apache.logging.log4j.core.appender.RollingFileAppender.append(RollingFileAppender.java:85)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:155)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:128)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:119)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:390)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:375)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:359)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:349)
> at
> org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:63)
> at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:146)
> at
> org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:1988)
> at
>
[jira] [Updated] (LOG4J2-1593) Concrete Filter implementations should override equals and hashCode
[
https://issues.apache.org/jira/browse/LOG4J2-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1593:
Fix Version/s: (was: 2.8)
2.8.1
> Concrete Filter implementations should override equals and hashCode
> ---
>
> Key: LOG4J2-1593
> URL: https://issues.apache.org/jira/browse/LOG4J2-1593
> Project: Log4j 2
> Issue Type: Improvement
> Components: Filters
>Reporter: Remko Popma
> Fix For: 2.8.1
>
>
> For {{CompositeFilter.remove(Filter)}} to work correctly, concrete Filter
> implementations should override {{equals}} and {{hashCode}}.
> This is because CompositeFilter uses List.remove(Object), comparing by
> equality. Applications that keep a reference to the Filter object that was
> registered will work, but for example registering and unregistering
> serialized and deserialized instances via JMX will not work without this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1229) Error creating logger
[
https://issues.apache.org/jira/browse/LOG4J2-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1229:
Fix Version/s: (was: 2.8)
2.8.1
> Error creating logger
> -
>
> Key: LOG4J2-1229
> URL: https://issues.apache.org/jira/browse/LOG4J2-1229
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.4.1, 2.5
> Environment: Ubuntu 14.04
>Reporter: Dmitriy Dumanskiy
> Fix For: 2.8.1
>
>
> I have a lot of VMs where everything is fine. But on some of them I get
> below stack trace. I have a feeling it somehow related with access rights.
> Here is stack trace :
> {code}
> 2015-12-21 08:05:06,036 AsyncLogger-1 ERROR Unable to invoke factory method
> in class class org.apache.logging.log4j.core.appender.RollingFileAppender for
> element RollingFile. java.lang.reflect.InvocationTargetException
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:136)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:813)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:753)
> at
> org.apache.logging.log4j.core.appender.routing.RoutingAppender.createAppender(RoutingAppender.java:152)
> at
> org.apache.logging.log4j.core.appender.routing.RoutingAppender.getControl(RoutingAppender.java:136)
> at
> org.apache.logging.log4j.core.appender.routing.RoutingAppender.append(RoutingAppender.java:110)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:152)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:125)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:116)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:390)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:378)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:362)
> at
> org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:79)
> at
> org.apache.logging.log4j.core.async.AsyncLogger.actualAsyncLog(AsyncLogger.java:385)
> at
> org.apache.logging.log4j.core.async.RingBufferLogEvent.execute(RingBufferLogEvent.java:103)
> at
> org.apache.logging.log4j.core.async.RingBufferLogEventHandler.onEvent(RingBufferLogEventHandler.java:43)
> at
> org.apache.logging.log4j.core.async.RingBufferLogEventHandler.onEvent(RingBufferLogEventHandler.java:28)
> at
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalStateException: ManagerFactory
> [org.apache.logging.log4j.core.appender.rolling.RollingFileManager$RollingFileManagerFactory@346629f5]
> unable to create manager for [/data//1_v4.csv] with data
> [org.apache.logging.log4j.core.appender.rolling.RollingFileManager$FactoryData@6d48f4b0]
> at
> org.apache.logging.log4j.core.appender.AbstractManager.getManager(AbstractManager.java:73)
> at
> org.apache.logging.log4j.core.appender.OutputStreamManager.getManager(OutputStreamManager.java:61)
> at
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.getFileManager(RollingFileManager.java:79)
> at
> org.apache.logging.log4j.core.appender.RollingFileAppender.createAppender(RollingFileAppender.java:193)
> ... 25 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1699) Configurable Log File Permissions with PosixFilePermission
[ https://issues.apache.org/jira/browse/LOG4J2-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1699: Fix Version/s: (was: 2.8) 2.8.1 > Configurable Log File Permissions with PosixFilePermission > -- > > Key: LOG4J2-1699 > URL: https://issues.apache.org/jira/browse/LOG4J2-1699 > Project: Log4j 2 > Issue Type: Question > Components: Appenders > Environment: Linux >Reporter: Demetrios Dimatos >Priority: Critical > Labels: features > Fix For: 2.8.1 > > Original Estimate: 336h > Remaining Estimate: 336h > > We would like to hear the communities thoughts on being able to configure the > permissions log files are created with. We don't want to rely on UMASK > because we have managed services who's process should generate logs with a > 644 yet deployed applications by users should default to a 640 because the > logs may contain sensitive information. > We will make the modification and set this in the properties file. Now we are > looking to see what the community position would be on accepting such a > patch, we don't want to be patching our own distribution indefinitely. > I searched all the JIRAs and was not able to find any matching requirements > recently. All I could find was something dated in 2006: > https://bz.apache.org/bugzilla/show_bug.cgi?id=40407 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1534) Create alias 'statusDestination' for 'dest' attribute in Configuration
[ https://issues.apache.org/jira/browse/LOG4J2-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1534: Fix Version/s: (was: 2.8) 2.8.1 > Create alias 'statusDestination' for 'dest' attribute in Configuration > -- > > Key: LOG4J2-1534 > URL: https://issues.apache.org/jira/browse/LOG4J2-1534 > Project: Log4j 2 > Issue Type: Improvement > Components: Configurators >Affects Versions: 2.6.2 >Reporter: Remko Popma >Priority: Minor > Fix For: 2.8.1 > > > This is a follow-up for LOG4J2-1526. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1705) Kotlin wrapper for Log4j 2 API
[ https://issues.apache.org/jira/browse/LOG4J2-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1705: Fix Version/s: (was: 2.8) 2.8.1 > Kotlin wrapper for Log4j 2 API > -- > > Key: LOG4J2-1705 > URL: https://issues.apache.org/jira/browse/LOG4J2-1705 > Project: Log4j 2 > Issue Type: New Feature > Components: API >Reporter: Raman Gupta > Fix For: 2.8.1 > > > Similar to LOG4J2-1181 for Scala, provide a Kotlin wrapper for the Log4j 2 > API that makes use of Kotlin features like delegates and string interpolation. > If there is interest in this, I'd like to contribute a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1246) PatternLayout %date conversion pattern should render time zone designator for ISO-ISO8601
[
https://issues.apache.org/jira/browse/LOG4J2-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1246:
Fix Version/s: (was: 2.8)
2.8.1
> PatternLayout %date conversion pattern should render time zone designator for
> ISO-ISO8601
> -
>
> Key: LOG4J2-1246
> URL: https://issues.apache.org/jira/browse/LOG4J2-1246
> Project: Log4j 2
> Issue Type: Bug
> Components: Pattern Converters
>Affects Versions: 2.4.1, 2.5
>Reporter: Daniel Marcotte
> Fix For: 2.8.1
>
>
> Hi there!
> There might be a small issue with the Pattern Converters regarding Timezone
> management:
> http://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout
> Right now, these patterns:
> * {{"%d\{ISO8601_BASIC\}}}
> * {{%d\{ISO8601_BASIC\}\{UTC\}}}
> Give the same results:
> * {{20160104T204256,048}}
> * {{20160104T204256,048}}
> However, with a deeper look at the ISO-8601 standards, the second one with
> {{"\{UTC\}"}} should properly add the Timezone at the end of the timestamp.
> Reference: https://en.wikipedia.org/wiki/ISO_8601#Times
> {quote}
> *UTC*
> If the time is in UTC, add a Z directly after the time without a space. Z is
> the zone designator for the zero UTC offset. "09:30 UTC" is therefore
> represented as "09:30Z" or "0930Z". "14:45:15 UTC" would be "14:45:15Z" or
> "144515Z".
> UTC time is also known as 'Zulu' time, since 'Zulu' is the NATO phonetic
> alphabet word for 'Z'.
> *Examples*
> Z
> ±hh:mm
> ±hhmm
> ±hh
> {quote}
> As of ISO-8601, the results should be one of the following (configurable?):
> * {{20160104T204256,048Z}}
> * {{20160104T204256,048+00:00}}
> * {{20160104T204256,048+}}
> * {{20160104T204256,048+00}}
> Another reference:
> http://stackoverflow.com/questions/833102/wheres-the-datetime-z-format-specifier
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1013) Log4j2 Main Arguments Lookup by name doesn't work
[
https://issues.apache.org/jira/browse/LOG4J2-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-1013:
Fix Version/s: (was: 2.8)
2.8.1
> Log4j2 Main Arguments Lookup by name doesn't work
> -
>
> Key: LOG4J2-1013
> URL: https://issues.apache.org/jira/browse/LOG4J2-1013
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core, Lookups
>Affects Versions: 2.2
> Environment: Windows 7 x64 Ultimate and Java 8U31 x64. Project
> created using Eclipse.
>Reporter: Ioan Mihaila
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments:
> LOG4J2_1013_select_underlying_StrLookup_before_stripping_off_potential_default_values.patch
>
>
> Accessing Main Arguments by using index based look up works : $\{main:0}
> Accessing Main Arguments by using name based look up doesn't work :
> $\{main:--file}
> When trying to access by name it doesn't retrieve the argument but retrieves
> "-file".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1630) Unit of Work Logging
[ https://issues.apache.org/jira/browse/LOG4J2-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1630: Fix Version/s: (was: 2.8) 2.8.1 > Unit of Work Logging > > > Key: LOG4J2-1630 > URL: https://issues.apache.org/jira/browse/LOG4J2-1630 > Project: Log4j 2 > Issue Type: Story > Components: API, Core, Filters >Affects Versions: 2.7 >Reporter: Remko Popma > Fix For: 2.8.1 > > > h3. Intent > Provide a way to filter log events, where the decision on whether to discard > the message or actually log them cannot be made until after the application > has already logged the message. > h3. Motivation > In many systems, particularly event processing applications, log files > contain a lot of repetitive log messages. Suppose an application needs to do > some calculation to decide whether or not to react to some event, and a lot > of detail is logged during this calculation. Imagine that 99% of the time, > the application decides to take no action. Once the application arrived at > that conclusion it would be nice if we could go back and undo all the > detailed logging and print a summary instead. When the application _does_ > decide to take some action, however, we _do_ want the detailed log messages. > A Unit of Work for logging would allow us to group a set of log messages and > either discard them or log them together. (Inspired by Martin Fowler's [Unit > of Work|http://martinfowler.com/eaaCatalog/unitOfWork.html] pattern.) > This should result in log files where a lot of the "uninteresting" logging is > filtered out, significantly reducing the amount of data logged. > Some applications do this in an ad hoc manner, for example by passing a > Collection to its components, where these components can add log message > strings to this Collection. When the discard/retain decision is made, the > application then either clears the Collection or logs the contents of the > Collection. This works, but having to pass the Collection down the component > tree is clunky and the result often omits details like logger name, timestamp > and other details that come for free with normal logging. Log4j can provide a > reusable and less intrusive way to accomplish this. > h3. How it works > There would need to be some API for the application to mark the _start_ of > the unit of work, and some API to signal whether the log messages that are > part of that unit of work need to be _discarded_ or _logged_ (retained). > Not all logging that occurs after a unit of work was started is part of that > unit of work. The application may want some messages to be logged regardless > of whether the unit of work was discarded or not. There needs to be a > flexible way (or multiple ways) to include or exclude logging statements from > the unit of work. > The application may also designate multiple units of work, which may be > sequential, nested or partially overlapping. Each unit of work may define its > own rules for which log messages are considered included in or excluded from > the unit of work. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1116) Web app-friendly thread locals for gc-free logging (was: upgrade to log4j2 causes too frequent minor gc)
[ https://issues.apache.org/jira/browse/LOG4J2-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1116: Fix Version/s: (was: 2.8) 2.8.1 > Web app-friendly thread locals for gc-free logging (was: upgrade to log4j2 > causes too frequent minor gc) > > > Key: LOG4J2-1116 > URL: https://issues.apache.org/jira/browse/LOG4J2-1116 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.3 > Environment: jdk1.6 > slf4j 1.7.9 > log4j2.3 >Reporter: Mingjiang Shi >Assignee: Ralph Goers >Priority: Critical > Fix For: 2.8.1 > > Attachments: Log4jThreadLocal.java, Log4jThreadLocal.java > > > We used slf4j+log1.2 in our spring web application. Due to the log4j1.0 > performance issue, we upgrade it to log4j2. When it goes to production, it > experienced very frequent minor gc (once per second) even though the eden > area is not full. For example, the eden area just occupied 10%, the minor gc > also happens. The issue disappears when rolling back to log4j1.2. > Can anyone show some hints on diagnose this issue? Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1198) Add support for custom rollover strategy
[ https://issues.apache.org/jira/browse/LOG4J2-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1198: Fix Version/s: (was: 2.8) 2.8.1 > Add support for custom rollover strategy > > > Key: LOG4J2-1198 > URL: https://issues.apache.org/jira/browse/LOG4J2-1198 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.4.1 >Reporter: Remko Popma > Fix For: 2.8.1 > > > [DefaultRolloverStrategy|http://logging.apache.org/log4j/2.x/manual/appenders.html#DefaultRolloverStrategy] > has a very compact configuration, but as a trade-off has become a bit > monolithic. I find it difficult to unit test and maintain. > Continuing in the spirit of the work done for LOG4J2-435, I would like to > break out components for the different kinds of processing done by > DefaultRolloverStrategy so that they can be individually configured and > combined by users. Users would configure a CustomRolloverStrategy by > specifying nested actions that define what needs to be done during a rollover. > The DefaultRolloverStrategy would still continue to work as current, but > under the hood can delegate to these components. > _At this stage the above is still just a concept. The description is to be > updated when it becomes more clear if and how this would work._ -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1761) Support for standard java queues for the async logger
[ https://issues.apache.org/jira/browse/LOG4J2-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833571#comment-15833571 ] Remko Popma commented on LOG4J2-1761: - If I understand correctly you are proposing to introduce a mechanism to let Async Loggers use various queues rather than the Disruptor under the hood. I am sorry but I don't see the benefit of doing this. The Disruptor is faster than the suggested queues, and with its pre-allocated ring buffer it is the only asynchronous message passing mechanism that can be garbage free. More flexibility in this case is not a good thing. > Support for standard java queues for the async logger > - > > Key: LOG4J2-1761 > URL: https://issues.apache.org/jira/browse/LOG4J2-1761 > Project: Log4j 2 > Issue Type: Improvement > Components: Core >Affects Versions: 2.7 >Reporter: Kim Northrop >Priority: Minor > Attachments: AsyncLogEvent.java, AsyncLoggerWithQueueContext.java, > AsyncLoggerWithQueueContextSelector.java, AsyncLoggerWithQueue.java, > QueueWrapperCLQ.java, QueueWrapper.java, QueueWrapperLBQ.java, > QueueWrapperLTQ.java > > > Please add support for standard java queues (LinkedTransferQueue, > ArrayBlockingQueue, LinkedBlockingQueue, ConcurrentLinkedQueue) to the async > logger. I will attach some classes for usage with System properties > (Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerWithQueueContextSelector, > LoggerQueue.Capacity=, LoggerQueue.Type= LinkedTransferQueue, ConcurrentLinkedQueue, LinkedBlockingQueue>). Since most > of these queues allocate new nodes for new elements I have not implemented > usage of thread locals for the log events. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1796) Serialize the ParameterizedMessage variables
[
https://issues.apache.org/jira/browse/LOG4J2-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833401#comment-15833401
]
Remko Popma commented on LOG4J2-1796:
-
There seems to be a misunderstanding:
When a ParameterizedMessage is serialized, the message String is formatted
first, _including the parameter values_. So the formatted string will contain
the text value of the original parameters when deserialized.
{{ParameterizedMessage::getFormattedMessage}} works correctly even for a
serialized and deserialized Message.
However the current implementation does not try to serialize the parameter
Objects.
Do you need the parameter Objects to be serialized and deserialized? (These
objects will not be used to create the formatted message since that is done
prior to serialization.)
> Serialize the ParameterizedMessage variables
>
>
> Key: LOG4J2-1796
> URL: https://issues.apache.org/jira/browse/LOG4J2-1796
> Project: Log4j 2
> Issue Type: New Feature
> Components: Core
>Reporter: Alexandru Ionita
>
> When serializing a {{LogEvent}}, if the message that the {{LogEvent}}
> consists of is of type {{ParameterizedMessage}}, the variables that are
> needed to construct the final String message are not serialized, thus making
> the message and the serialization itself unuseful, since the message is
> carrying the whole value of the {{LogEvent}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1795) LogEvent serialization deserialization
[ https://issues.apache.org/jira/browse/LOG4J2-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15832602#comment-15832602 ] Remko Popma commented on LOG4J2-1795: - We can use a similar approach as with [SortedArrayStringMap|https://github.com/apache/logging-log4j2/blob/master/log4j-api/src/main/java/org/apache/logging/log4j/util/SortedArrayStringMap.java], so we serialize where possible and drop the rest. Wrapping in MarshalledObject to handle NoClassDefErrors. But there needs to be a request. > LogEvent serialization deserialization > -- > > Key: LOG4J2-1795 > URL: https://issues.apache.org/jira/browse/LOG4J2-1795 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.7 >Reporter: Alexandru Ionita > Labels: serializable > > Deserialization of a LogEvent that has been serialized with the > Log4jLogEvent.serialize method fails after the serialized object went through > a byte stream. > Here is a test that demonstrates the issue: > https://github.com/nucatus/LogEventSerializationPOC -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1795) LogEvent serialization deserialization
[ https://issues.apache.org/jira/browse/LOG4J2-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831919#comment-15831919 ] Remko Popma commented on LOG4J2-1795: - I agree this is counterintuitive. Do you have suggestions for improvement? We could improve the manual for example. Suggestions for which page and wording would be welcome. As for ParameterizedMessage serialization, would you mind raising a separate JIRA ticket for that? > LogEvent serialization deserialization > -- > > Key: LOG4J2-1795 > URL: https://issues.apache.org/jira/browse/LOG4J2-1795 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.7 >Reporter: Alexandru Ionita > Labels: serializable > > Deserialization of a LogEvent that has been serialized with the > Log4jLogEvent.serialize method fails after the serialized object went through > a byte stream. > Here is a test that demonstrates the issue: > https://github.com/nucatus/LogEventSerializationPOC -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
