[jira] [Comment Edited] (LOG4J2-2072) Support TLS configuration through FlumeAppender

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205976#comment-16205976
 ] 

Gary Gregory edited comment on LOG4J2-2072 at 10/16/17 2:29 PM:


IMO, the first task in this ticket should be to convert the factory method to a 
builder as we have for other appenders.


was (Author: garydgregory):
IMO, the first task in this ticket should be to convert the factory method to a 
builder as we have for other area of the project.

> Support TLS configuration through FlumeAppender
> ---
>
> Key: LOG4J2-2072
> URL: https://issues.apache.org/jira/browse/LOG4J2-2072
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Affects Versions: 2.9.1
>Reporter: Frank Swanson
>
> When using the FlumeAppnder with a FlumeAvroManager it would be nice to be 
> able to pass some properties through to the connect method for the RpcClient 
> to support SSL configuration.
> The required properties to support the configuration are ~
> properties[0] = 
> Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUST_ALL_CERTS,
>  "false");
> properties[1] = 
> Property.createProperty(RpcClientConfigurationConstants.CONFIG_SSL, "true");
> properties[2] = 
> Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE, 
> path_to_truststore);
> properties[3] = 
> Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_PASSWORD,
>  super_secret);
> properties[4] = 
> Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_TYPE,
>  "JKS");
> I am happy to provide a PR for this feature if supported. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2072) Support TLS configuration through FlumeAppender

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205976#comment-16205976
 ] 

Gary Gregory commented on LOG4J2-2072:
--

IMO, the first task in this ticket should be to convert the factory method to a 
builder as we have for other area of the project.

> Support TLS configuration through FlumeAppender
> ---
>
> Key: LOG4J2-2072
> URL: https://issues.apache.org/jira/browse/LOG4J2-2072
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Affects Versions: 2.9.1
>Reporter: Frank Swanson
>
> When using the FlumeAppnder with a FlumeAvroManager it would be nice to be 
> able to pass some properties through to the connect method for the RpcClient 
> to support SSL configuration.
> The required properties to support the configuration are ~
> properties[0] = 
> Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUST_ALL_CERTS,
>  "false");
> properties[1] = 
> Property.createProperty(RpcClientConfigurationConstants.CONFIG_SSL, "true");
> properties[2] = 
> Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE, 
> path_to_truststore);
> properties[3] = 
> Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_PASSWORD,
>  super_secret);
> properties[4] = 
> Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_TYPE,
>  "JKS");
> I am happy to provide a PR for this feature if supported. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (LOG4J2-2074) The console appender should say why it cannot load JAnsi

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-2074.

   Resolution: Fixed
Fix Version/s: 2.10.0

In git master.

> The console appender should say why it cannot load JAnsi
> 
>
> Key: LOG4J2-2074
> URL: https://issues.apache.org/jira/browse/LOG4J2-2074
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders, Core
>Affects Versions: 2.9.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.10.0
>
>
> The console appender should say why it cannot load JAnsi



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (LOG4J2-2074) The console appender should say why it cannot load JAnsi

[Gary Gregory (JIRA)]

Gary Gregory created LOG4J2-2074:


 Summary: The console appender should say why it cannot load JAnsi
 Key: LOG4J2-2074
 URL: https://issues.apache.org/jira/browse/LOG4J2-2074
 Project: Log4j 2
  Issue Type: Bug
  Components: Appenders, Core
Affects Versions: 2.9.1
Reporter: Gary Gregory
Assignee: Gary Gregory


The console appender should say why it cannot load JAnsi



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (LOG4J2-2073) Log4j-config.xsd should make AppenderRef optional for each Logger element

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-2073.

   Resolution: Fixed
Fix Version/s: 2.10.0

In git master.

> Log4j-config.xsd should make AppenderRef optional for each Logger element
> -
>
> Key: LOG4J2-2073
> URL: https://issues.apache.org/jira/browse/LOG4J2-2073
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.9.0, 2.9.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.10.0
>
>
> Log4j-config.xsd should make AppenderRef optional for each Logger element.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-1982) Log4j-config.xsd only allows one AppenderRef element for each Logger element

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202777#comment-16202777
 ] 

Gary Gregory commented on LOG4J2-1982:
--

Right! Fixing with https://issues.apache.org/jira/browse/LOG4J2-2073

> Log4j-config.xsd only allows one AppenderRef element for each Logger element
> 
>
> Key: LOG4J2-1982
> URL: https://issues.apache.org/jira/browse/LOG4J2-1982
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Configurators
>Affects Versions: 2.8.2
> Environment: Alle environments
>Reporter: Christoph Lembeck
> Fix For: 2.9.0
>
>
> The xsd schema definition for the log4j configuration allow only one 
> AppenderRef per Logger. The definition of the Logger element is as follows
> {code:xml}
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> {code}
> Comparing this to the Definition of the root Logger we see a sequence of 
> multiple Appender
> Ref elements to be allowed.
> {code:xml}
> 
> 
>  minOccurs="1" maxOccurs="unbounded"/>
> 
> 
> 
> {code}
> With this configuration it is not possible to define a specific Logger, that 
> shows infos and errors to the console and writes only the errors in a log 
> file, since there can only be one appender defined for that logger.
> Please modify the xsd file to allow mutliple AppenderRef elements per Logger.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (LOG4J2-2073) Log4j-config.xsd should make AppenderRef optional for each Logger element

[Gary Gregory (JIRA)]

Gary Gregory created LOG4J2-2073:


 Summary: Log4j-config.xsd should make AppenderRef optional for 
each Logger element
 Key: LOG4J2-2073
 URL: https://issues.apache.org/jira/browse/LOG4J2-2073
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.9.1, 2.9.0
Reporter: Gary Gregory
Assignee: Gary Gregory


Log4j-config.xsd should make AppenderRef optional for each Logger element.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (LOG4J2-1216) Nested pattern layout options broken

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved LOG4J2-1216.
--
Resolution: Fixed

PR 116 applied. Please verify and close. Note that the unit test 
{{org.apache.logging.log4j.core.pattern.PatternParserTest}} hangs without the 
main code change, which is good.

> Nested pattern layout options broken
> 
>
> Key: LOG4J2-1216
> URL: https://issues.apache.org/jira/browse/LOG4J2-1216
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Pattern Converters
>Affects Versions: 2.4.1, 2.9.1
>Reporter: Thies Wellpott
>  Labels: easyfix
> Fix For: 2.9.2
>
>
> Parsing the "deeply" nested PatternLayout
> {code}
> %maxLen{[XXX, ${hostName}, ${web:contextPath}] %p: %c{1} - %m%notEmpty{ 
> =>%ex{short}}}{160}
> {code}
> (with %maxLen being a custom Converter)
> results in wrong parsing.
> Patternparser.extractOptions() gets the nesting wrong.
> Solution:
> {code}
> private static int extractOptions(final String pattern, final int start, 
> final List options) {
> int i = start;
> while (i < pattern.length()  &&  pattern.charAt(i) == '{') {
> i++;  // skip opening "{"
> final int begin = i;  // position of first real char
> int depth = 1;// already inside one level
> while (depth > 0  &&  i < pattern.length()) {
> char c = pattern.charAt(i);
> if (c == '{') {
> depth++;
> } else if (c == '}') {
> depth--;
> // TODO(?) maybe escaping of { and } with \ or %
> }
> i++;
> } // while
> if (depth > 0) {  // option not closed, continue with pattern 
> on opening "{"
> return begin-1;
> }
> options.add(pattern.substring(begin, i-1));
> } // while
> return i;
> }
> {code}
> This should also be faster than the current implementation because the 
> pattern ist only walked once, not multiple times with indexOf().
> (LOG4J2-107 is a similar but old bug)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2072) Support TLS configuration through FlumeAppender

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202207#comment-16202207
 ] 

Gary Gregory commented on LOG4J2-2072:
--

Thank you for helping out. Please do not forget unit tests.

> Support TLS configuration through FlumeAppender
> ---
>
> Key: LOG4J2-2072
> URL: https://issues.apache.org/jira/browse/LOG4J2-2072
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Affects Versions: 2.9.1
>Reporter: Frank Swanson
>
> When using the FlumeAppnder with a FlumeAvroManager it would be nice to be 
> able to pass some properties through to the connect method for the RpcClient 
> to support SSL configuration.
> The required properties to support the configuration are ~
> properties[0] = 
> Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUST_ALL_CERTS,
>  "false");
> properties[1] = 
> Property.createProperty(RpcClientConfigurationConstants.CONFIG_SSL, "true");
> properties[2] = 
> Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE, 
> path_to_truststore);
> properties[3] = 
> Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_PASSWORD,
>  super_secret);
> properties[4] = 
> Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_TYPE,
>  "JKS");
> I am happy to provide a PR for this feature if supported. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (LOG4J2-1216) Nested pattern layout options broken

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory reopened LOG4J2-1216:
--

> Nested pattern layout options broken
> 
>
> Key: LOG4J2-1216
> URL: https://issues.apache.org/jira/browse/LOG4J2-1216
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Pattern Converters
>Affects Versions: 2.4.1, 2.9.1
>Reporter: Thies Wellpott
>  Labels: easyfix
> Fix For: 2.9.2
>
>
> Parsing the "deeply" nested PatternLayout
> {code}
> %maxLen{[XXX, ${hostName}, ${web:contextPath}] %p: %c{1} - %m%notEmpty{ 
> =>%ex{short}}}{160}
> {code}
> (with %maxLen being a custom Converter)
> results in wrong parsing.
> Patternparser.extractOptions() gets the nesting wrong.
> Solution:
> {code}
> private static int extractOptions(final String pattern, final int start, 
> final List options) {
> int i = start;
> while (i < pattern.length()  &&  pattern.charAt(i) == '{') {
> i++;  // skip opening "{"
> final int begin = i;  // position of first real char
> int depth = 1;// already inside one level
> while (depth > 0  &&  i < pattern.length()) {
> char c = pattern.charAt(i);
> if (c == '{') {
> depth++;
> } else if (c == '}') {
> depth--;
> // TODO(?) maybe escaping of { and } with \ or %
> }
> i++;
> } // while
> if (depth > 0) {  // option not closed, continue with pattern 
> on opening "{"
> return begin-1;
> }
> options.add(pattern.substring(begin, i-1));
> } // while
> return i;
> }
> {code}
> This should also be faster than the current implementation because the 
> pattern ist only walked once, not multiple times with indexOf().
> (LOG4J2-107 is a similar but old bug)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2071) Add org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString()

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201065#comment-16201065
 ] 

Gary Gregory commented on LOG4J2-2071:
--

This closes #114.

> Add 
> org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString()
> 
>
> Key: LOG4J2-2071
> URL: https://issues.apache.org/jira/browse/LOG4J2-2071
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.9.2
>
>
> Add 
> org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString()



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (LOG4J2-2071) Add org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString()

[Gary Gregory (JIRA)]

Gary Gregory created LOG4J2-2071:


 Summary: Add 
org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString()
 Key: LOG4J2-2071
 URL: https://issues.apache.org/jira/browse/LOG4J2-2071
 Project: Log4j 2
  Issue Type: Improvement
  Components: Core
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 2.9.2


Add 
org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString()



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (LOG4J2-2068) Can't set monitorInterval for composite XML configuration.

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved LOG4J2-2068.
--
   Resolution: Fixed
Fix Version/s: 2.9.2

In Git master. Please verify and fix. Adding a unit test would be greatly 
appreciated.

> Can't set monitorInterval for composite XML configuration.
> --
>
> Key: LOG4J2-2068
> URL: https://issues.apache.org/jira/browse/LOG4J2-2068
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.9.1
>Reporter: Robert Haycock
> Fix For: 2.9.2
>
> Attachments: patch_2068.diff
>
>
> When trying to combine a composite configuration with automatic reload, it 
> fails to reload. 
> When an {{XmlConfiguration}} is reloaded it calls 
> {{XmlConfiguration.reconfigure()}} which sets the {{rootElement}} field, and 
> everything is fine.
> When a {{CompositeConfiguration}} is reloaded, it doesn't call 
> {{reconfigure()}} on the {{XmlConfigurations}}. This means when it tries to 
> start the config {{XmlConfiguration.setup()}} is called and {{rootElement}} 
> is null, resulting in an error message "No logging configuration".
> End result is the config isn't loaded and there's no more logging.
> To reproduce, it doesn't matter what is in the configurations. Just need at 
> least 2 XML configs in the {{log4j.configurationFile}} property and the 
> {{monitorInterval}} set.
> (Ps. my first ticket)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2068) Can't set monitorInterval for composite XML configuration.

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16200540#comment-16200540
 ] 

Gary Gregory commented on LOG4J2-2068:
--

Hi [~tedtrippin]:

Thank you for your patch! Can you please include a unit test that fails with 
this change? Otherwise, another change could just inadvertently revert the fix.

Thank you,
Gary

> Can't set monitorInterval for composite XML configuration.
> --
>
> Key: LOG4J2-2068
> URL: https://issues.apache.org/jira/browse/LOG4J2-2068
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.9.1
>Reporter: Robert Haycock
> Attachments: patch_2068.diff
>
>
> When trying to combine a composite configuration with automatic reload, it 
> fails to reload. 
> When an {{XmlConfiguration}} is reloaded it calls 
> {{XmlConfiguration.reconfigure()}} which sets the {{rootElement}} field, and 
> everything is fine.
> When a {{CompositeConfiguration}} is reloaded, it doesn't call 
> {{reconfigure()}} on the {{XmlConfigurations}}. This means when it tries to 
> start the config {{XmlConfiguration.setup()}} is called and {{rootElement}} 
> is null, resulting in an error message "No logging configuration".
> End result is the config isn't loaded and there's no more logging.
> To reproduce, it doesn't matter what is in the configurations. Just need at 
> least 2 XML configs in the {{log4j.configurationFile}} property and the 
> {{monitorInterval}} set.
> (Ps. my first ticket)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LOG4J2-2070) Log4j1XmlLayout does not provide the entire stack trace, it is missing the caused by information

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-2070:
-
Fix Version/s: 2.9.2

> Log4j1XmlLayout does not provide the entire stack trace, it is missing the 
> caused by information
> 
>
> Key: LOG4J2-2070
> URL: https://issues.apache.org/jira/browse/LOG4J2-2070
> Project: Log4j 2
>  Issue Type: Bug
>  Components: log4j 1.2 emulation
>Affects Versions: 2.8.2
>Reporter: Doug Hughes
> Fix For: 2.9.2
>
> Attachments: patch.diff
>
>
> Log4j1XmlLayout does not provide the entire stack trace, it is missing the 
> caused by information.
> Attaching a patch that can correct this



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (LOG4J2-2070) Log4j1XmlLayout does not provide the entire stack trace, it is missing the caused by information

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved LOG4J2-2070.
--
Resolution: Fixed

In git master. Please verify and close.

> Log4j1XmlLayout does not provide the entire stack trace, it is missing the 
> caused by information
> 
>
> Key: LOG4J2-2070
> URL: https://issues.apache.org/jira/browse/LOG4J2-2070
> Project: Log4j 2
>  Issue Type: Bug
>  Components: log4j 1.2 emulation
>Affects Versions: 2.8.2
>Reporter: Doug Hughes
> Attachments: patch.diff
>
>
> Log4j1XmlLayout does not provide the entire stack trace, it is missing the 
> caused by information.
> Attaching a patch that can correct this



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2061) RollingFileManager not removed when RollingFileAppender is stopped, using DirectWriteRolloverStrategy

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199534#comment-16199534
 ] 

Gary Gregory commented on LOG4J2-2061:
--

Hi [~matthewhill],

Are you able to provide a unit test that reproduces the problem? This ticket is 
more likely to get some attention with some test code attached ;-)

Thank you!
Gary

> RollingFileManager not removed when RollingFileAppender is stopped, using 
> DirectWriteRolloverStrategy
> -
>
> Key: LOG4J2-2061
> URL: https://issues.apache.org/jira/browse/LOG4J2-2061
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.9.0
> Environment: *
>Reporter: Matthew Hill
>Priority: Blocker
>
> When programmatically creating an instance of RollingFileAppender using 
> RollingFileAppender.newBuilder.(config options).build(), an instance of 
> RollingFileManager is created in AbstractManager.getManager(...), and this 
> instance is stored in the hashmap AbstractManager.MAP as well as on the 
> instance of RollingFileAppender in the super class 
> AbstractOutputStreamAppender. This manager is created and stored in the 
> AbstractManager.MAP with the name FILE_PATTERN (since we cannot create an 
> instance of RollingFileAppender with a file name using the 
> DirectWriteRolloverStrategy). However, the same manager is created with a 
> NAME of NULL since it is trying to use file name as the name of the manager, 
> but this parameter is not allowed using DirectWriteRolloverStrategy. 
> The problem here is that the RollingFileManager is created with a name of 
> FILE NAME (i.e., NULL when using DirectWriteRolloverStrategy) and added to 
> the hashmap with a key of FILE PATTERN, but when the rolling file appender is 
> stopped, it attempts to remove its manager from this MAP using 
> RollingFileManager.name, which equates to FILE NAME which is NULL.
> Consider the following example:
> * create a rolling file appender using the DirectWriteRolloverStrategy with a 
> file pattern of 'output.%i.log'
> * a RollingFileManager is created with the name NULL, but put in 
> AbstractManager.MAP with the name 'output.%i.log'
> * the rolling file appender is used to write a few line of log file
> * the rolling file appender is stopped using RollingFileAppender.stop(..)
> * the RollingFileManager is NOT removed from AbstractManager.MAP since it is 
> trying to remove FILE NAME but it is keyed on FILE PATTERN
> * a NEW instance of rolling file appender is created using the 
> DirectWriteRolloverStrategy with the SAME file pattern of 'output.%i.log'. 
> * a new instance of RollingFileManager is NOT created, as it already exists 
> in the MAP, so the old instance is simply returned
> * the instance of RollingFileManager for the new instance of 
> RollingFileAppender has a closed output stream, meaning that no logging is 
> possible.
> In the above example you can see that if the old rolling file appender's 
> output stream is closed, and a new instance created with the same file 
> pattern, then the old manager will be used. I see no easy way of recreating 
> this output stream.
> I found no documentation regarding why one cannot set the FILE NAME for a 
> RollingFileAppender using DirectWriteRolloverStrategy. Being able to 
> configure this may also solve the problem (unless it causes issues 
> elsewhere), but another possible fix to this issue is to create the 
> RollingFileManager with the name FILE PATTERN when using the 
> DirectWriteRolloverStrategy. This way we add to the MAP the instance of 
> RollingFileManager with the key FILE PATTERN, and we remove from the MAP 
> RollingFileManager.name which equals FILE PATTERN



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (LOG4J2-2067) Using PatternSelectors breaks header printing in PatternLayout

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199531#comment-16199531
 ] 

Gary Gregory edited comment on LOG4J2-2067 at 10/10/17 11:03 PM:
-

Would you be able to provide a unit test we can run that breaks without this 
patch?



was (Author: garydgregory):
Would you be able to provide a unit test we can run that breaks with this patch?


> Using PatternSelectors breaks header printing in PatternLayout
> --
>
> Key: LOG4J2-2067
> URL: https://issues.apache.org/jira/browse/LOG4J2-2067
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Layouts, Pattern Converters
>Affects Versions: 2.8.2, 2.9.0
>Reporter: Paul Burrowes
>
> Using a config of
> {code}
> 
> 
>   
> 
>   
> 
>  filePattern="foo.log.%i">
>   
> 
>   
> 
>   
>   
> 
>   
>   
> 
>   
>   
> 
>   
> 
> {code}
> the header is expected to be formatted according to the pattern configured 
> but instead the output is 
> {code}
> 2017-10-09 14:25:12.072+1300
> 2017-10-09 14:25:12.143+1300 using interpolation and a throwable 
> java.lang.NullPointerException
> java.lang.NullPointerException: null
> at leliel.Main.main(Main.java:51) [Log4j2-testing/:?]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[?:1.7.0_79]
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
> ~[?:1.7.0_79]
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[?:1.7.0_79]
> at java.lang.reflect.Method.invoke(Method.java:606) ~[?:1.7.0_79]
> at 
> com.intellij.rt.execution.application.AppMain.main(AppMain.java:147) 
> [idea_rt.jar:?]
> 2017-10-09 14:25:12.151+1300 throwable only
> {code}
> The fix appears to simply be to not provide the PatternSelector to the header 
> and footer Serializer builders.
> {code}
> diff --git 
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/PatternLayout.java
>  
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/PatternLayout.java
> index e4440eb9b..39042081f 100644
> --- 
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/PatternLayout.java
> +++ 
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/layout/PatternLayout.java
> @@ -108,7 +108,7 @@ public final class PatternLayout extends 
> AbstractStringLayout {
>  newSerializerBuilder()
>  .setConfiguration(config)
>  .setReplace(replace)
> -.setPatternSelector(patternSelector)
> +.setPatternSelector(null)
>  .setAlwaysWriteExceptions(alwaysWriteExceptions)
>  .setDisableAnsi(disableAnsi)
>  .setNoConsoleNoAnsi(noConsoleNoAnsi)
> @@ -117,7 +117,7 @@ public final class PatternLayout extends 
> AbstractStringLayout {
>  newSerializerBuilder()
>  .setConfiguration(config)
>  .setReplace(replace)
> -.setPatternSelector(patternSelector)
> +.setPatternSelector(null)
>  .setAlwaysWriteExceptions(alwaysWriteExceptions)
>  .setDisableAnsi(disableAnsi)
>  .setNoConsoleNoAnsi(noConsoleNoAnsi)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2053) Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199526#comment-16199526
 ] 

Gary Gregory commented on LOG4J2-2053:
--

Please run the test org.apache.logging.log4j.util.Log4jCharsetsPropertiesTest 
before submitting changes. I had to remove many entries that are already 
mapped. Or, did the test pass for you? If yes, what is you Java vendor and 
version?

I tested with Oracle Java 1.7.0_80, Oracle Java 8 (latest), Oracle Java 9, IBM 
Java 8.



> Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
> 
>
> Key: LOG4J2-2053
> URL: https://issues.apache.org/jira/browse/LOG4J2-2053
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0, 2.9.1
> Environment: Windows 10x64 1607 German
> Java JDK 1.8.0_144 (JAVA_TOOL_OPTIONS=-Dsun.jnu.encoding=UTF8 
> -Dfile.encoding=UTF8 -Ds=0)
> Fitnesse 20161106
> Log4j 2.9.0
> Executing from command line, switching to chcp 65001
>Reporter: Frank Steudle
>Priority: Minor
> Attachments: Log4j-charsets.properties
>
>
> Today I updated my fitnesse project to use the 2.9.0 versions of log4-core 
> and log4j-api. Now I am encountering the exception 
> java.nio.charset.UnsupportedCharsetException: cp65001. 
> However, my project is running well. Logging seems to work anyway.
> According to Issue 1888, there was a similar bug, which was fixed in 2.9.0: 
> [https://issues.apache.org/jira/browse/LOG4J2-1888]. I commented it, but 
> didn't get an answer until now.
> I am using ISO-8859-1 on my Eclipse computer to store the files. But the 
> execution environment is plain UTF-8. Therefore I am using those parameters 
> to run my fitnesse project:
> * -Dsun.jnu.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * -Dfile.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * chcp 65001: to switch the Windows console encoding to UTF8
> Here is the exception, which is thrown: 
> {code:java}
> C:\Users\admin\Desktop\RabbitDevInstall\Testtool>java -jar 
> RunRabbitRun-2.0-SNAPSHOT-jar-with-dependencies.jar start ./Resources
> Picked up JAVA_TOOL_OPTIONS: -Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8 
> -Ds=0
> Unable to get Charset 'sun.stdout.encoding', using default UTF-8
> java.nio.charset.UnsupportedCharsetException: cp65001
> at java.nio.charset.Charset.forName(Unknown Source)
> at 
> org.apache.logging.log4j.util.PropertiesUtil.getCharsetProperty(PropertiesUtil.java:172)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target.getCharset(ConsoleAppender.java:89)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target$1.getDefaultCharset(ConsoleAppender.java:74)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:222)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:189)
> at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:958)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:898)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:890)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:513)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:237)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:249)
> at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:545)
> at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617)
> at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
> at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
> at de.duerr.fitnesse.RunRabbitRun.(RunRabbitRun.java:24)
> 11:37:19.176 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - Passed over first 
> parameter: start
> 11:37:19.192 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - Passed over 
> Fitnesse directory: ./Resources
> 

[jira] [Updated] (LOG4J2-1216) Nested pattern layout options broken

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-1216:
-
Affects Version/s: 2.9.1

> Nested pattern layout options broken
> 
>
> Key: LOG4J2-1216
> URL: https://issues.apache.org/jira/browse/LOG4J2-1216
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Pattern Converters
>Affects Versions: 2.4.1, 2.9.1
>Reporter: Thies Wellpott
>  Labels: easyfix
> Fix For: 2.9.2
>
>
> Parsing the "deeply" nested PatternLayout
> {code}
> %maxLen{[XXX, ${hostName}, ${web:contextPath}] %p: %c{1} - %m%notEmpty{ 
> =>%ex{short}}}{160}
> {code}
> (with %maxLen being a custom Converter)
> results in wrong parsing.
> Patternparser.extractOptions() gets the nesting wrong.
> Solution:
> {code}
> private static int extractOptions(final String pattern, final int start, 
> final List options) {
> int i = start;
> while (i < pattern.length()  &&  pattern.charAt(i) == '{') {
> i++;  // skip opening "{"
> final int begin = i;  // position of first real char
> int depth = 1;// already inside one level
> while (depth > 0  &&  i < pattern.length()) {
> char c = pattern.charAt(i);
> if (c == '{') {
> depth++;
> } else if (c == '}') {
> depth--;
> // TODO(?) maybe escaping of { and } with \ or %
> }
> i++;
> } // while
> if (depth > 0) {  // option not closed, continue with pattern 
> on opening "{"
> return begin-1;
> }
> options.add(pattern.substring(begin, i-1));
> } // while
> return i;
> }
> {code}
> This should also be faster than the current implementation because the 
> pattern ist only walked once, not multiple times with indexOf().
> (LOG4J2-107 is a similar but old bug)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (LOG4J2-1216) Nested pattern layout options broken

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved LOG4J2-1216.
--
   Resolution: Fixed
Fix Version/s: 2.9.2

Setting to Resolved: Fixed in git master.

Please verify and close.

> Nested pattern layout options broken
> 
>
> Key: LOG4J2-1216
> URL: https://issues.apache.org/jira/browse/LOG4J2-1216
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Pattern Converters
>Affects Versions: 2.4.1, 2.9.1
>Reporter: Thies Wellpott
>  Labels: easyfix
> Fix For: 2.9.2
>
>
> Parsing the "deeply" nested PatternLayout
> {code}
> %maxLen{[XXX, ${hostName}, ${web:contextPath}] %p: %c{1} - %m%notEmpty{ 
> =>%ex{short}}}{160}
> {code}
> (with %maxLen being a custom Converter)
> results in wrong parsing.
> Patternparser.extractOptions() gets the nesting wrong.
> Solution:
> {code}
> private static int extractOptions(final String pattern, final int start, 
> final List options) {
> int i = start;
> while (i < pattern.length()  &&  pattern.charAt(i) == '{') {
> i++;  // skip opening "{"
> final int begin = i;  // position of first real char
> int depth = 1;// already inside one level
> while (depth > 0  &&  i < pattern.length()) {
> char c = pattern.charAt(i);
> if (c == '{') {
> depth++;
> } else if (c == '}') {
> depth--;
> // TODO(?) maybe escaping of { and } with \ or %
> }
> i++;
> } // while
> if (depth > 0) {  // option not closed, continue with pattern 
> on opening "{"
> return begin-1;
> }
> options.add(pattern.substring(begin, i-1));
> } // while
> return i;
> }
> {code}
> This should also be faster than the current implementation because the 
> pattern ist only walked once, not multiple times with indexOf().
> (LOG4J2-107 is a similar but old bug)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LOG4J2-2056) Modularize Log4j as automatic modules

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-2056:
-
Description: 
To fully support Java 9 all Log4j jars must (at least) be packaged as automatic 
modules. We should, as much as possible, follow the recommendations at 
http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given that 
the module names would be:

||Artifact ID ||Module name||
|log4j-api|org.apache.logging.log4j|
|log4j-core|org.apache.logging.log4j.core|
|log4j-1.2-api|org.apache.log4j|
|log4j-appserver|org.apache.logging.log4j.appserver|
|log4j-flume-ng|org.apache.logging.log4j.flume|
|log4j-iostreams|org.apache.logging.log4j.iostreams|
|log4j-jcl|org.apache.logging.log4j.jcl|
|log4j-jmx-gui|org.apache.logging.log4j.jmx.gui|
|log4j-jul|org.apache.logging.log4j.jul|
|log4j-nosql|org.apache.logging.log4j.nosql|
|log4j-osgi|org.apache.logging.log4j.osgi|
|log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*|
|log4j-to-slf4j|org.apache.logging.log4j.to.slf4j|
|log4j-taglib|org.apache.logging.log4j.taglib|
|log4j-web|org.apache.logging.log4j.web|

# log4j-liquibase uses a package name outside the org.apache.logging.log4j 
namespace so is not modularized.
# log4j-slf4j-impl cannot currently be modularized until the binding is 
modified. It cannot have classes in the org.slf4j namespace.
# log4j-slf4j-impl and log4j-to-slf4j both use the same package name - 
org.apache.logging.log4j.slf4j. This will remain the same as it will prevent 
them both from being loaded at the same time.




  was:
To fully support Java 9 all Log4j jars must (at least) be packaged as automatic 
modules. We should, as much as possible, follow the recommendations at 
http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given that 
the module names would be:

||Jar name||Module name||
|log4j-api|org.apache.logging.log4j|
|log4j-core|org.apache.logging.log4j.core|
|log4j-1.2-api|org.apache.log4j|
|log4j-appserver|org.apache.logging.log4j.appserver|
|log4j-flume-ng|org.apache.logging.log4j.flume|
|log4j-iostreams|org.apache.logging.log4j.iostreams|
|log4j-jcl|org.apache.logging.log4j.jcl|
|log4j-jmx-gui|org.apache.logging.log4j.jmx.gui|
|log4j-jul|org.apache.logging.log4j.jul|
|log4j-nosql|org.apache.logging.log4j.nosql|
|log4j-osgi|org.apache.logging.log4j.osgi|
|log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*|
|log4j-to-slf4j|org.apache.logging.log4j.to.slf4j|
|log4j-taglib|org.apache.logging.log4j.taglib|
|log4j-web|org.apache.logging.log4j.web|

# log4j-liquibase uses a package name outside the org.apache.logging.log4j 
namespace so is not modularized.
# log4j-slf4j-impl cannot currently be modularized until the binding is 
modified. It cannot have classes in the org.slf4j namespace.
# log4j-slf4j-impl and log4j-to-slf4j both use the same package name - 
org.apache.logging.log4j.slf4j. This will remain the same as it will prevent 
them both from being loaded at the same time.





> Modularize Log4j as automatic modules
> -
>
> Key: LOG4J2-2056
> URL: https://issues.apache.org/jira/browse/LOG4J2-2056
> Project: Log4j 2
>  Issue Type: New Feature
>Affects Versions: 2.9.1
>Reporter: Ralph Goers
>Assignee: Ralph Goers
>
> To fully support Java 9 all Log4j jars must (at least) be packaged as 
> automatic modules. We should, as much as possible, follow the recommendations 
> at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given 
> that the module names would be:
> ||Artifact ID ||Module name||
> |log4j-api|org.apache.logging.log4j|
> |log4j-core|org.apache.logging.log4j.core|
> |log4j-1.2-api|org.apache.log4j|
> |log4j-appserver|org.apache.logging.log4j.appserver|
> |log4j-flume-ng|org.apache.logging.log4j.flume|
> |log4j-iostreams|org.apache.logging.log4j.iostreams|
> |log4j-jcl|org.apache.logging.log4j.jcl|
> |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui|
> |log4j-jul|org.apache.logging.log4j.jul|
> |log4j-nosql|org.apache.logging.log4j.nosql|
> |log4j-osgi|org.apache.logging.log4j.osgi|
> |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*|
> |log4j-to-slf4j|org.apache.logging.log4j.to.slf4j|
> |log4j-taglib|org.apache.logging.log4j.taglib|
> |log4j-web|org.apache.logging.log4j.web|
> # log4j-liquibase uses a package name outside the org.apache.logging.log4j 
> namespace so is not modularized.
> # log4j-slf4j-impl cannot currently be modularized until the binding is 
> modified. It cannot have classes in the org.slf4j namespace.
> # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - 
> org.apache.logging.log4j.slf4j. This will remain the same as it will prevent 
> them both from being loaded at the same time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2068) Can't set monitorInterval for composite XML configuration.

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198022#comment-16198022
 ] 

Gary Gregory commented on LOG4J2-2068:
--

Hi [~tedtrippin],

Would you mind providing a failing unit test that demonstrates this?

Gary

> Can't set monitorInterval for composite XML configuration.
> --
>
> Key: LOG4J2-2068
> URL: https://issues.apache.org/jira/browse/LOG4J2-2068
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.9.1
>Reporter: Robert Haycock
>
> When trying to combine a composite configuration with automatic reload, it 
> fails to reload. 
> When an {{XmlConfiguration}} is reloaded it calls 
> {{XmlConfiguration.reconfigure()}} which sets the {{rootElement}} field, and 
> everything is fine.
> When a {{CompositeConfiguration}} is reloaded, it doesn't call 
> {{reconfigure()}} on the {{XmlConfigurations}}. This means when it tries to 
> start the config {{XmlConfiguration.setup()}} is called and {{rootElement}} 
> is null, resulting in an error message "No logging configuration".
> End result is the config isn't loaded and there's no more logging.
> To reproduce, it doesn't matter what is in the configurations. Just need at 
> least 2 XML configs in the {{log4j.configurationFile}} property and the 
> {{monitorInterval}} set.
> (Ps. my first ticket)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (LOG4J2-2053) Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197391#comment-16197391
 ] 

Gary Gregory edited comment on LOG4J2-2053 at 10/9/17 5:54 PM:
---

This mapping is not quite right. Please the current version in git master here: 
{{log4j-api/src/main/resources/Log4j-charsets.properties}}

For example, the charset {{ibm-912_P100-1995}} is provided by ICU but the page 
https://msdn.microsoft.com/en-us/en-en/library/windows/desktop/dd317756(v=vs.85).aspx
 maps {{28592}} to {{iso-8859-2}} which exists in the Oracle JRE. This lets you 
create the mapping without depending on ICU.

If you really want to map to UTF-7, then yes, you will need to depend on ICU, 
in which case, we can consider adding an optional dependency to ICU4J so that 
tests will pass when testing the default mapping file. Or we can relax the test.

Also run this test when you update the mapping: 
{{org.apache.logging.log4j.util.Log4jCharsetsPropertiesTest}}

To check if a charset SOME_NAME can be loaded run 
{{org.apache.logging.log4j.util.CharsetForNameMain SOME_NAME}} 

To update the property file, either attach a patch file here in unified diff 
format. Alternatively, (and better IMO), you can create a PR on GitHub 
https://github.com/apache/log4j


was (Author: garydgregory):
This mapping is not quite right. Please the current version in git master here: 
{{log4j-api/src/main/resources/Log4j-charsets.properties}}

For example, the charset {{ibm-912_P100-1995}} is provided by ICU but the page 
https://msdn.microsoft.com/en-us/en-en/library/windows/desktop/dd317756(v=vs.85).aspx
 maps {{28592}} to {{iso-8859-2}} which exists in the Oracle JRE. This lets you 
create the mapping without depending on ICU.

Also run this test when you update the mapping: 
{{org.apache.logging.log4j.util.Log4jCharsetsPropertiesTest}}

To check if a charset SOME_NAME can be loaded run 
{{org.apache.logging.log4j.util.CharsetForNameMain SOME_NAME}} 

To update the property file, either attach a patch file here in unified diff 
format. Alternatively, (and better IMO), you can create a PR on GitHub 
https://github.com/apache/log4j

> Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
> 
>
> Key: LOG4J2-2053
> URL: https://issues.apache.org/jira/browse/LOG4J2-2053
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0, 2.9.1
> Environment: Windows 10x64 1607 German
> Java JDK 1.8.0_144 (JAVA_TOOL_OPTIONS=-Dsun.jnu.encoding=UTF8 
> -Dfile.encoding=UTF8 -Ds=0)
> Fitnesse 20161106
> Log4j 2.9.0
> Executing from command line, switching to chcp 65001
>Reporter: Frank Steudle
>Priority: Minor
>
> Today I updated my fitnesse project to use the 2.9.0 versions of log4-core 
> and log4j-api. Now I am encountering the exception 
> java.nio.charset.UnsupportedCharsetException: cp65001. 
> However, my project is running well. Logging seems to work anyway.
> According to Issue 1888, there was a similar bug, which was fixed in 2.9.0: 
> [https://issues.apache.org/jira/browse/LOG4J2-1888]. I commented it, but 
> didn't get an answer until now.
> I am using ISO-8859-1 on my Eclipse computer to store the files. But the 
> execution environment is plain UTF-8. Therefore I am using those parameters 
> to run my fitnesse project:
> * -Dsun.jnu.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * -Dfile.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * chcp 65001: to switch the Windows console encoding to UTF8
> Here is the exception, which is thrown: 
> {code:java}
> C:\Users\admin\Desktop\RabbitDevInstall\Testtool>java -jar 
> RunRabbitRun-2.0-SNAPSHOT-jar-with-dependencies.jar start ./Resources
> Picked up JAVA_TOOL_OPTIONS: -Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8 
> -Ds=0
> Unable to get Charset 'sun.stdout.encoding', using default UTF-8
> java.nio.charset.UnsupportedCharsetException: cp65001
> at java.nio.charset.Charset.forName(Unknown Source)
> at 
> org.apache.logging.log4j.util.PropertiesUtil.getCharsetProperty(PropertiesUtil.java:172)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target.getCharset(ConsoleAppender.java:89)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target$1.getDefaultCharset(ConsoleAppender.java:74)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:222)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:189)
> at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:958)
> at 
> 

[jira] [Comment Edited] (LOG4J2-2053) Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197391#comment-16197391
 ] 

Gary Gregory edited comment on LOG4J2-2053 at 10/9/17 5:52 PM:
---

This mapping is not quite right. Please the current version in git master here: 
{{log4j-api/src/main/resources/Log4j-charsets.properties}}

For example, the charset {{ibm-912_P100-1995}} is provided by ICU but the page 
https://msdn.microsoft.com/en-us/en-en/library/windows/desktop/dd317756(v=vs.85).aspx
 maps {{28592}} to {{iso-8859-2}} which exists in the Oracle JRE.

Also run this test when you update the mapping: 
{{org.apache.logging.log4j.util.Log4jCharsetsPropertiesTest}}

To check if a charset SOME_NAME can be loaded run 
{{org.apache.logging.log4j.util.CharsetForNameMain SOME_NAME}} 

To update the property file, either attach a patch file here in unified diff 
format. Alternatively, (and better IMO), you can create a PR on GitHub 
https://github.com/apache/log4j


was (Author: garydgregory):
This mapping is not quite right. Please the current version in git master here: 
{{log4j-api/src/main/resources/Log4j-charsets.properties}}

Also run this test when you update the mapping: 
{{org.apache.logging.log4j.util.Log4jCharsetsPropertiesTest}}

To check if a charset SOME_NAME can be loaded run 
{{org.apache.logging.log4j.util.CharsetForNameMain SOME_NAME}} 

To update the property file, either attach a patch file here in unified diff 
format. Alternatively, (and better IMO), you can create a PR on GitHub 
https://github.com/apache/log4j

> Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
> 
>
> Key: LOG4J2-2053
> URL: https://issues.apache.org/jira/browse/LOG4J2-2053
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0, 2.9.1
> Environment: Windows 10x64 1607 German
> Java JDK 1.8.0_144 (JAVA_TOOL_OPTIONS=-Dsun.jnu.encoding=UTF8 
> -Dfile.encoding=UTF8 -Ds=0)
> Fitnesse 20161106
> Log4j 2.9.0
> Executing from command line, switching to chcp 65001
>Reporter: Frank Steudle
>Priority: Minor
>
> Today I updated my fitnesse project to use the 2.9.0 versions of log4-core 
> and log4j-api. Now I am encountering the exception 
> java.nio.charset.UnsupportedCharsetException: cp65001. 
> However, my project is running well. Logging seems to work anyway.
> According to Issue 1888, there was a similar bug, which was fixed in 2.9.0: 
> [https://issues.apache.org/jira/browse/LOG4J2-1888]. I commented it, but 
> didn't get an answer until now.
> I am using ISO-8859-1 on my Eclipse computer to store the files. But the 
> execution environment is plain UTF-8. Therefore I am using those parameters 
> to run my fitnesse project:
> * -Dsun.jnu.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * -Dfile.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * chcp 65001: to switch the Windows console encoding to UTF8
> Here is the exception, which is thrown: 
> {code:java}
> C:\Users\admin\Desktop\RabbitDevInstall\Testtool>java -jar 
> RunRabbitRun-2.0-SNAPSHOT-jar-with-dependencies.jar start ./Resources
> Picked up JAVA_TOOL_OPTIONS: -Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8 
> -Ds=0
> Unable to get Charset 'sun.stdout.encoding', using default UTF-8
> java.nio.charset.UnsupportedCharsetException: cp65001
> at java.nio.charset.Charset.forName(Unknown Source)
> at 
> org.apache.logging.log4j.util.PropertiesUtil.getCharsetProperty(PropertiesUtil.java:172)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target.getCharset(ConsoleAppender.java:89)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target$1.getDefaultCharset(ConsoleAppender.java:74)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:222)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:189)
> at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:958)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:898)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:890)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:513)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:237)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:249)
>

[jira] [Comment Edited] (LOG4J2-2053) Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197391#comment-16197391
 ] 

Gary Gregory edited comment on LOG4J2-2053 at 10/9/17 5:52 PM:
---

This mapping is not quite right. Please the current version in git master here: 
{{log4j-api/src/main/resources/Log4j-charsets.properties}}

For example, the charset {{ibm-912_P100-1995}} is provided by ICU but the page 
https://msdn.microsoft.com/en-us/en-en/library/windows/desktop/dd317756(v=vs.85).aspx
 maps {{28592}} to {{iso-8859-2}} which exists in the Oracle JRE. This lets you 
create the mapping without depending on ICU.

Also run this test when you update the mapping: 
{{org.apache.logging.log4j.util.Log4jCharsetsPropertiesTest}}

To check if a charset SOME_NAME can be loaded run 
{{org.apache.logging.log4j.util.CharsetForNameMain SOME_NAME}} 

To update the property file, either attach a patch file here in unified diff 
format. Alternatively, (and better IMO), you can create a PR on GitHub 
https://github.com/apache/log4j


was (Author: garydgregory):
This mapping is not quite right. Please the current version in git master here: 
{{log4j-api/src/main/resources/Log4j-charsets.properties}}

For example, the charset {{ibm-912_P100-1995}} is provided by ICU but the page 
https://msdn.microsoft.com/en-us/en-en/library/windows/desktop/dd317756(v=vs.85).aspx
 maps {{28592}} to {{iso-8859-2}} which exists in the Oracle JRE.

Also run this test when you update the mapping: 
{{org.apache.logging.log4j.util.Log4jCharsetsPropertiesTest}}

To check if a charset SOME_NAME can be loaded run 
{{org.apache.logging.log4j.util.CharsetForNameMain SOME_NAME}} 

To update the property file, either attach a patch file here in unified diff 
format. Alternatively, (and better IMO), you can create a PR on GitHub 
https://github.com/apache/log4j

> Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
> 
>
> Key: LOG4J2-2053
> URL: https://issues.apache.org/jira/browse/LOG4J2-2053
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0, 2.9.1
> Environment: Windows 10x64 1607 German
> Java JDK 1.8.0_144 (JAVA_TOOL_OPTIONS=-Dsun.jnu.encoding=UTF8 
> -Dfile.encoding=UTF8 -Ds=0)
> Fitnesse 20161106
> Log4j 2.9.0
> Executing from command line, switching to chcp 65001
>Reporter: Frank Steudle
>Priority: Minor
>
> Today I updated my fitnesse project to use the 2.9.0 versions of log4-core 
> and log4j-api. Now I am encountering the exception 
> java.nio.charset.UnsupportedCharsetException: cp65001. 
> However, my project is running well. Logging seems to work anyway.
> According to Issue 1888, there was a similar bug, which was fixed in 2.9.0: 
> [https://issues.apache.org/jira/browse/LOG4J2-1888]. I commented it, but 
> didn't get an answer until now.
> I am using ISO-8859-1 on my Eclipse computer to store the files. But the 
> execution environment is plain UTF-8. Therefore I am using those parameters 
> to run my fitnesse project:
> * -Dsun.jnu.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * -Dfile.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * chcp 65001: to switch the Windows console encoding to UTF8
> Here is the exception, which is thrown: 
> {code:java}
> C:\Users\admin\Desktop\RabbitDevInstall\Testtool>java -jar 
> RunRabbitRun-2.0-SNAPSHOT-jar-with-dependencies.jar start ./Resources
> Picked up JAVA_TOOL_OPTIONS: -Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8 
> -Ds=0
> Unable to get Charset 'sun.stdout.encoding', using default UTF-8
> java.nio.charset.UnsupportedCharsetException: cp65001
> at java.nio.charset.Charset.forName(Unknown Source)
> at 
> org.apache.logging.log4j.util.PropertiesUtil.getCharsetProperty(PropertiesUtil.java:172)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target.getCharset(ConsoleAppender.java:89)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target$1.getDefaultCharset(ConsoleAppender.java:74)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:222)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:189)
> at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:958)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:898)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:890)
> at 
> 

[jira] [Updated] (LOG4J2-2068) Can't set monitorInterval for composite XML configuration.

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-2068:
-
Summary: Can't set monitorInterval for composite XML configuration.  (was: 
Cant set monitorInterval for composite XML configuration.)

> Can't set monitorInterval for composite XML configuration.
> --
>
> Key: LOG4J2-2068
> URL: https://issues.apache.org/jira/browse/LOG4J2-2068
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.9.1
>Reporter: Robert Haycock
>
> When trying to combine a composite configuration with automatic reload, it 
> fails to reload. 
> When an {{XmlConfiguration}} is reloaded it calls 
> {{XmlConfiguration.reconfigure()}} which sets the {{rootElement}} field, and 
> everything is fine.
> When a {{CompositeConfiguration}} is reloaded, it doesn't call 
> {{reconfigure()}} on the {{XmlConfigurations}}. This means when it tries to 
> start the config {{XmlConfiguration.setup()}} is called and {{rootElement}} 
> is null, resulting in an error message "No logging configuration".
> End result is the config isn't loaded and there's no more logging.
> To reproduce, it doesn't matter what is in the configurations. Just need at 
> least 2 XML configs in the {{log4j.configurationFile}} property and the 
> {{monitorInterval}} set.
> (Ps. my first ticket)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2053) Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16195746#comment-16195746
 ] 

Gary Gregory commented on LOG4J2-2053:
--

FYI: The whole build runs after calling "chcp 65001" on the console with "mvn 
clean install"

> Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
> 
>
> Key: LOG4J2-2053
> URL: https://issues.apache.org/jira/browse/LOG4J2-2053
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0, 2.9.1
> Environment: Windows 10x64 1607 German
> Java JDK 1.8.0_144 (JAVA_TOOL_OPTIONS=-Dsun.jnu.encoding=UTF8 
> -Dfile.encoding=UTF8 -Ds=0)
> Fitnesse 20161106
> Log4j 2.9.0
> Executing from command line, switching to chcp 65001
>Reporter: Frank Steudle
>Priority: Minor
>
> Today I updated my fitnesse project to use the 2.9.0 versions of log4-core 
> and log4j-api. Now I am encountering the exception 
> java.nio.charset.UnsupportedCharsetException: cp65001. 
> However, my project is running well. Logging seems to work anyway.
> According to Issue 1888, there was a similar bug, which was fixed in 2.9.0: 
> [https://issues.apache.org/jira/browse/LOG4J2-1888]. I commented it, but 
> didn't get an answer until now.
> I am using ISO-8859-1 on my Eclipse computer to store the files. But the 
> execution environment is plain UTF-8. Therefore I am using those parameters 
> to run my fitnesse project:
> * -Dsun.jnu.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * -Dfile.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * chcp 65001: to switch the Windows console encoding to UTF8
> Here is the exception, which is thrown: 
> {code:java}
> C:\Users\admin\Desktop\RabbitDevInstall\Testtool>java -jar 
> RunRabbitRun-2.0-SNAPSHOT-jar-with-dependencies.jar start ./Resources
> Picked up JAVA_TOOL_OPTIONS: -Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8 
> -Ds=0
> Unable to get Charset 'sun.stdout.encoding', using default UTF-8
> java.nio.charset.UnsupportedCharsetException: cp65001
> at java.nio.charset.Charset.forName(Unknown Source)
> at 
> org.apache.logging.log4j.util.PropertiesUtil.getCharsetProperty(PropertiesUtil.java:172)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target.getCharset(ConsoleAppender.java:89)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target$1.getDefaultCharset(ConsoleAppender.java:74)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:222)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:189)
> at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:958)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:898)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:890)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:513)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:237)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:249)
> at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:545)
> at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617)
> at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
> at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
> at de.duerr.fitnesse.RunRabbitRun.(RunRabbitRun.java:24)
> 11:37:19.176 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - Passed over first 
> parameter: start
> 11:37:19.192 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - Passed over 
> Fitnesse directory: ./Resources
> 11:37:19.192 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - The parameters 
> handed over to Fitnesse: -d
> 11:37:19.192 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - The parameters 
> handed over to Fitnesse: ./Resources
> 11:37:19.192 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - The 

[jira] [Comment Edited] (LOG4J2-2053) Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16195746#comment-16195746
 ] 

Gary Gregory edited comment on LOG4J2-2053 at 10/7/17 3:01 PM:
---

FYI: The whole build runs after calling "chcp 65001" on the Windows 10 console 
with "mvn clean install"


was (Author: garydgregory):
FYI: The whole build runs after calling "chcp 65001" on the console with "mvn 
clean install"

> Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
> 
>
> Key: LOG4J2-2053
> URL: https://issues.apache.org/jira/browse/LOG4J2-2053
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0, 2.9.1
> Environment: Windows 10x64 1607 German
> Java JDK 1.8.0_144 (JAVA_TOOL_OPTIONS=-Dsun.jnu.encoding=UTF8 
> -Dfile.encoding=UTF8 -Ds=0)
> Fitnesse 20161106
> Log4j 2.9.0
> Executing from command line, switching to chcp 65001
>Reporter: Frank Steudle
>Priority: Minor
>
> Today I updated my fitnesse project to use the 2.9.0 versions of log4-core 
> and log4j-api. Now I am encountering the exception 
> java.nio.charset.UnsupportedCharsetException: cp65001. 
> However, my project is running well. Logging seems to work anyway.
> According to Issue 1888, there was a similar bug, which was fixed in 2.9.0: 
> [https://issues.apache.org/jira/browse/LOG4J2-1888]. I commented it, but 
> didn't get an answer until now.
> I am using ISO-8859-1 on my Eclipse computer to store the files. But the 
> execution environment is plain UTF-8. Therefore I am using those parameters 
> to run my fitnesse project:
> * -Dsun.jnu.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * -Dfile.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * chcp 65001: to switch the Windows console encoding to UTF8
> Here is the exception, which is thrown: 
> {code:java}
> C:\Users\admin\Desktop\RabbitDevInstall\Testtool>java -jar 
> RunRabbitRun-2.0-SNAPSHOT-jar-with-dependencies.jar start ./Resources
> Picked up JAVA_TOOL_OPTIONS: -Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8 
> -Ds=0
> Unable to get Charset 'sun.stdout.encoding', using default UTF-8
> java.nio.charset.UnsupportedCharsetException: cp65001
> at java.nio.charset.Charset.forName(Unknown Source)
> at 
> org.apache.logging.log4j.util.PropertiesUtil.getCharsetProperty(PropertiesUtil.java:172)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target.getCharset(ConsoleAppender.java:89)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target$1.getDefaultCharset(ConsoleAppender.java:74)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:222)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:189)
> at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:958)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:898)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:890)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:513)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:237)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:249)
> at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:545)
> at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617)
> at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
> at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
> at de.duerr.fitnesse.RunRabbitRun.(RunRabbitRun.java:24)
> 11:37:19.176 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - Passed over first 
> parameter: start
> 11:37:19.192 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - Passed over 
> Fitnesse directory: ./Resources
> 11:37:19.192 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - The parameters 
> handed over to Fitnesse: 

[jira] [Comment Edited] (LOG4J2-2053) Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16195389#comment-16195389
 ] 

Gary Gregory edited comment on LOG4J2-2053 at 10/6/17 10:50 PM:


I added a file called 
{{log4j-api/src/main/resources/Log4j-charsets.properties}} which currently 
contains only one mapping:

{noformat}
cp65001 = UTF-8
{noformat}

This mapping file is used when a charset is not normally found.

Please checkout and test git master (which will be a 2.9.2-SNAPSHOT)

Code reviews welcome!


was (Author: garydgregory):
I added a file called 
{{log4j-api/src/main/resources/Log4j-charsets.properties}} which currently 
contains only one mapping:

{noformat}
cp65001 = UTF-8
{noformat}

This mapping file is used when a charset is not normally found.

Please checkout and test git master (which will be a 2.9.2-SNAPSHOT)

> Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
> 
>
> Key: LOG4J2-2053
> URL: https://issues.apache.org/jira/browse/LOG4J2-2053
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0, 2.9.1
> Environment: Windows 10x64 1607 German
> Java JDK 1.8.0_144 (JAVA_TOOL_OPTIONS=-Dsun.jnu.encoding=UTF8 
> -Dfile.encoding=UTF8 -Ds=0)
> Fitnesse 20161106
> Log4j 2.9.0
> Executing from command line, switching to chcp 65001
>Reporter: Frank Steudle
>Priority: Minor
>
> Today I updated my fitnesse project to use the 2.9.0 versions of log4-core 
> and log4j-api. Now I am encountering the exception 
> java.nio.charset.UnsupportedCharsetException: cp65001. 
> However, my project is running well. Logging seems to work anyway.
> According to Issue 1888, there was a similar bug, which was fixed in 2.9.0: 
> [https://issues.apache.org/jira/browse/LOG4J2-1888]. I commented it, but 
> didn't get an answer until now.
> I am using ISO-8859-1 on my Eclipse computer to store the files. But the 
> execution environment is plain UTF-8. Therefore I am using those parameters 
> to run my fitnesse project:
> * -Dsun.jnu.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * -Dfile.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * chcp 65001: to switch the Windows console encoding to UTF8
> Here is the exception, which is thrown: 
> {code:java}
> C:\Users\admin\Desktop\RabbitDevInstall\Testtool>java -jar 
> RunRabbitRun-2.0-SNAPSHOT-jar-with-dependencies.jar start ./Resources
> Picked up JAVA_TOOL_OPTIONS: -Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8 
> -Ds=0
> Unable to get Charset 'sun.stdout.encoding', using default UTF-8
> java.nio.charset.UnsupportedCharsetException: cp65001
> at java.nio.charset.Charset.forName(Unknown Source)
> at 
> org.apache.logging.log4j.util.PropertiesUtil.getCharsetProperty(PropertiesUtil.java:172)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target.getCharset(ConsoleAppender.java:89)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target$1.getDefaultCharset(ConsoleAppender.java:74)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:222)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:189)
> at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:958)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:898)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:890)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:513)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:237)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:249)
> at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:545)
> at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617)
> at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
> at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> at 

[jira] [Resolved] (LOG4J2-2053) Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved LOG4J2-2053.
--
Resolution: Fixed

I added a file called 
{{log4j-api/src/main/resources/Log4j-charsets.properties}} which currently 
contains only one mapping:

{noformat}
cp65001 = UTF-8
{noformat}

This mapping file is used when a charset is not normally found.

Please checkout and test git master (which will be a 2.9.2-SNAPSHOT)

> Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
> 
>
> Key: LOG4J2-2053
> URL: https://issues.apache.org/jira/browse/LOG4J2-2053
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0, 2.9.1
> Environment: Windows 10x64 1607 German
> Java JDK 1.8.0_144 (JAVA_TOOL_OPTIONS=-Dsun.jnu.encoding=UTF8 
> -Dfile.encoding=UTF8 -Ds=0)
> Fitnesse 20161106
> Log4j 2.9.0
> Executing from command line, switching to chcp 65001
>Reporter: Frank Steudle
>Priority: Minor
>
> Today I updated my fitnesse project to use the 2.9.0 versions of log4-core 
> and log4j-api. Now I am encountering the exception 
> java.nio.charset.UnsupportedCharsetException: cp65001. 
> However, my project is running well. Logging seems to work anyway.
> According to Issue 1888, there was a similar bug, which was fixed in 2.9.0: 
> [https://issues.apache.org/jira/browse/LOG4J2-1888]. I commented it, but 
> didn't get an answer until now.
> I am using ISO-8859-1 on my Eclipse computer to store the files. But the 
> execution environment is plain UTF-8. Therefore I am using those parameters 
> to run my fitnesse project:
> * -Dsun.jnu.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * -Dfile.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * chcp 65001: to switch the Windows console encoding to UTF8
> Here is the exception, which is thrown: 
> {code:java}
> C:\Users\admin\Desktop\RabbitDevInstall\Testtool>java -jar 
> RunRabbitRun-2.0-SNAPSHOT-jar-with-dependencies.jar start ./Resources
> Picked up JAVA_TOOL_OPTIONS: -Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8 
> -Ds=0
> Unable to get Charset 'sun.stdout.encoding', using default UTF-8
> java.nio.charset.UnsupportedCharsetException: cp65001
> at java.nio.charset.Charset.forName(Unknown Source)
> at 
> org.apache.logging.log4j.util.PropertiesUtil.getCharsetProperty(PropertiesUtil.java:172)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target.getCharset(ConsoleAppender.java:89)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target$1.getDefaultCharset(ConsoleAppender.java:74)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:222)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:189)
> at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:958)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:898)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:890)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:513)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:237)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:249)
> at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:545)
> at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617)
> at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
> at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
> at de.duerr.fitnesse.RunRabbitRun.(RunRabbitRun.java:24)
> 11:37:19.176 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - Passed over first 
> parameter: start
> 11:37:19.192 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - Passed over 
> Fitnesse directory: ./Resources
> 11:37:19.192 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - The parameters 
> handed over to 

[jira] [Updated] (LOG4J2-1990) ConcurrentModificationException logging a parameter of type Map

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-1990:
-
Fix Version/s: (was: 2.9.1)
   2.9.2

> ConcurrentModificationException logging a parameter of type Map 
> 
>
> Key: LOG4J2-1990
> URL: https://issues.apache.org/jira/browse/LOG4J2-1990
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.8.2
>Reporter: Philippe Mouawad
> Fix For: 2.9.2
>
> Attachments: LOG4J2-1990.patch
>
>
> Hello,
> Working with current JMeter trunk and:
> *  attached test plan 
> * org.apache.jmeter.protocol.http.control.CacheManager level set to debug in 
> log4j2.xml in bin folder
> I get:
> {code:none}
> java.util.concurrent.ExecutionException: 
> java.util.ConcurrentModificationException
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
> ~[?:1.8.0_121]
>   at java.util.concurrent.FutureTask.get(FutureTask.java:192) 
> ~[?:1.8.0_121]
>   at 
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.downloadPageResources(HTTPSamplerBase.java:1349)
>  [ApacheJMeter_http.jar:3.3-SNAPSHOT.20170724]
>   at 
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.resultProcessing(HTTPSamplerBase.java:1657)
>  [ApacheJMeter_http.jar:3.3-SNAPSHOT.20170724]
>   at 
> org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.resultProcessing(HTTPAbstractImpl.java:519)
>  [ApacheJMeter_http.jar:3.3-SNAPSHOT.20170724]
>   at 
> org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:534)
>  [ApacheJMeter_http.jar:3.3-SNAPSHOT.20170724]
>   at 
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
>  [ApacheJMeter_http.jar:3.3-SNAPSHOT.20170724]
>   at 
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189)
>  [ApacheJMeter_http.jar:3.3-SNAPSHOT.20170724]
>   at 
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178)
>  [ApacheJMeter_http.jar:3.3-SNAPSHOT.20170724]
>   at 
> org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:500)
>  [ApacheJMeter_core.jar:3.3-SNAPSHOT.20170724]
>   at 
> org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) 
> [ApacheJMeter_core.jar:3.3-SNAPSHOT.20170724]
>   at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) 
> [ApacheJMeter_core.jar:3.3-SNAPSHOT.20170724]
>   at java.lang.Thread.run(Thread.java:745) [?:1.8.0_121]
> Caused by: java.util.ConcurrentModificationException
>   at 
> org.apache.commons.collections.map.AbstractLinkedMap$LinkIterator.nextEntry(AbstractLinkedMap.java:560)
>  ~[commons-collections-3.2.2.jar:3.2.2]
>   at 
> org.apache.commons.collections.map.AbstractLinkedMap$EntrySetIterator.next(AbstractLinkedMap.java:428)
>  ~[commons-collections-3.2.2.jar:3.2.2]
>   at 
> org.apache.logging.log4j.message.ParameterFormatter.appendMap(ParameterFormatter.java:569)
>  ~[log4j-api-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.message.ParameterFormatter.appendPotentiallyRecursiveValue(ParameterFormatter.java:505)
>  ~[log4j-api-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.message.ParameterFormatter.recursiveDeepToString(ParameterFormatter.java:432)
>  ~[log4j-api-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.message.ParameterFormatter.formatMessage2(ParameterFormatter.java:189)
>  ~[log4j-api-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.message.ReusableParameterizedMessage.formatTo(ReusableParameterizedMessage.java:313)
>  ~[log4j-api-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.core.impl.MutableLogEvent.setMessage(MutableLogEvent.java:214)
>  ~[log4j-core-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.core.impl.ReusableLogEventFactory.createEvent(ReusableLogEventFactory.java:81)
>  ~[log4j-core-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:401) 
> [log4j-core-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:63)
>  [log4j-core-2.8.2.jar:2.8.2]
>   at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:146) 
> [log4j-core-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(AbstractLogger.java:2091)
>  [log4j-api-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:2005)
>  [log4j-api-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1876)
>  [log4j-api-2.8.2.jar:2.8.2]
>   at 

[jira] [Updated] (LOG4J2-2064) Publish new log4j-server on maven central repository

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-2064:
-
Fix Version/s: (was: 2.9.1)
   2.9.2

> Publish new log4j-server on maven central repository
> 
>
> Key: LOG4J2-2064
> URL: https://issues.apache.org/jira/browse/LOG4J2-2064
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.9.1
>Reporter: Hüseyin Kartal
> Fix For: 2.9.2
>
>
> Server components moved from the log4j-core module to new module, but not 
> available in the central repository.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LOG4J2-1630) Unit of Work Logging

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-1630:
-
Fix Version/s: (was: 2.9.1)
   2.9.2

> 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.9.2
>
>
> 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.4.14#64029)

[jira] [Updated] (LOG4J2-2053) Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-2053:
-
Affects Version/s: 2.9.1

> Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
> 
>
> Key: LOG4J2-2053
> URL: https://issues.apache.org/jira/browse/LOG4J2-2053
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0, 2.9.1
> Environment: Windows 10x64 1607 German
> Java JDK 1.8.0_144 (JAVA_TOOL_OPTIONS=-Dsun.jnu.encoding=UTF8 
> -Dfile.encoding=UTF8 -Ds=0)
> Fitnesse 20161106
> Log4j 2.9.0
> Executing from command line, switching to chcp 65001
>Reporter: Frank Steudle
>Priority: Minor
>
> Today I updated my fitnesse project to use the 2.9.0 versions of log4-core 
> and log4j-api. Now I am encountering the exception 
> java.nio.charset.UnsupportedCharsetException: cp65001. 
> However, my project is running well. Logging seems to work anyway.
> According to Issue 1888, there was a similar bug, which was fixed in 2.9.0: 
> [https://issues.apache.org/jira/browse/LOG4J2-1888]. I commented it, but 
> didn't get an answer until now.
> I am using ISO-8859-1 on my Eclipse computer to store the files. But the 
> execution environment is plain UTF-8. Therefore I am using those parameters 
> to run my fitnesse project:
> * -Dsun.jnu.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * -Dfile.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * chcp 65001: to switch the Windows console encoding to UTF8
> Here is the exception, which is thrown: 
> {code:java}
> C:\Users\admin\Desktop\RabbitDevInstall\Testtool>java -jar 
> RunRabbitRun-2.0-SNAPSHOT-jar-with-dependencies.jar start ./Resources
> Picked up JAVA_TOOL_OPTIONS: -Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8 
> -Ds=0
> Unable to get Charset 'sun.stdout.encoding', using default UTF-8
> java.nio.charset.UnsupportedCharsetException: cp65001
> at java.nio.charset.Charset.forName(Unknown Source)
> at 
> org.apache.logging.log4j.util.PropertiesUtil.getCharsetProperty(PropertiesUtil.java:172)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target.getCharset(ConsoleAppender.java:89)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target$1.getDefaultCharset(ConsoleAppender.java:74)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:222)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:189)
> at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:958)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:898)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:890)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:513)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:237)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:249)
> at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:545)
> at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617)
> at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
> at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
> at de.duerr.fitnesse.RunRabbitRun.(RunRabbitRun.java:24)
> 11:37:19.176 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - Passed over first 
> parameter: start
> 11:37:19.192 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - Passed over 
> Fitnesse directory: ./Resources
> 11:37:19.192 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - The parameters 
> handed over to Fitnesse: -d
> 11:37:19.192 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - The parameters 
> handed over to Fitnesse: ./Resources
> 11:37:19.192 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - The parameters 
> handed over to Fitnesse: -r
> 11:37:19.192 [main] DEBUG de.duerr.fitnesse.RunRabbitRun - 

[jira] [Commented] (LOG4J2-2053) Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16195319#comment-16195319
 ] 

Gary Gregory commented on LOG4J2-2053:
--

Hi.

The reason I offered the link to the ICU project is that a project could add 
ICU to its classpath to pick up additional encodings. BUT in this case, using 
ICU would not help since there is no "cp65001" aliased to "UTF-8" or to _any_ 
other encoding. This leads me to suggest a mapping file. We would include such 
a file in the code jar by default. The file could be overriden by a user by 
placing his own earlier on the classpath. Or we could come up with a different 
configuration mechanism. 

I will attach a super simple default file (or maybe put it in the resource 
folder), which you can feel free to add to through a patch or GitHub... 
forthcoming...

Gary

> Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
> 
>
> Key: LOG4J2-2053
> URL: https://issues.apache.org/jira/browse/LOG4J2-2053
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: Windows 10x64 1607 German
> Java JDK 1.8.0_144 (JAVA_TOOL_OPTIONS=-Dsun.jnu.encoding=UTF8 
> -Dfile.encoding=UTF8 -Ds=0)
> Fitnesse 20161106
> Log4j 2.9.0
> Executing from command line, switching to chcp 65001
>Reporter: Frank Steudle
>Priority: Minor
>
> Today I updated my fitnesse project to use the 2.9.0 versions of log4-core 
> and log4j-api. Now I am encountering the exception 
> java.nio.charset.UnsupportedCharsetException: cp65001. 
> However, my project is running well. Logging seems to work anyway.
> According to Issue 1888, there was a similar bug, which was fixed in 2.9.0: 
> [https://issues.apache.org/jira/browse/LOG4J2-1888]. I commented it, but 
> didn't get an answer until now.
> I am using ISO-8859-1 on my Eclipse computer to store the files. But the 
> execution environment is plain UTF-8. Therefore I am using those parameters 
> to run my fitnesse project:
> * -Dsun.jnu.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * -Dfile.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * chcp 65001: to switch the Windows console encoding to UTF8
> Here is the exception, which is thrown: 
> {code:java}
> C:\Users\admin\Desktop\RabbitDevInstall\Testtool>java -jar 
> RunRabbitRun-2.0-SNAPSHOT-jar-with-dependencies.jar start ./Resources
> Picked up JAVA_TOOL_OPTIONS: -Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8 
> -Ds=0
> Unable to get Charset 'sun.stdout.encoding', using default UTF-8
> java.nio.charset.UnsupportedCharsetException: cp65001
> at java.nio.charset.Charset.forName(Unknown Source)
> at 
> org.apache.logging.log4j.util.PropertiesUtil.getCharsetProperty(PropertiesUtil.java:172)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target.getCharset(ConsoleAppender.java:89)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target$1.getDefaultCharset(ConsoleAppender.java:74)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:222)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:189)
> at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:958)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:898)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:890)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:513)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:237)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:249)
> at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:545)
> at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617)
> at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
> at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> at 

[jira] [Comment Edited] (LOG4J2-2053) Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16191434#comment-16191434
 ] 

Gary Gregory edited comment on LOG4J2-2053 at 10/4/17 7:59 PM:
---

The message emitted by log4j says: 

{quote}
Unable to get Charset 'sun.stdout.encoding', using default UTF-8
{quote}

I've improved the message in git master to read:

{quote}
"Unable to get Charset 'cp65001' for property 'sun.stdout.encoding', using 
default UTF-8 and continuing."
{quote}

When you set the active console's code page with {{chcp}} to {{65001}}, Java 
does not know that this maps to UTF-8. So it tries to use {{cp65001}} as the 
code page and fails since there is no such encoding name standardized. Note 
that not even the ICU project 
(https://ssl.icu-project.org/icu-bin/convexp?s=WINDOWS=ALL) maps the name 
{{cp65001}}, but there is mapping in ICU from {{windows-65001}} to {{UTF-8}}.

Options today:

- You can ignore this error since Log4j will continue working and use UTF-8 as 
the default, which happens to match what you want.
- You can set the system property {{sun.stdout.encoding}} to {{UTF-8}}.
- You can set the charset attribute on the layout to whatever charset name you 
want (but the default charset will still be queried)

The more general solution is to provide some handling for what to do when a 
user calls {{chcp}} to change to an encoding that is both not supported with 
the encoding name Java gives the chcp value AND UTF-8 is not the right value.

- We could change the query of the default charset to only take place if the 
layout's charset is not set. This could be done with a lambda or the equivalent 
Java 7 hack.
- We could add a properties file with some default mappings like {{cp65001 = 
UTF-8}} which would be used when an exception is caught calling 
Charset.forName(). We could then still log the exception but perhaps only at 
the WARN level.

Thoughts?



was (Author: garydgregory):
The message emitted by log4j says: 

{quote}
Unable to get Charset 'sun.stdout.encoding', using default UTF-8
{quote}

I've improved the message in git master to read:

{quote}
"Unable to get Charset 'cp65001' for property 'sun.stdout.encoding', using 
default UTF-8 and continuing."
{quote}

When you set the active console's code page with {{chcp}} to {{65001}}, Java 
does not know that this maps to UTF-8. So it tries to use {{cp65001}} as the 
code page and fails since there is no such encoding name standardized. Note 
that not even the ICU project 
(https://ssl.icu-project.org/icu-bin/convexp?s=WINDOWS=ALL) maps the name 
{{cp65001}}, but there is mapping in ICU from {{windows-65001}} to {{UTF-8}}.

What to do?

We could have an special Log4j mapping...

> Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
> 
>
> Key: LOG4J2-2053
> URL: https://issues.apache.org/jira/browse/LOG4J2-2053
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: Windows 10x64 1607 German
> Java JDK 1.8.0_144 (JAVA_TOOL_OPTIONS=-Dsun.jnu.encoding=UTF8 
> -Dfile.encoding=UTF8 -Ds=0)
> Fitnesse 20161106
> Log4j 2.9.0
> Executing from command line, switching to chcp 65001
>Reporter: Frank Steudle
>Priority: Minor
>
> Today I updated my fitnesse project to use the 2.9.0 versions of log4-core 
> and log4j-api. Now I am encountering the exception 
> java.nio.charset.UnsupportedCharsetException: cp65001. 
> However, my project is running well. Logging seems to work anyway.
> According to Issue 1888, there was a similar bug, which was fixed in 2.9.0: 
> [https://issues.apache.org/jira/browse/LOG4J2-1888]. I commented it, but 
> didn't get an answer until now.
> I am using ISO-8859-1 on my Eclipse computer to store the files. But the 
> execution environment is plain UTF-8. Therefore I am using those parameters 
> to run my fitnesse project:
> * -Dsun.jnu.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * -Dfile.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * chcp 65001: to switch the Windows console encoding to UTF8
> Here is the exception, which is thrown: 
> {code:java}
> C:\Users\admin\Desktop\RabbitDevInstall\Testtool>java -jar 
> RunRabbitRun-2.0-SNAPSHOT-jar-with-dependencies.jar start ./Resources
> Picked up JAVA_TOOL_OPTIONS: -Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8 
> -Ds=0
> Unable to get Charset 'sun.stdout.encoding', using default UTF-8
> java.nio.charset.UnsupportedCharsetException: cp65001
> at java.nio.charset.Charset.forName(Unknown Source)
> at 
> org.apache.logging.log4j.util.PropertiesUtil.getCharsetProperty(PropertiesUtil.java:172)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target.getCharset(ConsoleAppender.java:89)
> at 
> 

[jira] [Commented] (LOG4J2-2053) Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16191434#comment-16191434
 ] 

Gary Gregory commented on LOG4J2-2053:
--

The message emitted by log4j says: 

{quote}
Unable to get Charset 'sun.stdout.encoding', using default UTF-8
{quote}

I've improved the message in git master to read:

{quote}
"Unable to get Charset 'cp65001' for property 'sun.stdout.encoding', using 
default UTF-8 and continuing."
{quote}

When you set the active console's code page with {{chcp}} to {{65001}}, Java 
does not know that this maps to UTF-8. So it tries to use {{cp65001}} as the 
code page and fails since there is no such encoding name standardized. Note 
that not even the ICU project 
(https://ssl.icu-project.org/icu-bin/convexp?s=WINDOWS=ALL) maps the name 
{{cp65001}}, but there is mapping in ICU from {{windows-65001}} to {{UTF-8}}.

What to do?

We could have an special Log4j mapping...

> Exception java.nio.charset.UnsupportedCharsetException: cp65001 in 2.9.0
> 
>
> Key: LOG4J2-2053
> URL: https://issues.apache.org/jira/browse/LOG4J2-2053
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: Windows 10x64 1607 German
> Java JDK 1.8.0_144 (JAVA_TOOL_OPTIONS=-Dsun.jnu.encoding=UTF8 
> -Dfile.encoding=UTF8 -Ds=0)
> Fitnesse 20161106
> Log4j 2.9.0
> Executing from command line, switching to chcp 65001
>Reporter: Frank Steudle
>Priority: Minor
>
> Today I updated my fitnesse project to use the 2.9.0 versions of log4-core 
> and log4j-api. Now I am encountering the exception 
> java.nio.charset.UnsupportedCharsetException: cp65001. 
> However, my project is running well. Logging seems to work anyway.
> According to Issue 1888, there was a similar bug, which was fixed in 2.9.0: 
> [https://issues.apache.org/jira/browse/LOG4J2-1888]. I commented it, but 
> didn't get an answer until now.
> I am using ISO-8859-1 on my Eclipse computer to store the files. But the 
> execution environment is plain UTF-8. Therefore I am using those parameters 
> to run my fitnesse project:
> * -Dsun.jnu.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * -Dfile.encoding=UTF8: handed over as JAVA_TOOL_OPTIONS
> * chcp 65001: to switch the Windows console encoding to UTF8
> Here is the exception, which is thrown: 
> {code:java}
> C:\Users\admin\Desktop\RabbitDevInstall\Testtool>java -jar 
> RunRabbitRun-2.0-SNAPSHOT-jar-with-dependencies.jar start ./Resources
> Picked up JAVA_TOOL_OPTIONS: -Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8 
> -Ds=0
> Unable to get Charset 'sun.stdout.encoding', using default UTF-8
> java.nio.charset.UnsupportedCharsetException: cp65001
> at java.nio.charset.Charset.forName(Unknown Source)
> at 
> org.apache.logging.log4j.util.PropertiesUtil.getCharsetProperty(PropertiesUtil.java:172)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target.getCharset(ConsoleAppender.java:89)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Target$1.getDefaultCharset(ConsoleAppender.java:74)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:222)
> at 
> org.apache.logging.log4j.core.appender.ConsoleAppender$Builder.build(ConsoleAppender.java:189)
> at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:958)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:898)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:890)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:513)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:237)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:249)
> at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:545)
> at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617)
> at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
> at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at 

[jira] [Commented] (LOG4J2-2058) java.locale.providers set to HOST causes Log4j2 to crash in Java 9

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16190563#comment-16190563
 ] 

Gary Gregory commented on LOG4J2-2058:
--

FYI:

Applying this patch:
{noformat}
diff --git 
a/log4j-jul/src/test/java/org/apache/logging/log4j/jul/CoreLoggerTest.java 
b/log4j-jul/src/test/java/org/apache/logging/log4j/jul/CoreLoggerTest.java
index fbc17b2..6623c98 100644
--- a/log4j-jul/src/test/java/org/apache/logging/log4j/jul/CoreLoggerTest.java
+++ b/log4j-jul/src/test/java/org/apache/logging/log4j/jul/CoreLoggerTest.java
@@ -37,11 +37,13 @@
 
 @BeforeClass
 public static void setUpClass() {
+System.setProperty("java.locale.providers", "HOST,JRE,SPI");
 System.setProperty("java.util.logging.manager", 
LogManager.class.getName());
 }
 
 @AfterClass
 public static void tearDownClass() {
+System.clearProperty("java.locale.providers");
 System.clearProperty("java.util.logging.manager");
 }
 {noformat} 

and running {{mvn clean test -pl log4j-jul}} passes.

> java.locale.providers set to HOST causes Log4j2 to crash in Java 9
> --
>
> Key: LOG4J2-2058
> URL: https://issues.apache.org/jira/browse/LOG4J2-2058
> Project: Log4j 2
>  Issue Type: Bug
>  Components: JUL adapter, Pattern Converters
>Affects Versions: 2.9.0, 2.9.1
> Environment: Windows 10, Java 9
>Reporter: Dean Wookey
>Priority: Blocker
>
> When using the JUL log manager, setting the java.locale.providers property to 
> "HOST" causes log4j2 to crash when you next log something. 
> {code:java}
> public class LocalePropertyTest {
> /**
>  * @param args the command line arguments
>  */
> public static void main(String[] args) {
> System.setProperty("java.locale.providers", "HOST,JRE,SPI");
> System.setProperty("java.util.logging.manager", 
> "org.apache.logging.log4j.jul.LogManager");
> 
> Logger.getLogger(LocalePropertyTest.class.getName()).log(Level.WARNING, "this 
> is a test");
> }
> }
> {code}
> The error is very long. Here are the first few lines:
> ERROR StatusLogger Error creating converter for d
>  java.lang.reflect.InvocationTargetException
>   at jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:564)
>   at 
> org.apache.logging.log4j.core.pattern.PatternParser.createConverter(PatternParser.java:582)
>   at 
> org.apache.logging.log4j.core.pattern.PatternParser.finalizeConverter(PatternParser.java:638)
>   at 
> org.apache.logging.log4j.core.pattern.PatternParser.parse(PatternParser.java:414)
>   at 
> org.apache.logging.log4j.core.pattern.PatternParser.parse(PatternParser.java:177)
>   at 
> org.apache.logging.log4j.core.layout.PatternLayout$SerializerBuilder.build(PatternLayout.java:376)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (LOG4J2-2058) java.locale.providers set to HOST causes Log4j2 to crash in Java 9

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-2058:
-
Comment: was deleted

(was: What do your imports look like? Are you intending to use the Log4j 1 API 
instead of 2?)

> java.locale.providers set to HOST causes Log4j2 to crash in Java 9
> --
>
> Key: LOG4J2-2058
> URL: https://issues.apache.org/jira/browse/LOG4J2-2058
> Project: Log4j 2
>  Issue Type: Bug
>  Components: JUL adapter, Pattern Converters
>Affects Versions: 2.9.0, 2.9.1
> Environment: Windows 10, Java 9
>Reporter: Dean Wookey
>Priority: Blocker
>
> When using the JUL log manager, setting the java.locale.providers property to 
> "HOST" causes log4j2 to crash when you next log something. 
> {code:java}
> public class LocalePropertyTest {
> /**
>  * @param args the command line arguments
>  */
> public static void main(String[] args) {
> System.setProperty("java.locale.providers", "HOST,JRE,SPI");
> System.setProperty("java.util.logging.manager", 
> "org.apache.logging.log4j.jul.LogManager");
> 
> Logger.getLogger(LocalePropertyTest.class.getName()).log(Level.WARNING, "this 
> is a test");
> }
> }
> {code}
> The error is very long. Here are the first few lines:
> ERROR StatusLogger Error creating converter for d
>  java.lang.reflect.InvocationTargetException
>   at jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:564)
>   at 
> org.apache.logging.log4j.core.pattern.PatternParser.createConverter(PatternParser.java:582)
>   at 
> org.apache.logging.log4j.core.pattern.PatternParser.finalizeConverter(PatternParser.java:638)
>   at 
> org.apache.logging.log4j.core.pattern.PatternParser.parse(PatternParser.java:414)
>   at 
> org.apache.logging.log4j.core.pattern.PatternParser.parse(PatternParser.java:177)
>   at 
> org.apache.logging.log4j.core.layout.PatternLayout$SerializerBuilder.build(PatternLayout.java:376)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2058) java.locale.providers set to HOST causes Log4j2 to crash in Java 9

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16190556#comment-16190556
 ] 

Gary Gregory commented on LOG4J2-2058:
--

What do your imports look like? Are you intending to use the Log4j 1 API 
instead of 2?

> java.locale.providers set to HOST causes Log4j2 to crash in Java 9
> --
>
> Key: LOG4J2-2058
> URL: https://issues.apache.org/jira/browse/LOG4J2-2058
> Project: Log4j 2
>  Issue Type: Bug
>  Components: JUL adapter, Pattern Converters
>Affects Versions: 2.9.0, 2.9.1
> Environment: Windows 10, Java 9
>Reporter: Dean Wookey
>Priority: Blocker
>
> When using the JUL log manager, setting the java.locale.providers property to 
> "HOST" causes log4j2 to crash when you next log something. 
> {code:java}
> public class LocalePropertyTest {
> /**
>  * @param args the command line arguments
>  */
> public static void main(String[] args) {
> System.setProperty("java.locale.providers", "HOST,JRE,SPI");
> System.setProperty("java.util.logging.manager", 
> "org.apache.logging.log4j.jul.LogManager");
> 
> Logger.getLogger(LocalePropertyTest.class.getName()).log(Level.WARNING, "this 
> is a test");
> }
> }
> {code}
> The error is very long. Here are the first few lines:
> ERROR StatusLogger Error creating converter for d
>  java.lang.reflect.InvocationTargetException
>   at jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:564)
>   at 
> org.apache.logging.log4j.core.pattern.PatternParser.createConverter(PatternParser.java:582)
>   at 
> org.apache.logging.log4j.core.pattern.PatternParser.finalizeConverter(PatternParser.java:638)
>   at 
> org.apache.logging.log4j.core.pattern.PatternParser.parse(PatternParser.java:414)
>   at 
> org.apache.logging.log4j.core.pattern.PatternParser.parse(PatternParser.java:177)
>   at 
> org.apache.logging.log4j.core.layout.PatternLayout$SerializerBuilder.build(PatternLayout.java:376)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-1896) Update classes in org.apache.logging.log4j.core.net.ssl in APIs from String to char[] for passwords

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16180851#comment-16180851
 ] 

Gary Gregory commented on LOG4J2-1896:
--

The SSL and JMS CMs count on being able to reuse the password to reconnect IIRC.

> Update classes in org.apache.logging.log4j.core.net.ssl in APIs from String 
> to char[] for passwords
> ---
>
> Key: LOG4J2-1896
> URL: https://issues.apache.org/jira/browse/LOG4J2-1896
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Configurators
>Reporter: Gary Gregory
>Assignee: Remko Popma
> Fix For: 2.10.0
>
>
> Update {{org.apache.logging.log4j.core.net.ssl.StoreConfiguration}} from a 
> {{String}} to {{char[]}} to represent its password.
> The goal is to reduce the security risk of using a String for a password. See 
> https://stackoverflow.com/questions/8881291/why-is-char-preferred-over-string-for-passwords



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2056) Modularize Log4j as automatic modules

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178222#comment-16178222
 ] 

Gary Gregory commented on LOG4J2-2056:
--

I kind of like the dot matching the dash in "to.foo"

> Modularize Log4j as automatic modules
> -
>
> Key: LOG4J2-2056
> URL: https://issues.apache.org/jira/browse/LOG4J2-2056
> Project: Log4j 2
>  Issue Type: New Feature
>Affects Versions: 2.9.1
>Reporter: Ralph Goers
>Assignee: Ralph Goers
>
> To fully support Java 9 all Log4j jars must (at least) be packaged as 
> automatic modules. We should, as much as possible, follow the recommendations 
> at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given 
> that the module names would be:
> ||Jar name||Module name||
> |log4j-api|org.apache.logging.log4j|
> |log4j-core|org.apache.logging.log4j.impl|
> |log4j-1.2-api|org.apache.log4j|
> |log4j-appserver|org.apache.logging.log4j.appserver|
> |log4j-flume-ng|org.apache.logging.log4j.flume|
> |log4j-iostreams|org.apache.logging.log4j.iostreams|
> |log4j-jcl|org.apache.logging.log4j.jcl|
> |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui|
> |log4j-jul|org.apache.logging.log4j.jul|
> |log4j-liquibase|org.apache.logging.log4j.liquibase|
> |log4j-nosql|org.apache.logging.log4j.nosql|
> |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*|
> |log4j-to-slf4j|org.apache.logging.log4j.toslf4j|
> |log4j-taglib|org.apache.logging.log4j.taglib|
> |log4j-web|org.apache.logging.log4j.web|
> # Notably missing is log4j-osgi. Until OSGi documents how it will support 
> Java 9 I see no point in modularizing the OSGi jar.
> # log4j-slf4j-impl cannot currently be modularized until the binding is 
> modified. It cannot have classes in the org.slf4j namespace.
> # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - 
> org.apache.logging.log4j.slf4j. This will remain the same as it will prevent 
> them both from being loaded at the same time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2054) Provide alternatives to configuring SecureSocketAppender that avoid plain-text passwords in config

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16178006#comment-16178006
 ] 

Gary Gregory commented on LOG4J2-2054:
--

Do we want to go as far as having a generic SecretProvider so we can have 
SecretProvider and SecretProvider?

> Provide alternatives to configuring SecureSocketAppender that avoid 
> plain-text passwords in config
> --
>
> Key: LOG4J2-2054
> URL: https://issues.apache.org/jira/browse/LOG4J2-2054
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.9.1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.10.0
>
>
> Following up on LOG4J2-1896, currently SecureSocketAppender can only be 
> configured by specifying the passwords to the trust store and the key store 
> in plain text in the log4j 2 configuration file.
> Provide alternative configurations that obtain the password from different 
> sources, for example:
> * system environment variable
> * file
> Example configuration:
> {noformat}
>   
>  port="${sys:SecureSocketAppenderSocketOptionsTest.port}" protocol="SSL"
>   ignoreExceptions="false">
>   
>reuseAddress="false" rfc1349TrafficClass="IPTOS_LOWCOST"
> sendBufferSize="8000" soLinger="12345" soTimeout="54321" 
> tcpNoDelay="false">
>  latency="100" />
>   
>   
>  location="src/test/resources/org/apache/logging/log4j/core/net/ssl/client.log4j2-keystore.jks"
>   passwordEnvironmentVariable="KEYSTORE_PASSWORD" type="JKS" />
>  location="src/test/resources/org/apache/logging/log4j/core/net/ssl/truststore.jks"
>   passwordFile="${sys:user.home}/truststore.pwd" type="JKS" />
>   
> 
>   
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2054) Provide alternatives to configuring SecureSocketAppender that avoid plain-text passwords in config

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16177919#comment-16177919
 ] 

Gary Gregory commented on LOG4J2-2054:
--

I do not think so. Java works with KeyStore/TrustStore, I am not sure if you 
can plugin something below that, but maybe through the "providers". Which is 
why it is important to allow configuration of providers. I think. There also 
the Windows vault...

> Provide alternatives to configuring SecureSocketAppender that avoid 
> plain-text passwords in config
> --
>
> Key: LOG4J2-2054
> URL: https://issues.apache.org/jira/browse/LOG4J2-2054
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.9.1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.10.0
>
>
> Following up on LOG4J2-1896, currently SecureSocketAppender can only be 
> configured by specifying the passwords to the trust store and the key store 
> in plain text in the log4j 2 configuration file.
> Provide alternative configurations that obtain the password from different 
> sources, for example:
> * system environment variable
> * file
> Example configuration:
> {noformat}
>   
>  port="${sys:SecureSocketAppenderSocketOptionsTest.port}" protocol="SSL"
>   ignoreExceptions="false">
>   
>reuseAddress="false" rfc1349TrafficClass="IPTOS_LOWCOST"
> sendBufferSize="8000" soLinger="12345" soTimeout="54321" 
> tcpNoDelay="false">
>  latency="100" />
>   
>   
>  location="src/test/resources/org/apache/logging/log4j/core/net/ssl/client.log4j2-keystore.jks"
>   passwordEnvironmentVariable="KEYSTORE_PASSWORD" type="JKS" />
>  location="src/test/resources/org/apache/logging/log4j/core/net/ssl/truststore.jks"
>   passwordFile="${sys:user.home}/truststore.pwd" type="JKS" />
>   
> 
>   
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2054) Provide alternatives to configuring SecureSocketAppender that avoid plain-text passwords in config

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16177871#comment-16177871
 ] 

Gary Gregory commented on LOG4J2-2054:
--

Passwords could also be fetched from Maven's password vault.

> Provide alternatives to configuring SecureSocketAppender that avoid 
> plain-text passwords in config
> --
>
> Key: LOG4J2-2054
> URL: https://issues.apache.org/jira/browse/LOG4J2-2054
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.9.1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.10.0
>
>
> Following up on LOG4J2-1896, currently SecureSocketAppender can only be 
> configured by specifying the passwords to the trust store and the key store 
> in plain text in the log4j 2 configuration file.
> Provide alternative configurations that obtain the password from different 
> sources, for example:
> * system environment variable
> * file
> Example configuration:
> {noformat}
>   
>  port="${sys:SecureSocketAppenderSocketOptionsTest.port}" protocol="SSL"
>   ignoreExceptions="false">
>   
>reuseAddress="false" rfc1349TrafficClass="IPTOS_LOWCOST"
> sendBufferSize="8000" soLinger="12345" soTimeout="54321" 
> tcpNoDelay="false">
>  latency="100" />
>   
>   
>  location="src/test/resources/org/apache/logging/log4j/core/net/ssl/client.log4j2-keystore.jks"
>   passwordEnvironmentVariable="KEYSTORE_PASSWORD" type="JKS" />
>  location="src/test/resources/org/apache/logging/log4j/core/net/ssl/truststore.jks"
>   passwordFile="${sys:user.home}/truststore.pwd" type="JKS" />
>   
> 
>   
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (LOG4J2-2051) Update Conversant Disruptor from 1.2.10 to 1.2.11.

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16168945#comment-16168945
 ] 

Gary Gregory edited comment on LOG4J2-2051 at 9/16/17 3:18 PM:
---

I guess. We could also create a Java 8 JIRA "Epic". Or a Java 8 JIRA with this 
one as the first subtask. Note that I labeled this ticket "Java8".


was (Author: garydgregory):
I guess. We could also create a Java 8 JIRA "Epic". Or a Java 8 JIRA with this 
one as the first subtask.

> Update Conversant Disruptor from 1.2.10 to 1.2.11.
> --
>
> Key: LOG4J2-2051
> URL: https://issues.apache.org/jira/browse/LOG4J2-2051
> Project: Log4j 2
>  Issue Type: Improvement
>Affects Versions: 2.9.0
>Reporter: Gary Gregory
>  Labels: Java8
>
> Update Convertant Disruptor from 1.2.10 to 1.2.11.
> This requires Java 8. Java 7 is only supported in 1.2.10 and below.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2051) Update Conversant Disruptor from 1.2.10 to 1.2.11.

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16168945#comment-16168945
 ] 

Gary Gregory commented on LOG4J2-2051:
--

I guess. We could also create a Java 8 JIRA "Epic". Or a Java 8 JIRA with this 
one as the first subtask.

> Update Conversant Disruptor from 1.2.10 to 1.2.11.
> --
>
> Key: LOG4J2-2051
> URL: https://issues.apache.org/jira/browse/LOG4J2-2051
> Project: Log4j 2
>  Issue Type: Improvement
>Affects Versions: 2.9.0
>Reporter: Gary Gregory
>  Labels: Java8
>
> Update Convertant Disruptor from 1.2.10 to 1.2.11.
> This requires Java 8. Java 7 is only supported in 1.2.10 and below.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LOG4J2-2051) Update Conversant Disruptor from 1.2.10 to 1.2.11.

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-2051:
-
Labels: Java8  (was: )

> Update Conversant Disruptor from 1.2.10 to 1.2.11.
> --
>
> Key: LOG4J2-2051
> URL: https://issues.apache.org/jira/browse/LOG4J2-2051
> Project: Log4j 2
>  Issue Type: Improvement
>Affects Versions: 2.9.0
>Reporter: Gary Gregory
>  Labels: Java8
>
> Update Convertant Disruptor from 1.2.10 to 1.2.11.
> This requires Java 8. Java 7 is only supported in 1.2.10 and below.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LOG4J2-2051) Update Conversant Disruptor from 1.2.10 to 1.2.11.

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-2051:
-
Description: 
Update Convertant Disruptor from 1.2.10 to 1.2.11.

This requires Java 8. Java 7 is only supported in 1.2.10 and below.

  was:Update Convertant Disruptor from 1.2.10 to 1.2.11.


> Update Conversant Disruptor from 1.2.10 to 1.2.11.
> --
>
> Key: LOG4J2-2051
> URL: https://issues.apache.org/jira/browse/LOG4J2-2051
> Project: Log4j 2
>  Issue Type: Improvement
>Affects Versions: 2.9.0
>Reporter: Gary Gregory
>
> Update Convertant Disruptor from 1.2.10 to 1.2.11.
> This requires Java 8. Java 7 is only supported in 1.2.10 and below.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (LOG4J2-2051) Update Convertant Disruptor from 1.2.10 to 1.2.11.

[Gary Gregory (JIRA)]

Gary Gregory created LOG4J2-2051:


 Summary: Update Convertant Disruptor from 1.2.10 to 1.2.11.
 Key: LOG4J2-2051
 URL: https://issues.apache.org/jira/browse/LOG4J2-2051
 Project: Log4j 2
  Issue Type: Improvement
Affects Versions: 2.9.0
Reporter: Gary Gregory


Update Convertant Disruptor from 1.2.10 to 1.2.11.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LOG4J2-2051) Update Conversant Disruptor from 1.2.10 to 1.2.11.

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-2051:
-
Summary: Update Conversant Disruptor from 1.2.10 to 1.2.11.  (was: Update 
Convertant Disruptor from 1.2.10 to 1.2.11.)

> Update Conversant Disruptor from 1.2.10 to 1.2.11.
> --
>
> Key: LOG4J2-2051
> URL: https://issues.apache.org/jira/browse/LOG4J2-2051
> Project: Log4j 2
>  Issue Type: Improvement
>Affects Versions: 2.9.0
>Reporter: Gary Gregory
>
> Update Convertant Disruptor from 1.2.10 to 1.2.11.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2050) NullPointerException in LogManager.getLogger when called from anonymous class initializer

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16166192#comment-16166192
 ] 

Gary Gregory commented on LOG4J2-2050:
--

That question does come up regularly, but we should make clear that SNAPSHOT 
builds have their caveats. 

> NullPointerException in LogManager.getLogger when called from anonymous class 
> initializer
> -
>
> Key: LOG4J2-2050
> URL: https://issues.apache.org/jira/browse/LOG4J2-2050
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.9.0
>Reporter: Mark Arnold
>Priority: Critical
> Fix For: 2.9.1
>
> Attachments: LibraryTest.java, SomeInterface.java
>
>
> I observed a NullPointerException when calling LogManager.getLogger in the 
> initializer block of an anonymous class, like so:
> {code:java}
>   SomeInterface _t = new SomeInterface() {
>   Logger log = LogManager.getLogger();
>   @Override
>   public String someMethod() {
>   log.info("Logging...");
>   return "";
>   }
>   };
> {code}
> This did work fine in 2.8.2, but 2.9.0 gets an NPE:
> {noformat}
> java.lang.NullPointerException
>   at 
> java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
>   at 
> org.apache.logging.log4j.spi.LoggerRegistry.getLogger(LoggerRegistry.java:125)
>   at 
> org.apache.logging.log4j.core.LoggerContext.getLogger(LoggerContext.java:447)
>   at 
> org.apache.logging.log4j.core.LoggerContext.getLogger(LoggerContext.java:420)
>   at 
> org.apache.logging.log4j.core.LoggerContext.getLogger(LoggerContext.java:60)
>   at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
>   at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:537)
>   at LibraryTest$1.(LibraryTest.java:11)
>   at 
> LibraryTest.testGetLoggerFromAnonymousInnerClass_inInitializer(LibraryTest.java:10)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> {noformat}
> The error does not occur when I move the call of LogManager.getLogger() down 
> inside of 
> someMethod(). It only happens when called from the initializer block.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (LOG4J2-2049) Update Apache Kafka Client from 0.11.0.0 to 0.11.0.1

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-2049.

   Resolution: Fixed
Fix Version/s: 2.9.1

Closing: In git master.

> Update Apache Kafka Client from 0.11.0.0 to 0.11.0.1
> 
>
> Key: LOG4J2-2049
> URL: https://issues.apache.org/jira/browse/LOG4J2-2049
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.9.0
>Reporter: Gary Gregory
> Fix For: 2.9.1
>
>
> Update Apache Kafka Client from 0.11.0.0 to 0.11.0.1.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (LOG4J2-2049) Update Apache Kafka Client from 0.11.0.0 to 0.11.0.1

[Gary Gregory (JIRA)]

Gary Gregory created LOG4J2-2049:


 Summary: Update Apache Kafka Client from 0.11.0.0 to 0.11.0.1
 Key: LOG4J2-2049
 URL: https://issues.apache.org/jira/browse/LOG4J2-2049
 Project: Log4j 2
  Issue Type: Bug
  Components: Appenders
Affects Versions: 2.9.0
Reporter: Gary Gregory


Update Apache Kafka Client from 0.11.0.0 to 0.11.0.1.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (LOG4J2-2047) Update Cassandra driver from 3.1.0 to 3.1.4

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-2047.

   Resolution: Fixed
Fix Version/s: 2.9.1

Closing: In Git master.

> Update Cassandra driver from 3.1.0 to 3.1.4
> ---
>
> Key: LOG4J2-2047
> URL: https://issues.apache.org/jira/browse/LOG4J2-2047
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.9.0
>Reporter: Gary Gregory
> Fix For: 2.9.1
>
>
> Update Cassandra driver from 3.1.0 to 3.1.4.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (LOG4J2-2047) Update Cassandra driver from 3.1.0 to 3.1.4

[Gary Gregory (JIRA)]

Gary Gregory created LOG4J2-2047:


 Summary: Update Cassandra driver from 3.1.0 to 3.1.4
 Key: LOG4J2-2047
 URL: https://issues.apache.org/jira/browse/LOG4J2-2047
 Project: Log4j 2
  Issue Type: Improvement
  Components: Appenders
Affects Versions: 2.9.0
Reporter: Gary Gregory


Update Cassandra driver from 3.1.0 to 3.1.4.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (LOG4J2-2046) Update Apache Commons Compress from 1.13 to 1.14

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-2046.

   Resolution: Fixed
Fix Version/s: 2.9.1

In git master.

> Update Apache Commons Compress from 1.13 to 1.14
> 
>
> Key: LOG4J2-2046
> URL: https://issues.apache.org/jira/browse/LOG4J2-2046
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.9.0
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.9.1
>
>
> Update Apache Commons Compress from 1.13 to 1.14.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (LOG4J2-2045) Update javax.mail from 1.5.6 to 1.6.0

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-2045.

   Resolution: Fixed
Fix Version/s: 2.9.1

Closing: In git master.

> Update javax.mail from 1.5.6 to 1.6.0
> -
>
> Key: LOG4J2-2045
> URL: https://issues.apache.org/jira/browse/LOG4J2-2045
> Project: Log4j 2
>  Issue Type: Improvement
>Affects Versions: 2.9.0
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.9.1
>
>
> Update javax.mail from 1.5.6 to 1.6.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (LOG4J2-2044) Update Apache Commons CSV from 1.4 to 1.5

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-2044.

Resolution: Cannot Reproduce

Closing: In git master.

> Update Apache Commons CSV from 1.4 to 1.5
> -
>
> Key: LOG4J2-2044
> URL: https://issues.apache.org/jira/browse/LOG4J2-2044
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Layouts
>Affects Versions: 2.9.0
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.9.1
>
>
> Update Apache Commons CSV from 1.4 to 1.5.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (LOG4J2-2043) Update Jackson from 2.9.0 to 2.9.1 (fix for Java 9)

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved LOG4J2-2043.
--
Resolution: Fixed

Closing: In git master.

> Update Jackson from 2.9.0 to 2.9.1 (fix for Java 9)
> ---
>
> Key: LOG4J2-2043
> URL: https://issues.apache.org/jira/browse/LOG4J2-2043
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.9.0
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.9.1
>
>
> Update Jackson from 2.9.0 to 2.9.1.
> Fix for Java 9: #397: Add `Automatic-Module-Name` 
> ("com.fasterxml.jackson.core") for JDK 9 module system



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (LOG4J2-2044) Update Apache Commons CSV from 1.4 to 1.5

[Gary Gregory (JIRA)]

Gary Gregory created LOG4J2-2044:


 Summary: Update Apache Commons CSV from 1.4 to 1.5
 Key: LOG4J2-2044
 URL: https://issues.apache.org/jira/browse/LOG4J2-2044
 Project: Log4j 2
  Issue Type: Improvement
  Components: Layouts
Affects Versions: 2.9.0
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 2.9.1


Update Apache Commons CSV from 1.4 to 1.5.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (LOG4J2-2043) Update Jackson from 2.9.0 to 2.9.1 (fix for Java 9)

[Gary Gregory (JIRA)]

Gary Gregory created LOG4J2-2043:


 Summary: Update Jackson from 2.9.0 to 2.9.1 (fix for Java 9)
 Key: LOG4J2-2043
 URL: https://issues.apache.org/jira/browse/LOG4J2-2043
 Project: Log4j 2
  Issue Type: Improvement
  Components: Appenders
Affects Versions: 2.9.0
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 2.9.1


Update Jackson from 2.9.0 to 2.9.1.

Fix for Java 9: #397: Add `Automatic-Module-Name` 
("com.fasterxml.jackson.core") for JDK 9 module system



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LOG4J2-2031) Log4j2 log file not reflecting application log function calls

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-2031:
-
Fix Version/s: (was: 2.9.1)

> Log4j2 log file not reflecting application log function calls
> -
>
> Key: LOG4J2-2031
> URL: https://issues.apache.org/jira/browse/LOG4J2-2031
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.8.2, 2.9.0
> Environment: Windows, Sun Java 8.
>Reporter: Colin McDowell
> Attachments: CapacityTest.java, log4j2.xml, pom2.xml
>
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> Was hoping to move our numerous J2EE projects from Log4j to Log4j2 for the 
> performance improvements.  I put together a small test case that writes a 
> string pattern to a Rolling File.  There is a 6 digit sequence number at the 
> start of the log message.  This allows me to quickly see if all the log 
> requests are making it into the log file. I attach the test case and 
> log4j2.xml.  The log4j2.xml uses an asynchronous appender.
> What I observe in the output log file is that after a short interval (120 or 
> so entries) the logged are appearing in the wrong order, and entries can be 
> missing.  The missing entries issues especially shows up when rolling to the 
> next log file.
> Perhaps there is a deliberate decision to not to guarantee log file 
> accurately for speed.  However we need the logs to accurately reflect what 
> the application is logging.  I have also noticed the performance is 25% worse 
> in Log4j2 than Log4j when not using the asynchronous appender.  So that 
> rather kills us using Log4j2 at the moment.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (LOG4J2-2030) ClassCastException: org.apache.logging.log4j.simple.SimpleLoggerContext cannot be cast to org.apache.logging.log4j.core.LoggerContext

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16154149#comment-16154149
 ] 

Gary Gregory edited comment on LOG4J2-2030 at 9/5/17 7:21 PM:
--

This is the stack trace where Log4jInvoker, simply doing a 
Configurator.setLevel(), is loaded from an isolated classloader, containing 
log4j jars. Otherwise there is no log4j jlibs part of the classpath.

{noformat}
Caused by: java.lang.ClassCastException: 
org.apache.logging.log4j.simple.SimpleLoggerContext cannot be cast to 
org.apache.logging.log4j.core.LoggerContext
at 
org.apache.logging.log4j.core.LoggerContext.getContext(LoggerContext.java:190)
at 
org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:291)
at com.util.Log4jInvoker.doIt(Log4jInvoker.java:11)
{noformat}

The point is that the ServiceLoader doesn't find the ServiceProvider, then the 
search is still performed with the PROVIDER_RESOURCE on each classloader, 
including the URLClassloader above, but the PROVIDER_RESOURCE is missing in 
2.9.0 jar. 
Wondering if same ServiceLoader should be performed on each "candidates" rather 
than this getResources.

{noformat}
private ProviderUtil() {
loadProviders(findClassLoader());
for (final LoaderUtil.UrlResource resource : 
LoaderUtil.findUrlResources(PROVIDER_RESOURCE)) {
loadProvider(resource.getUrl(), resource.getClassLoader());
}
}

   final ClassLoader[] candidates = {getThreadContextClassLoader(), 
*LoaderUtil.class.getClassLoader()*,
GET_CLASS_LOADER_DISABLED ? null : 
ClassLoader.getSystemClassLoader()};
{noformat}



 


was (Author: jncharpin):
This is the stack trace where Log4jInvoker, simply doing a 
Configurator.setLevel(), is loaded from an isolated classloader, containing 
log4j jars. Otherwise there is no log4j jlibs part of the classpath.

{{Caused by: java.lang.ClassCastException: 
org.apache.logging.log4j.simple.SimpleLoggerContext cannot be cast to 
org.apache.logging.log4j.core.LoggerContext
at 
org.apache.logging.log4j.core.LoggerContext.getContext(LoggerContext.java:190)
at 
org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:291)
at com.util.Log4jInvoker.doIt(Log4jInvoker.java:11)}}

The point is that the ServiceLoader doesn't find the ServiceProvider, then the 
search is still performed with the PROVIDER_RESOURCE on each classloader, 
including the URLClassloader above, but the PROVIDER_RESOURCE is missing in 
2.9.0 jar. 
Wondering if same ServiceLoader should be performed on each "candidates" rather 
than this getResources.

 {{private ProviderUtil() {
loadProviders(findClassLoader());
for (final LoaderUtil.UrlResource resource : 
LoaderUtil.findUrlResources(PROVIDER_RESOURCE)) {
loadProvider(resource.getUrl(), resource.getClassLoader());
}
}

   final ClassLoader[] candidates = {getThreadContextClassLoader(), 
*LoaderUtil.class.getClassLoader()*,
GET_CLASS_LOADER_DISABLED ? null : 
ClassLoader.getSystemClassLoader()};
}}



 

> ClassCastException: org.apache.logging.log4j.simple.SimpleLoggerContext 
> cannot be cast to org.apache.logging.log4j.core.LoggerContext
> -
>
> Key: LOG4J2-2030
> URL: https://issues.apache.org/jira/browse/LOG4J2-2030
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.9.0
>Reporter: jncharpin
>
> When upgrading from 2.8.2 to 2.9.0, we are facing the following exception 
> when accessing the context.
> Caused by: java.lang.ClassCastException: 
> org.apache.logging.log4j.simple.SimpleLoggerContext cannot be cast to 
> org.apache.logging.log4j.core.LoggerContext
>   at 
> org.apache.logging.log4j.core.LoggerContext.getContext(LoggerContext.java:190)
>   at 
> org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:291)
> Seems like that the context factory is incorrect and defaulted to 
> {{SimpleLoggerContextFactory}} because of the provider is not able to find 
> the resource {{META-INF/log4j-provider.properties}} which is missing in 2.9.0 
> if not wrong.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (LOG4J2-1936) ClassNotFoundException when making all loggers asynchronous under OSGi environment

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved LOG4J2-1936.
--
   Resolution: Fixed
Fix Version/s: 2.9.1

In Git master. Please verify and close if it works in your set up. Thank you!

> ClassNotFoundException when making all loggers asynchronous under OSGi 
> environment
> --
>
> Key: LOG4J2-1936
> URL: https://issues.apache.org/jira/browse/LOG4J2-1936
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.8.2
> Environment: Windows 10
> Eclipse 4.4
> JDK 1.8.0_102
>Reporter: Helber Belmiro
>Priority: Blocker
>  Labels: bug
> Fix For: 2.9.1
>
> Attachments: patch.diff
>
>
> Can't find AsyncLoggerContextSelector when making all Log4j loggers 
> asynchronous on an OSGi environment.
> {noformat}
> java.lang.ClassNotFoundException: 
> org.apache.logging.log4j.core.async.AsyncLoggerContextSelector cannot be 
> found by org.apache.logging.log4j.api_2.8.2
> at 
> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:432)
> at 
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:345)
> at 
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:337)
> at 
> org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.apache.logging.log4j.util.LoaderUtil.loadClass(LoaderUtil.java:141)
> at 
> org.apache.logging.log4j.util.LoaderUtil.newInstanceOf(LoaderUtil.java:180)
> at 
> org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOf(LoaderUtil.java:201)
> at 
> org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOfProperty(LoaderUtil.java:226)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.createContextSelector(Log4jContextFactory.java:97)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.(Log4jContextFactory.java:58)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at org.apache.logging.log4j.LogManager.(LogManager.java:94)
> at teste.Activator.start(Activator.java:26)
> at 
> org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:771)
> at 
> org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:764)
> at 
> org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:721)
> at 
> org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:936)
> at 
> org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:319)
> at org.eclipse.osgi.container.Module.doStart(Module.java:571)
> at org.eclipse.osgi.container.Module.start(Module.java:439)
> at 
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)
> at 
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1562)
> at 
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)
> at 
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)
> at 
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
> at 
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at 
> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LOG4J2-1936) ClassNotFoundException when making all loggers asynchronous under OSGi environment

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-1936:
-
Description: 
Can't find AsyncLoggerContextSelector when making all Log4j loggers 
asynchronous on an OSGi environment.

{noformat}
java.lang.ClassNotFoundException: 
org.apache.logging.log4j.core.async.AsyncLoggerContextSelector cannot be found 
by org.apache.logging.log4j.api_2.8.2
at 
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:432)
at 
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:345)
at 
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:337)
at 
org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.apache.logging.log4j.util.LoaderUtil.loadClass(LoaderUtil.java:141)
at 
org.apache.logging.log4j.util.LoaderUtil.newInstanceOf(LoaderUtil.java:180)
at 
org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOf(LoaderUtil.java:201)
at 
org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOfProperty(LoaderUtil.java:226)
at 
org.apache.logging.log4j.core.impl.Log4jContextFactory.createContextSelector(Log4jContextFactory.java:97)
at 
org.apache.logging.log4j.core.impl.Log4jContextFactory.(Log4jContextFactory.java:58)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at org.apache.logging.log4j.LogManager.(LogManager.java:94)
at teste.Activator.start(Activator.java:26)
at 
org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:771)
at 
org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:764)
at 
org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:721)
at 
org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:936)
at 
org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:319)
at org.eclipse.osgi.container.Module.doStart(Module.java:571)
at org.eclipse.osgi.container.Module.start(Module.java:439)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1562)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
at 
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at 
org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
{noformat}

  was:
Can't find AsyncLoggerContextSelector when making all Log4j loggers 
asynchronous on an OSGi environment.

java.lang.ClassNotFoundException: 
org.apache.logging.log4j.core.async.AsyncLoggerContextSelector cannot be found 
by org.apache.logging.log4j.api_2.8.2
at 
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:432)
at 
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:345)
at 
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:337)
at 
org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.apache.logging.log4j.util.LoaderUtil.loadClass(LoaderUtil.java:141)
at 
org.apache.logging.log4j.util.LoaderUtil.newInstanceOf(LoaderUtil.java:180)
at 
org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOf(LoaderUtil.java:201)
at 
org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOfProperty(LoaderUtil.java:226)
at 
org.apache.logging.log4j.core.impl.Log4jContextFactory.createContextSelector(Log4jContextFactory.java:97)
at 
org.apache.logging.log4j.core.impl.Log4jContextFactory.(Log4jContextFactory.java:58)

[jira] [Commented] (LOG4J2-2030) ClassCastException: org.apache.logging.log4j.simple.SimpleLoggerContext cannot be cast to org.apache.logging.log4j.core.LoggerContext

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16154096#comment-16154096
 ] 

Gary Gregory commented on LOG4J2-2030:
--

Do you have the stack trace?

> ClassCastException: org.apache.logging.log4j.simple.SimpleLoggerContext 
> cannot be cast to org.apache.logging.log4j.core.LoggerContext
> -
>
> Key: LOG4J2-2030
> URL: https://issues.apache.org/jira/browse/LOG4J2-2030
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.9.0
>Reporter: jncharpin
>
> When upgrading from 2.8.2 to 2.9.0, we are facing the following exception 
> when accessing the context.
> Caused by: java.lang.ClassCastException: 
> org.apache.logging.log4j.simple.SimpleLoggerContext cannot be cast to 
> org.apache.logging.log4j.core.LoggerContext
>   at 
> org.apache.logging.log4j.core.LoggerContext.getContext(LoggerContext.java:190)
>   at 
> org.apache.logging.log4j.core.config.Configurator.setLevel(Configurator.java:291)
> Seems like that the context factory is incorrect and defaulted to 
> {{SimpleLoggerContextFactory}} because of the provider is not able to find 
> the resource {{META-INF/log4j-provider.properties}} which is missing in 2.9.0 
> if not wrong.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2027) File appenders fail to configure when using a header with createOnDemand=true

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16154012#comment-16154012
 ] 

Gary Gregory commented on LOG4J2-2027:
--

[~pburrowesOC]:

Thank you for looking at this area. A couple of things to keep in mind:
- Look for opportunities to refactor common code.
- For a future version, consider managers being able to deal with corrupted 
streams, where corrupted is vaguely defined and would mean that the manager 
should be able to re-create the output stream at anytime. This in the same vein 
as the recent rework of the JMS appender which can now reconnect to a broker if 
the connection starts out as bad or goes bad later. See the socket manager as 
well which knows how to reconnect itself to a server.

Gary

> File appenders fail to configure when using a header with createOnDemand=true
> -
>
> Key: LOG4J2-2027
> URL: https://issues.apache.org/jira/browse/LOG4J2-2027
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.8.2
>Reporter: Paul Burrowes
>Priority: Minor
>
> FileManager and RollingFileManager are not completely initialised when 
> OutputStreamManager. tries to create a stream to log the header. This 
> only occurs when append=false, createOnDemand=true and the appender has a 
> layout with a header.
> The key to the problem is that if createOnDemand=false the FileManagerFactory 
> will create the FileOutputStream before constructing the FileManager 
> (FileManager.java:422, RollingFIleManager.java:635). 
> I suspect that the DirectWriteStrategy may be vulnerable to this too.
> RandomAccessFileManager is not affected by this because it does not support 
> createOnDemand.
> For example
> {code}
>  createOnDemand="true">
> 
> 
> {code}
> Stack trace of the failure showing that OutputStreamManager is trying to 
> write the header in an incompletely constructed FileManager.
> {code}
> 2017-09-01 17:09:36.016+1200 ERROR   [log4j.status]  {} 
> Unable to inject fields into builder class for plugin type class 
> org.apache.logging.log4j.core.appender.RollingFileAppender, element 
> RollingFile.
> java.lang.NullPointerException: name can't be null
> at java.io.FilePermission.init(FilePermission.java:191)
> at java.io.FilePermission.(FilePermission.java:277)
> at java.lang.SecurityManager.checkWrite(SecurityManager.java:979)
> at java.io.FileOutputStream.(FileOutputStream.java:200)
> at java.io.FileOutputStream.(FileOutputStream.java:133)
> at 
> org.apache.logging.log4j.core.appender.FileManager.createOutputStream(FileManager.java:120)
> at 
> org.apache.logging.log4j.core.appender.OutputStreamManager.getOutputStream(OutputStreamManager.java:166)
> at 
> org.apache.logging.log4j.core.appender.OutputStreamManager.(OutputStreamManager.java:95)
> at 
> org.apache.logging.log4j.core.appender.FileManager.(FileManager.java:84)
> at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.(RollingFileManager.java:111)
> at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager$RollingFileManagerFactory.createManager(RollingFileManager.java:593)
> at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager$RollingFileManagerFactory.createManager(RollingFileManager.java:554)
> at 
> org.apache.logging.log4j.core.appender.AbstractManager.getManager(AbstractManager.java:112)
> at 
> org.apache.logging.log4j.core.appender.OutputStreamManager.getManager(OutputStreamManager.java:114)
> at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.getFileManager(RollingFileManager.java:155)
> at 
> org.apache.logging.log4j.core.appender.RollingFileAppender$Builder.build(RollingFileAppender.java:131)
> at 
> org.apache.logging.log4j.core.appender.RollingFileAppender$Builder.build(RollingFileAppender.java:60)
> at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:122)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:952)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:892)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:884)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:508)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:232)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:244)

[jira] [Closed] (LOG4J2-2029) Marker examples should not use deprecate flow APIs

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-2029.

Resolution: Fixed

In git master.

> Marker examples should not use deprecate flow APIs
> --
>
> Key: LOG4J2-2029
> URL: https://issues.apache.org/jira/browse/LOG4J2-2029
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.9.1
>
>
> Marker examples should not use deprecate flow APIs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (LOG4J2-2029) Marker examples should not use deprecate flow APIs

[Gary Gregory (JIRA)]

Gary Gregory created LOG4J2-2029:


 Summary: Marker examples should not use deprecate flow APIs
 Key: LOG4J2-2029
 URL: https://issues.apache.org/jira/browse/LOG4J2-2029
 Project: Log4j 2
  Issue Type: Bug
Affects Versions: 2.9.0
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 2.9.1


Marker examples should not use deprecate flow APIs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (LOG4J2-2026) java.lang.AbstractMethodError: javax.xml.parsers.DocumentBuilderFactory.setFeature()

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150873#comment-16150873
 ] 

Gary Gregory edited comment on LOG4J2-2026 at 9/1/17 5:45 PM:
--

The change doesn't handle AbstractMethodError which is not Exception based:
{noformat}
Object (java.lang)
  Throwable (java.lang)
Error (java.lang)
  LinkageError (java.lang)
IncompatibleClassChangeError (java.lang)
  AbstractMethodError (java.lang)
{noformat}


was (Author: leonfin):
The change doesn't handle AbstractMethodError which is not Exception based:
Object (java.lang)
  Throwable (java.lang)
Error (java.lang)
  LinkageError (java.lang)
IncompatibleClassChangeError (java.lang)
  AbstractMethodError (java.lang)


> java.lang.AbstractMethodError: 
> javax.xml.parsers.DocumentBuilderFactory.setFeature()
> 
>
> Key: LOG4J2-2026
> URL: https://issues.apache.org/jira/browse/LOG4J2-2026
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: Leon Finker
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.9.1
>
>
> Hi,
> Tested 2.9.0 RC1 and noticed one issue due to xerces 2.6.2 version being used 
> on one big app. It causes log4j2 failure to initialize (changes are from 
> LOG4J2-1959):
> {noformat}
> Exception in thread "main" java.lang.AbstractMethodError: 
> javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.disableDtdProcessing(XmlConfiguration.java:205)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.newDocumentBuilder(XmlConfiguration.java:194)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.(XmlConfiguration.java:92)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfigurationFactory.getConfiguration(XmlConfigurationFactory.java:46)
> at 
> org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:239)
> at 
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:369)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:237)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:158)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:131)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:101)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:188)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (LOG4J2-2026) java.lang.AbstractMethodError: javax.xml.parsers.DocumentBuilderFactory.setFeature()

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved LOG4J2-2026.
--
Resolution: Fixed

Now handling {{LinkageError}} in git master. Please verify and close.

> java.lang.AbstractMethodError: 
> javax.xml.parsers.DocumentBuilderFactory.setFeature()
> 
>
> Key: LOG4J2-2026
> URL: https://issues.apache.org/jira/browse/LOG4J2-2026
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: Leon Finker
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.9.1
>
>
> Hi,
> Tested 2.9.0 RC1 and noticed one issue due to xerces 2.6.2 version being used 
> on one big app. It causes log4j2 failure to initialize (changes are from 
> LOG4J2-1959):
> Exception in thread "main" java.lang.AbstractMethodError: 
> javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.disableDtdProcessing(XmlConfiguration.java:205)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.newDocumentBuilder(XmlConfiguration.java:194)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.(XmlConfiguration.java:92)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfigurationFactory.getConfiguration(XmlConfigurationFactory.java:46)
> at 
> org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:239)
> at 
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:369)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:237)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:158)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:131)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:101)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:188)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LOG4J2-2026) java.lang.AbstractMethodError: javax.xml.parsers.DocumentBuilderFactory.setFeature()

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-2026:
-
Description: 
Hi,

Tested 2.9.0 RC1 and noticed one issue due to xerces 2.6.2 version being used 
on one big app. It causes log4j2 failure to initialize (changes are from 
LOG4J2-1959):

{noformat}
Exception in thread "main" java.lang.AbstractMethodError: 
javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
at 
org.apache.logging.log4j.core.config.xml.XmlConfiguration.disableDtdProcessing(XmlConfiguration.java:205)
at 
org.apache.logging.log4j.core.config.xml.XmlConfiguration.newDocumentBuilder(XmlConfiguration.java:194)
at 
org.apache.logging.log4j.core.config.xml.XmlConfiguration.(XmlConfiguration.java:92)
at 
org.apache.logging.log4j.core.config.xml.XmlConfigurationFactory.getConfiguration(XmlConfigurationFactory.java:46)
at 
org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:239)
at 
org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:369)
at 
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:237)
at 
org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:158)
at 
org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:131)
at 
org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:101)
at 
org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:188)
{noformat}

  was:
Hi,

Tested 2.9.0 RC1 and noticed one issue due to xerces 2.6.2 version being used 
on one big app. It causes log4j2 failure to initialize (changes are from 
LOG4J2-1959):

Exception in thread "main" java.lang.AbstractMethodError: 
javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
at 
org.apache.logging.log4j.core.config.xml.XmlConfiguration.disableDtdProcessing(XmlConfiguration.java:205)
at 
org.apache.logging.log4j.core.config.xml.XmlConfiguration.newDocumentBuilder(XmlConfiguration.java:194)
at 
org.apache.logging.log4j.core.config.xml.XmlConfiguration.(XmlConfiguration.java:92)
at 
org.apache.logging.log4j.core.config.xml.XmlConfigurationFactory.getConfiguration(XmlConfigurationFactory.java:46)
at 
org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:239)
at 
org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:369)
at 
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:237)
at 
org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:158)
at 
org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:131)
at 
org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:101)
at 
org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:188)


> java.lang.AbstractMethodError: 
> javax.xml.parsers.DocumentBuilderFactory.setFeature()
> 
>
> Key: LOG4J2-2026
> URL: https://issues.apache.org/jira/browse/LOG4J2-2026
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: Leon Finker
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.9.1
>
>
> Hi,
> Tested 2.9.0 RC1 and noticed one issue due to xerces 2.6.2 version being used 
> on one big app. It causes log4j2 failure to initialize (changes are from 
> LOG4J2-1959):
> {noformat}
> Exception in thread "main" java.lang.AbstractMethodError: 
> javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.disableDtdProcessing(XmlConfiguration.java:205)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.newDocumentBuilder(XmlConfiguration.java:194)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.(XmlConfiguration.java:92)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfigurationFactory.getConfiguration(XmlConfigurationFactory.java:46)
> at 
> org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:239)
> at 
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:369)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:237)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:158)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:131)
> 

[jira] [Comment Edited] (LOG4J2-2026) java.lang.AbstractMethodError: javax.xml.parsers.DocumentBuilderFactory.setFeature()

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150906#comment-16150906
 ] 

Gary Gregory edited comment on LOG4J2-2026 at 9/1/17 5:40 PM:
--

Reopening to handle {{LinkageError}}.


was (Author: garydgregory):
Reopening to hanle LinkageError

> java.lang.AbstractMethodError: 
> javax.xml.parsers.DocumentBuilderFactory.setFeature()
> 
>
> Key: LOG4J2-2026
> URL: https://issues.apache.org/jira/browse/LOG4J2-2026
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: Leon Finker
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.9.1
>
>
> Hi,
> Tested 2.9.0 RC1 and noticed one issue due to xerces 2.6.2 version being used 
> on one big app. It causes log4j2 failure to initialize (changes are from 
> LOG4J2-1959):
> Exception in thread "main" java.lang.AbstractMethodError: 
> javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.disableDtdProcessing(XmlConfiguration.java:205)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.newDocumentBuilder(XmlConfiguration.java:194)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.(XmlConfiguration.java:92)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfigurationFactory.getConfiguration(XmlConfigurationFactory.java:46)
> at 
> org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:239)
> at 
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:369)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:237)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:158)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:131)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:101)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:188)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (LOG4J2-2026) java.lang.AbstractMethodError: javax.xml.parsers.DocumentBuilderFactory.setFeature()

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory reopened LOG4J2-2026:
--

Reopening to hanle LinkageError

> java.lang.AbstractMethodError: 
> javax.xml.parsers.DocumentBuilderFactory.setFeature()
> 
>
> Key: LOG4J2-2026
> URL: https://issues.apache.org/jira/browse/LOG4J2-2026
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: Leon Finker
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.9.1
>
>
> Hi,
> Tested 2.9.0 RC1 and noticed one issue due to xerces 2.6.2 version being used 
> on one big app. It causes log4j2 failure to initialize (changes are from 
> LOG4J2-1959):
> Exception in thread "main" java.lang.AbstractMethodError: 
> javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.disableDtdProcessing(XmlConfiguration.java:205)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.newDocumentBuilder(XmlConfiguration.java:194)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.(XmlConfiguration.java:92)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfigurationFactory.getConfiguration(XmlConfigurationFactory.java:46)
> at 
> org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:239)
> at 
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:369)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:237)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:158)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:131)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:101)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:188)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (LOG4J2-2023) Use a class' canonical name instead of name to create its logger name

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved LOG4J2-2023.
--
   Resolution: Fixed
Fix Version/s: 2.9.1

In git master. Please verify and close this issue.

> Use a class' canonical name instead of name to create its logger name
> -
>
> Key: LOG4J2-2023
> URL: https://issues.apache.org/jira/browse/LOG4J2-2023
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.9.1, 2.9.0
>
>
> Use a class' canonical name instead of name to create its logger name.
> Say you have loggers built with Classes for which {{getName()}} give you:
> - {{com.example.app.A}}
> - {{com.example.app.A$AS1}}
> - {{com.example.app.A$AS2}}
> - ...
> - {{com.example.app.A$ASN}}
> Before 2.9.0: You you set the root logger to {{WARN}} and 
> {{com.example.app.A}} to {{INFO}}, then you get {{INFO}} events for A but you 
> do not get {{INFO}} messages from {{AS1}}, {{AS2}}, and so on. There is no 
> way to set all {{A$ASx}} loggers to the same level at the same time.
> In 2.9.0 now, converting a Class to a logger name uses 
> {{getCannonicalName()}} such that the logger names are:
> - {{com.example.app.A}}
> - {{com.example.app.A.AS1}}
> - {{com.example.app.A.AS2}}
> - ...
> - {{com.example.app.A.ASN}}
> When you set {{com.example.app.A}} to {{INFO}}, then you get {{INFO}} events 
> for {{A}}, {{AS1}}, {{AS2}}, and so on. 
> The dev ML thread is:
> https://lists.apache.org/thread.html/43b83474aad9c8625e5a6a63d2595c9d795dd6a51076493bacd87a36@%3Cdev.logging.apache.org%3E
> Note post 2.9.0: If the class canonical name is null, then use the class name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LOG4J2-2023) Use a class' canonical name instead of name to create its logger name

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-2023:
-
Description: 
Use a class' canonical name instead of name to create its logger name.

Say you have loggers built with Classes for which {{getName()}} give you:
- {{com.example.app.A}}
- {{com.example.app.A$AS1}}
- {{com.example.app.A$AS2}}
- ...
- {{com.example.app.A$ASN}}

Before 2.9.0: You you set the root logger to {{WARN}} and {{com.example.app.A}} 
to {{INFO}}, then you get {{INFO}} events for A but you do not get {{INFO}} 
messages from {{AS1}}, {{AS2}}, and so on. There is no way to set all {{A$ASx}} 
loggers to the same level at the same time.

In 2.9.0 now, converting a Class to a logger name uses {{getCannonicalName()}} 
such that the logger names are:

- {{com.example.app.A}}
- {{com.example.app.A.AS1}}
- {{com.example.app.A.AS2}}
- ...
- {{com.example.app.A.ASN}}

When you set {{com.example.app.A}} to {{INFO}}, then you get {{INFO}} events 
for {{A}}, {{AS1}}, {{AS2}}, and so on. 

The dev ML thread is:

https://lists.apache.org/thread.html/43b83474aad9c8625e5a6a63d2595c9d795dd6a51076493bacd87a36@%3Cdev.logging.apache.org%3E

Note post 2.9.0: If the class canonical name is null, then use the class name.



  was:
Use a class' canonical name instead of name to create its logger name.

Say you have loggers built with Classes for which {{getName()}} give you:
- {{com.example.app.A}}
- {{com.example.app.A$AS1}}
- {{com.example.app.A$AS2}}
- ...
- {{com.example.app.A$ASN}}

Before 2.9.0: You you set the root logger to {{WARN}} and {{com.example.app.A}} 
to {{INFO}}, then you get {{INFO}} events for A but you do not get {{INFO}} 
messages from {{AS1}}, {{AS2}}, and so on. There is no way to set all {{A$ASx}} 
loggers to the same level at the same time.

In 2.9.0 now, converting a Class to a logger name uses {{getCannonicalName()}} 
such that the logger names are:

- {{com.example.app.A}}
- {{com.example.app.A.AS1}}
- {{com.example.app.A.AS2}}
- ...
- {{com.example.app.A.ASN}}

When you set {{com.example.app.A}} to {{INFO}}, then you get {{INFO}} events 
for {{A}}, {{AS1}}, {{AS2}}, and so on. 

The dev ML thread is:

https://lists.apache.org/thread.html/43b83474aad9c8625e5a6a63d2595c9d795dd6a51076493bacd87a36@%3Cdev.logging.apache.org%3E




> Use a class' canonical name instead of name to create its logger name
> -
>
> Key: LOG4J2-2023
> URL: https://issues.apache.org/jira/browse/LOG4J2-2023
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.9.0
>
>
> Use a class' canonical name instead of name to create its logger name.
> Say you have loggers built with Classes for which {{getName()}} give you:
> - {{com.example.app.A}}
> - {{com.example.app.A$AS1}}
> - {{com.example.app.A$AS2}}
> - ...
> - {{com.example.app.A$ASN}}
> Before 2.9.0: You you set the root logger to {{WARN}} and 
> {{com.example.app.A}} to {{INFO}}, then you get {{INFO}} events for A but you 
> do not get {{INFO}} messages from {{AS1}}, {{AS2}}, and so on. There is no 
> way to set all {{A$ASx}} loggers to the same level at the same time.
> In 2.9.0 now, converting a Class to a logger name uses 
> {{getCannonicalName()}} such that the logger names are:
> - {{com.example.app.A}}
> - {{com.example.app.A.AS1}}
> - {{com.example.app.A.AS2}}
> - ...
> - {{com.example.app.A.ASN}}
> When you set {{com.example.app.A}} to {{INFO}}, then you get {{INFO}} events 
> for {{A}}, {{AS1}}, {{AS2}}, and so on. 
> The dev ML thread is:
> https://lists.apache.org/thread.html/43b83474aad9c8625e5a6a63d2595c9d795dd6a51076493bacd87a36@%3Cdev.logging.apache.org%3E
> Note post 2.9.0: If the class canonical name is null, then use the class name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (LOG4J2-2023) Use a class' canonical name instead of name to create its logger name

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory reopened LOG4J2-2023:
--

Reopening to adjust for a null cannonical name.

> Use a class' canonical name instead of name to create its logger name
> -
>
> Key: LOG4J2-2023
> URL: https://issues.apache.org/jira/browse/LOG4J2-2023
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.9.0
>
>
> Use a class' canonical name instead of name to create its logger name.
> Say you have loggers built with Classes for which {{getName()}} give you:
> - {{com.example.app.A}}
> - {{com.example.app.A$AS1}}
> - {{com.example.app.A$AS2}}
> - ...
> - {{com.example.app.A$ASN}}
> Before 2.9.0: You you set the root logger to {{WARN}} and 
> {{com.example.app.A}} to {{INFO}}, then you get {{INFO}} events for A but you 
> do not get {{INFO}} messages from {{AS1}}, {{AS2}}, and so on. There is no 
> way to set all {{A$ASx}} loggers to the same level at the same time.
> In 2.9.0 now, converting a Class to a logger name uses 
> {{getCannonicalName()}} such that the logger names are:
> - {{com.example.app.A}}
> - {{com.example.app.A.AS1}}
> - {{com.example.app.A.AS2}}
> - ...
> - {{com.example.app.A.ASN}}
> When you set {{com.example.app.A}} to {{INFO}}, then you get {{INFO}} events 
> for {{A}}, {{AS1}}, {{AS2}}, and so on. 
> The dev ML thread is:
> https://lists.apache.org/thread.html/43b83474aad9c8625e5a6a63d2595c9d795dd6a51076493bacd87a36@%3Cdev.logging.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2023) Use a class' canonical name instead of name to create its logger name

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16149294#comment-16149294
 ] 

Gary Gregory commented on LOG4J2-2023:
--

Using custom separators was discussed and rejected. The fix here will be to use 
getName() if getCannonicalName() returns null.

> Use a class' canonical name instead of name to create its logger name
> -
>
> Key: LOG4J2-2023
> URL: https://issues.apache.org/jira/browse/LOG4J2-2023
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.9.0
>
>
> Use a class' canonical name instead of name to create its logger name.
> Say you have loggers built with Classes for which {{getName()}} give you:
> - {{com.example.app.A}}
> - {{com.example.app.A$AS1}}
> - {{com.example.app.A$AS2}}
> - ...
> - {{com.example.app.A$ASN}}
> Before 2.9.0: You you set the root logger to {{WARN}} and 
> {{com.example.app.A}} to {{INFO}}, then you get {{INFO}} events for A but you 
> do not get {{INFO}} messages from {{AS1}}, {{AS2}}, and so on. There is no 
> way to set all {{A$ASx}} loggers to the same level at the same time.
> In 2.9.0 now, converting a Class to a logger name uses 
> {{getCannonicalName()}} such that the logger names are:
> - {{com.example.app.A}}
> - {{com.example.app.A.AS1}}
> - {{com.example.app.A.AS2}}
> - ...
> - {{com.example.app.A.ASN}}
> When you set {{com.example.app.A}} to {{INFO}}, then you get {{INFO}} events 
> for {{A}}, {{AS1}}, {{AS2}}, and so on. 
> The dev ML thread is:
> https://lists.apache.org/thread.html/43b83474aad9c8625e5a6a63d2595c9d795dd6a51076493bacd87a36@%3Cdev.logging.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (LOG4J2-2026) java.lang.AbstractMethodError: javax.xml.parsers.DocumentBuilderFactory.setFeature()

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved LOG4J2-2026.
--
   Resolution: Fixed
Fix Version/s: 2.9.1

In git master. 

Any exceptions aside from a standard configuration exception will be caught and 
logged to the internal Log4j status logger as an ERROR.

Please verify and close this issue.

> java.lang.AbstractMethodError: 
> javax.xml.parsers.DocumentBuilderFactory.setFeature()
> 
>
> Key: LOG4J2-2026
> URL: https://issues.apache.org/jira/browse/LOG4J2-2026
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: Leon Finker
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.9.1
>
>
> Hi,
> Tested 2.9.0 RC1 and noticed one issue due to xerces 2.6.2 version being used 
> on one big app. It causes log4j2 failure to initialize (changes are from 
> LOG4J2-1959):
> Exception in thread "main" java.lang.AbstractMethodError: 
> javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.disableDtdProcessing(XmlConfiguration.java:205)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.newDocumentBuilder(XmlConfiguration.java:194)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.(XmlConfiguration.java:92)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfigurationFactory.getConfiguration(XmlConfigurationFactory.java:46)
> at 
> org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:239)
> at 
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:369)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:237)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:158)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:131)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:101)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:188)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LOG4J2-1990) ConcurrentModificationException logging a parameter of type Map

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-1990:
-
Fix Version/s: (was: 2.9.0)
   2.9.1

> ConcurrentModificationException logging a parameter of type Map 
> 
>
> Key: LOG4J2-1990
> URL: https://issues.apache.org/jira/browse/LOG4J2-1990
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.8.2
>Reporter: Philippe Mouawad
> Fix For: 2.9.1
>
> Attachments: LOG4J2-1990.patch
>
>
> Hello,
> Working with current JMeter trunk and:
> *  attached test plan 
> * org.apache.jmeter.protocol.http.control.CacheManager level set to debug in 
> log4j2.xml in bin folder
> I get:
> {code:none}
> java.util.concurrent.ExecutionException: 
> java.util.ConcurrentModificationException
>   at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
> ~[?:1.8.0_121]
>   at java.util.concurrent.FutureTask.get(FutureTask.java:192) 
> ~[?:1.8.0_121]
>   at 
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.downloadPageResources(HTTPSamplerBase.java:1349)
>  [ApacheJMeter_http.jar:3.3-SNAPSHOT.20170724]
>   at 
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.resultProcessing(HTTPSamplerBase.java:1657)
>  [ApacheJMeter_http.jar:3.3-SNAPSHOT.20170724]
>   at 
> org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.resultProcessing(HTTPAbstractImpl.java:519)
>  [ApacheJMeter_http.jar:3.3-SNAPSHOT.20170724]
>   at 
> org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:534)
>  [ApacheJMeter_http.jar:3.3-SNAPSHOT.20170724]
>   at 
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
>  [ApacheJMeter_http.jar:3.3-SNAPSHOT.20170724]
>   at 
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189)
>  [ApacheJMeter_http.jar:3.3-SNAPSHOT.20170724]
>   at 
> org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178)
>  [ApacheJMeter_http.jar:3.3-SNAPSHOT.20170724]
>   at 
> org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:500)
>  [ApacheJMeter_core.jar:3.3-SNAPSHOT.20170724]
>   at 
> org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425) 
> [ApacheJMeter_core.jar:3.3-SNAPSHOT.20170724]
>   at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254) 
> [ApacheJMeter_core.jar:3.3-SNAPSHOT.20170724]
>   at java.lang.Thread.run(Thread.java:745) [?:1.8.0_121]
> Caused by: java.util.ConcurrentModificationException
>   at 
> org.apache.commons.collections.map.AbstractLinkedMap$LinkIterator.nextEntry(AbstractLinkedMap.java:560)
>  ~[commons-collections-3.2.2.jar:3.2.2]
>   at 
> org.apache.commons.collections.map.AbstractLinkedMap$EntrySetIterator.next(AbstractLinkedMap.java:428)
>  ~[commons-collections-3.2.2.jar:3.2.2]
>   at 
> org.apache.logging.log4j.message.ParameterFormatter.appendMap(ParameterFormatter.java:569)
>  ~[log4j-api-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.message.ParameterFormatter.appendPotentiallyRecursiveValue(ParameterFormatter.java:505)
>  ~[log4j-api-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.message.ParameterFormatter.recursiveDeepToString(ParameterFormatter.java:432)
>  ~[log4j-api-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.message.ParameterFormatter.formatMessage2(ParameterFormatter.java:189)
>  ~[log4j-api-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.message.ReusableParameterizedMessage.formatTo(ReusableParameterizedMessage.java:313)
>  ~[log4j-api-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.core.impl.MutableLogEvent.setMessage(MutableLogEvent.java:214)
>  ~[log4j-core-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.core.impl.ReusableLogEventFactory.createEvent(ReusableLogEventFactory.java:81)
>  ~[log4j-core-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:401) 
> [log4j-core-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:63)
>  [log4j-core-2.8.2.jar:2.8.2]
>   at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:146) 
> [log4j-core-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(AbstractLogger.java:2091)
>  [log4j-api-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:2005)
>  [log4j-api-2.8.2.jar:2.8.2]
>   at 
> org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1876)
>  [log4j-api-2.8.2.jar:2.8.2]
>   at 

[jira] [Updated] (LOG4J2-1630) Unit of Work Logging

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-1630:
-
Fix Version/s: (was: 2.9.0)
   2.9.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.9.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.4.14#64029)

[jira] [Updated] (LOG4J2-1896) Update classes in org.apache.logging.log4j.core.net.ssl in APIs from String to char[] for passwords

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-1896:
-
Fix Version/s: (was: 2.9.0)
   2.9.1

> Update classes in org.apache.logging.log4j.core.net.ssl in APIs from String 
> to char[] for passwords
> ---
>
> Key: LOG4J2-1896
> URL: https://issues.apache.org/jira/browse/LOG4J2-1896
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Configurators
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.9.1
>
>
> Update {{org.apache.logging.log4j.core.net.ssl.StoreConfiguration}} from a 
> {{String}} to {{char[]}} to represent its password.
> The goal is to reduce the security risk of using a String for a password. See 
> https://stackoverflow.com/questions/8881291/why-is-char-preferred-over-string-for-passwords



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LOG4J2-2008) RFC5424Layout should support multiple StructuredData elements.

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-2008:
-
Fix Version/s: (was: 2.9.0)
   2.9.1

> RFC5424Layout should support multiple StructuredData elements.
> --
>
> Key: LOG4J2-2008
> URL: https://issues.apache.org/jira/browse/LOG4J2-2008
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Layouts
>Affects Versions: 2.8.2
>Reporter: Ralph Goers
> Fix For: 2.9.1
>
>
> Currently RFC5424Layout will support a StructuredDataMessage and will print 
> the ThreadContext as a structured data element and the StructuredData as a 
> second structured data element. In some cases other structured data elements 
> may be needed and the RFC5424Layout should support printing those.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LOG4J2-2026) java.lang.AbstractMethodError: javax.xml.parsers.DocumentBuilderFactory.setFeature()

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-2026:
-
Summary: java.lang.AbstractMethodError: 
javax.xml.parsers.DocumentBuilderFactory.setFeature()  (was: 
AbstractMethodError DocumentBuilderFactory.setFeature)

> java.lang.AbstractMethodError: 
> javax.xml.parsers.DocumentBuilderFactory.setFeature()
> 
>
> Key: LOG4J2-2026
> URL: https://issues.apache.org/jira/browse/LOG4J2-2026
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Leon Finker
>Assignee: Gary Gregory
>Priority: Minor
>
> Hi,
> Tested 2.9.0 RC1 and noticed one issue due to xerces 2.6.2 version being used 
> on one big app. It causes log4j2 failure to initialize (changes are from 
> LOG4J2-1959):
> Exception in thread "main" java.lang.AbstractMethodError: 
> javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.disableDtdProcessing(XmlConfiguration.java:205)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.newDocumentBuilder(XmlConfiguration.java:194)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfiguration.(XmlConfiguration.java:92)
> at 
> org.apache.logging.log4j.core.config.xml.XmlConfigurationFactory.getConfiguration(XmlConfigurationFactory.java:46)
> at 
> org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:239)
> at 
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:369)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:237)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:158)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:131)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:101)
> at 
> org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:188)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (LOG4J2-2023) Use a class' canonical name instead of name to create its logger name

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed LOG4J2-2023.

Resolution: Fixed

> Use a class' canonical name instead of name to create its logger name
> -
>
> Key: LOG4J2-2023
> URL: https://issues.apache.org/jira/browse/LOG4J2-2023
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.9
>
>
> Use a class' canonical name instead of name to create its logger name.
> Say you have loggers built with Classes for which {{getName()}} give you:
> - {{com.example.app.A}}
> - {{com.example.app.A$AS1}}
> - {{com.example.app.A$AS2}}
> - ...
> - {{com.example.app.A$ASN}}
> Before 2.9.0: You you set the root logger to {{WARN}} and 
> {{com.example.app.A}} to {{INFO}}, then you get {{INFO}} events for A but you 
> do not get {{INFO}} messages from {{AS1}}, {{AS2}}, and so on. There is no 
> way to set all {{A$ASx}} loggers to the same level at the same time.
> In 2.9.0 now, converting a Class to a logger name uses 
> {{getCannonicalName()}} such that the logger names are:
> - {{com.example.app.A}}
> - {{com.example.app.A.AS1}}
> - {{com.example.app.A.AS2}}
> - ...
> - {{com.example.app.A.ASN}}
> When you set {{com.example.app.A}} to {{INFO}}, then you get {{INFO}} events 
> for {{A}}, {{AS1}}, {{AS2}}, and so on. 
> The dev ML thread is:
> https://lists.apache.org/thread.html/43b83474aad9c8625e5a6a63d2595c9d795dd6a51076493bacd87a36@%3Cdev.logging.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2023) Use a class' canonical name instead of name to create its logger name

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16149029#comment-16149029
 ] 

Gary Gregory commented on LOG4J2-2023:
--

Hello [~jasonetedor]:

Say you have loggers built with Classes for which {{getName()}} give you:
- {{com.example.app.A}}
- {{com.example.app.A$AS1}}
- {{com.example.app.A$AS2}}
- ...
- {{com.example.app.A$ASN}}

Before 2.9.0: You you set the root logger to {{WARN}} and {{com.example.app.A}} 
to {{INFO}}, then you get {{INFO}} events for A but you do not get {{INFO}} 
messages from {{AS1}}, {{AS2}}, and so on. There is no way to set all {{A$ASx}} 
loggers to the same level at the same time.

In 2.9.0 now, converting a Class to a logger name uses {{getCannonicalName()}} 
such that the logger names are:

- {{com.example.app.A}}
- {{com.example.app.A.AS1}}
- {{com.example.app.A.AS2}}
- ...
- {{com.example.app.A.ASN}}

When you set {{com.example.app.A}} to {{INFO}}, then you get {{INFO}} events 
for {{A}}, {{AS1}}, {{AS2}}, and so on. 

The dev ML thread is:

https://lists.apache.org/thread.html/43b83474aad9c8625e5a6a63d2595c9d795dd6a51076493bacd87a36@%3Cdev.logging.apache.org%3E

Gary

> Use a class' canonical name instead of name to create its logger name
> -
>
> Key: LOG4J2-2023
> URL: https://issues.apache.org/jira/browse/LOG4J2-2023
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.9
>
>
> Use a class' canonical name instead of name to create its logger name



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (LOG4J2-2023) Use a class' canonical name instead of name to create its logger name

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory reopened LOG4J2-2023:
--

> Use a class' canonical name instead of name to create its logger name
> -
>
> Key: LOG4J2-2023
> URL: https://issues.apache.org/jira/browse/LOG4J2-2023
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.9
>
>
> Use a class' canonical name instead of name to create its logger name



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2013) SslSocketManager does not apply SSLContext on TCP reconnect

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16145868#comment-16145868
 ] 

Gary Gregory commented on LOG4J2-2013:
--

Big Happy then.

> SslSocketManager does not apply SSLContext on TCP reconnect
> ---
>
> Key: LOG4J2-2013
> URL: https://issues.apache.org/jira/browse/LOG4J2-2013
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.8.2
>Reporter: Taylor Patton
>Assignee: Gary Gregory
> Fix For: 2.9
>
>
> The SslSocketManger is not applying the SSLContext correctly when the TCP 
> connection is restarted. Currently the SslSocketManager inherits a 
> Reconnector class from TcpSocketManger, which only restarts the TCP 
> connection and does not apply SSL correctly. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2013) SslSocketManager does not apply SSLContext on TCP reconnect

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16145743#comment-16145743
 ] 

Gary Gregory commented on LOG4J2-2013:
--

YW. Note that the release vote for 2.9.0 is under way. If all goes well, we 
should have a release out by the end of the week.

> SslSocketManager does not apply SSLContext on TCP reconnect
> ---
>
> Key: LOG4J2-2013
> URL: https://issues.apache.org/jira/browse/LOG4J2-2013
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.8.2
>Reporter: Taylor Patton
>Assignee: Gary Gregory
> Fix For: 2.9
>
>
> The SslSocketManger is not applying the SSLContext correctly when the TCP 
> connection is restarted. Currently the SslSocketManager inherits a 
> Reconnector class from TcpSocketManger, which only restarts the TCP 
> connection and does not apply SSL correctly. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2025) Support Tomcat JULI's per-webapp JUL logging by implementing java.util.logging.Handler

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16141802#comment-16141802
 ] 

Gary Gregory commented on LOG4J2-2025:
--

A patch would be most welcome :-)

> Support Tomcat JULI's per-webapp JUL logging by implementing 
> java.util.logging.Handler
> --
>
> Key: LOG4J2-2025
> URL: https://issues.apache.org/jira/browse/LOG4J2-2025
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: JUL adapter
>Affects Versions: 2.8.2
> Environment: Tomcat 8.5.20, Oracle Java 1.8.0_144
>Reporter: Ibrahim M. Ghazal
>Priority: Minor
>
> On most servlet containers, the only way to redirect JUL calls to Log4j is by 
> setting the 
> {{java.util.logging.manager=org.apache.logging.log4j.jul.LogManager}} system 
> property *globally*. This often breaks the native logging of the container, 
> and could also break other apps on the same container do not use Log4j 2. 
> This also requires changing the container's settings and cannot be expressed 
> in the app itself.
> Another approach (used by slf4j) is to implement 
> {{java.util.logging.Handler}} and then install this handler at the root 
> logger, either programmatically by calling 
> {{LogManager.getLogManager().getLogger("").addHandler(...)}} or by changing 
> logging.properties at the JRE level. This also breaks the container's native 
> logging and other apps, but in different ways than LogManager. I do not 
> advocate this approach, but it's useful to know about it as a background for 
> this feature request.
> (tl;dr: It's impossible to reliably redirect JUL from a webapp without 
> creating a mess).
> Thankfully, Tomcat has a solution for this: Tomcat 
> [JULI|https://tomcat.apache.org/tomcat-8.5-doc/logging.html] allows 
> per-webapp configuration by adding a {{WEB-INF/classes/logging.properties}} 
> file with {{handlers=some.custom.Handler}} inside it. This will redirect JUL 
> calls from this webapp (and this webapp only) to that handler, and that 
> handler then can redirect to Log4j.
> In short: Add a {{java.util.logging.Handler}} implementation that redirects 
> to Log4j so that webapps can use Tomcat's per-webapp configuration and avoid 
> the JUL mess.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (LOG4J2-2012) No compression when using a separate drive in Linux

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved LOG4J2-2012.
--
   Resolution: Fixed
Fix Version/s: 2.9

Fixed by [LOG4J-2016]. Please verify and close this ticket.

> No compression when using a separate drive in Linux
> ---
>
> Key: LOG4J2-2012
> URL: https://issues.apache.org/jira/browse/LOG4J2-2012
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.7
> Environment: Unix
>Reporter: Benjamin Jaton
> Fix For: 2.9
>
>
> When setting up the filePattern of a RollingFileAppender pointing to a 
> different FS than the fileName, the file gets moved but not compressed:
> In this example, /usr/local and /archives are not on the same FS:
> {code}2017-08-11 14:34:33,632 pool-8-thread-1 TRACE 
> DefaultRolloverStrategy.purge() took 15.0 milliseconds 
> 2017-08-11 14:34:33,643 pool-8-thread-1 DEBUG RollingFileManager executing 
> synchronous FileRenameAction[/usr/local/app/logs/app.log to 
> /archives/logs/app-2017-08-11_14-34-33.log, renameEmptyFiles=false] 
> 2017-08-11 14:34:33,646 pool-8-thread-1 ERROR Unable to move file 
> /usr/local/app/logs/app.log to /archives/logs/app-2017-08-11_14-34-33.log: 
> java.nio.file.AtomicMoveNotSupportedException /usr/local/app/logs/app.log -> 
> /archives/logs/app-2017-08-11_14-34-33.log: Invalid cross-device link 
> 2017-08-11 14:34:33,736 pool-8-thread-1 TRACE Renamed file 
> /usr/local/app/logs/app.log to /archives/logs/app-2017-08-11_14-34-33.log 
> using copy and delete{code}
> Also reported here:
> https://stackoverflow.com/questions/43179979/log4j2-rollingfileappender-invalid-cross-device-link



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LOG4J2-875) Log file getting overwritten on Microsoft Windows Machines

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-875:

Summary: Log file getting overwritten on Microsoft Windows Machines  (was: 
Log file getting overwritten on Microsoft Windows Maschines)

> Log file getting overwritten on Microsoft Windows Machines
> --
>
> Key: LOG4J2-875
> URL: https://issues.apache.org/jira/browse/LOG4J2-875
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.0
> Environment: Java 7, Tomcat 7, Windows Server 2012 R2
>Reporter: Luigi Alice
>Priority: Critical
> Attachments: wrong_path.png
>
>
> A problem with slashes?
> does not work since version 2.0, but in rc1:
> filePattern =
> "C:\Server\Webapps\sql2008-test\WEB-INF/log/$\{ctx:remoteDnsName}/$\{ctx:log.uid}_app-%d\{-MM-dd}-%i.log"
> works:
> filePattern =
> "C:/Server/Webapps/sql2008-test/WEB-INF/log/$\{ctx:remoteDnsName}/$\{ctx:log.uid}_app-%d\{-MM-dd}-%i.log"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2005) Level.valueOf() converts level strings to uppercase

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138694#comment-16138694
 ] 

Gary Gregory commented on LOG4J2-2005:
--

Thinking about this a little more: 

- the stock level names are case-insensitive.
- the custom level names are documented as case-sensitive.

These two don't play well together. 

Why not make custom level names case-insensitive? This should fix all of this.

> Level.valueOf() converts level strings to uppercase
> ---
>
> Key: LOG4J2-2005
> URL: https://issues.apache.org/jira/browse/LOG4J2-2005
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.8.2
>Reporter: Paul Burrowes
>
> When using custom levels that are not all uppercase the serialized level 
> strings are not deserializable back into levels because Level.valueOf() 
> assumes all levels will be uppercase.
> https://logging.apache.org/log4j/2.x/manual/customloglevels.html says that 
> levels are case sensitive and the convention is to use uppercase. Having the 
> convention mandatory in code breaks all cases where the level name has 
> already been standardised as mixed case.
> The fix is simple, Level.valueOf() should not convert levelName to uppercase.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (LOG4J2-922) Parameter of mdcId in SyslogAppender has no default value.

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory reopened LOG4J2-922:
-

> Parameter of mdcId in SyslogAppender has no default value.
> --
>
> Key: LOG4J2-922
> URL: https://issues.apache.org/jira/browse/LOG4J2-922
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Reporter: angus.aqlu
>Assignee: Gary Gregory
> Fix For: 2.9
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> I don't need MDC information, but must setting mdcId.  if not set mdcId, 
> throw a IllegalArgumentException;
> {code:xml|title=Configruation|borderStyle=solid}
>  port="13514" protocol="UDP"
> appName="testApp" includeMDC="false" facility="USER"
> newline="true" messageId="Audit" "/>
> {code}
> {code:title=exception info}
> Caused by: java.lang.IllegalArgumentException: No structured id name was 
> supplied
>   at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:92)
>   at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.(Rfc5424Layout.java:139)
>   at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.createLayout(Rfc5424Layout.java:657)
>   at 
> org.apache.logging.log4j.core.appender.SyslogAppender.createAppender(SyslogAppender.java:133)
>   ... 25 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (LOG4J2-922) Parameter of mdcId in SyslogAppender has no default value.

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved LOG4J2-922.
-
   Resolution: Fixed
Fix Version/s: 2.9

Fixed in git master with [~pburrowesOC] patch. Please verify and close.

> Parameter of mdcId in SyslogAppender has no default value.
> --
>
> Key: LOG4J2-922
> URL: https://issues.apache.org/jira/browse/LOG4J2-922
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Reporter: angus.aqlu
>Assignee: Gary Gregory
> Fix For: 2.9
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> I don't need MDC information, but must setting mdcId.  if not set mdcId, 
> throw a IllegalArgumentException;
> {code:xml|title=Configruation|borderStyle=solid}
>  port="13514" protocol="UDP"
> appName="testApp" includeMDC="false" facility="USER"
> newline="true" messageId="Audit" "/>
> {code}
> {code:title=exception info}
> Caused by: java.lang.IllegalArgumentException: No structured id name was 
> supplied
>   at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:92)
>   at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.(Rfc5424Layout.java:139)
>   at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.createLayout(Rfc5424Layout.java:657)
>   at 
> org.apache.logging.log4j.core.appender.SyslogAppender.createAppender(SyslogAppender.java:133)
>   ... 25 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (LOG4J2-922) Parameter of mdcId in SyslogAppender has no default value.

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory reassigned LOG4J2-922:
---

Assignee: Gary Gregory

> Parameter of mdcId in SyslogAppender has no default value.
> --
>
> Key: LOG4J2-922
> URL: https://issues.apache.org/jira/browse/LOG4J2-922
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Reporter: angus.aqlu
>Assignee: Gary Gregory
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> I don't need MDC information, but must setting mdcId.  if not set mdcId, 
> throw a IllegalArgumentException;
> {code:xml|title=Configruation|borderStyle=solid}
>  port="13514" protocol="UDP"
> appName="testApp" includeMDC="false" facility="USER"
> newline="true" messageId="Audit" "/>
> {code}
> {code:title=exception info}
> Caused by: java.lang.IllegalArgumentException: No structured id name was 
> supplied
>   at 
> org.apache.logging.log4j.message.StructuredDataId.(StructuredDataId.java:92)
>   at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.(Rfc5424Layout.java:139)
>   at 
> org.apache.logging.log4j.core.layout.Rfc5424Layout.createLayout(Rfc5424Layout.java:657)
>   at 
> org.apache.logging.log4j.core.appender.SyslogAppender.createAppender(SyslogAppender.java:133)
>   ... 25 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4J2-2009) Rolling appender managers broken on pattern/policy reconfiguration

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16137482#comment-16137482
 ] 

Gary Gregory commented on LOG4J2-2009:
--

I added the unit test 
{{org.apache.logging.log4j.core.appender.rolling.RollingFileAppenderUpdateDataTest}}
 with one method passing and another method failing but annotated with 
{{@Ignore}}. The suggested fix does not work.

> Rolling appender managers broken on pattern/policy reconfiguration
> --
>
> Key: LOG4J2-2009
> URL: https://issues.apache.org/jira/browse/LOG4J2-2009
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.8.2
>Reporter: Leliel Trethowen
>
> LOG4J2-1964 is not fixed. 
> Not fixed per latest snapshot at: 
> https://repository.apache.org/content/groups/snapshots/org/apache/logging/log4j/log4j-core/2.9-SNAPSHOT/
> log4j-core-2.9-20170730.210717-98.jar
> Both RollingFileManager and RollingRandomAccessFileManager are affected.
> Minimal example inline
> {code}
> package leliel;
> import org.apache.logging.log4j.Level;
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.core.appender.ConsoleAppender;
> import org.apache.logging.log4j.core.config.Configurator;
> import org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder;
> import 
> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilderFactory;
> import org.apache.logging.log4j.core.config.builder.impl.BuiltConfiguration;
> public class Main {
> public static void main(String[] args) {
>   //initial config with indexed rollover
> ConfigurationBuilder builder = 
> ConfigurationBuilderFactory.newConfigurationBuilder();
> builder.setConfigurationName("LOG4j2-1964 demo");
> builder.setStatusLevel(Level.ERROR);
> builder.add(builder.newAppender("consoleLog", "Console")
> .addAttribute("target", ConsoleAppender.Target.SYSTEM_ERR));
> builder.add(builder.newAppender("fooAppender", "RollingFile")
> .addAttribute("fileName", "foo.log")
> .addAttribute("filePattern", "foo.log.%i")
> 
> .addComponent(builder.newComponent("SizeBasedTriggeringPolicy")
> .addAttribute("size", "10MB")));
> builder.add(builder.newRootLogger(Level.INFO)
> .add(builder.newAppenderRef("consoleLog"))
> .add(builder.newAppenderRef("fooAppender")));
> Configurator.initialize(builder.build());
> LogManager.getLogger("root").info("just to show it works.");
> //rebuild config with date based rollover
> builder = ConfigurationBuilderFactory.newConfigurationBuilder();
> builder.setConfigurationName("LOG4j2-1964 demo");
> builder.setStatusLevel(Level.ERROR);
> builder.add(builder.newAppender("consoleLog", "Console")
> .addAttribute("target", ConsoleAppender.Target.SYSTEM_ERR));
> builder.add(builder.newAppender("fooAppender", "RollingFile")
> .addAttribute("fileName", "foo.log")
> .addAttribute("filePattern", 
> "foo.log.%d{-MM-dd-HH:mm:ss}.%i")
> 
> .addComponent(builder.newComponent("TimeBasedTriggeringPolicy")
> .addAttribute("interval", 5)
> .addAttribute("modulate", true)));
> builder.add(builder.newRootLogger(Level.INFO)
> .add(builder.newAppenderRef("consoleLog"))
> .add(builder.newAppenderRef("fooAppender")));
> Configurator.initialize(builder.build());
> }
> }
> {code}
> {noformat}
> /usr/local/java/jdk1.7.0_79/bin/java -Didea.launcher.port=7532 
> -Didea.launcher.bin.path=/home/user/leliel/.local/idea-IC-163.12024.16/bin 
> -Dfile.encoding=UTF-8 -classpath 
> 

[jira] [Comment Edited] (LOG4J2-2005) Level.valueOf() converts level strings to uppercase

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16137284#comment-16137284
 ] 

Gary Gregory edited comment on LOG4J2-2005 at 8/22/17 8:04 PM:
---

Hm..., to avoid breaking existing configs we could go the other way by 
converting custom level names to upper case.

And too bad we cannot build the {{ConcurrentHashMap}} with 
{{String.CASE_INSENSITIVE_ORDER}}...


was (Author: garydgregory):
Hm..., to avoid breaking existing configs we could go the other way by 
converting custom level names to upper case.

> Level.valueOf() converts level strings to uppercase
> ---
>
> Key: LOG4J2-2005
> URL: https://issues.apache.org/jira/browse/LOG4J2-2005
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.8.2
>Reporter: Paul Burrowes
>
> When using custom levels that are not all uppercase the serialized level 
> strings are not deserializable back into levels because Level.valueOf() 
> assumes all levels will be uppercase.
> https://logging.apache.org/log4j/2.x/manual/customloglevels.html says that 
> levels are case sensitive and the convention is to use uppercase. Having the 
> convention mandatory in code breaks all cases where the level name has 
> already been standardised as mixed case.
> The fix is simple, Level.valueOf() should not convert levelName to uppercase.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)