[ 
https://issues.apache.org/jira/browse/LOG4J2-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&s=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&s=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 org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
>         at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
>         at de.duerr.fitnesse.RunRabbitRun.<clinit>(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 - The parameters 
> handed over to Fitnesse: FitNesseRoot
> Sep 20, 2017 11:37:19 AM fitnesse.ConfigurationParameter loadProperties
> INFORMATION: No configuration file found 
> (C:\Users\admin\Desktop\RabbitDevInstall\Testtool\Resources\plugins.properties)
> Bootstrapping FitNesse, the fully integrated standalone wiki and acceptance 
> testing framework.
> root page: fitnesse.wiki.fs.WikiFilePage: FitNesseRoot
> logger: none
> authenticator: fitnesse.authentication.PromiscuousAuthenticator
> page factory: fitnesse.html.template.PageFactory
> page theme: bootstrap
> Starting FitNesse on port: 80
> {code}
> Here is my log4j configuration file:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <Configuration status="WARN">
>   <Appenders>
>     <Console name="Console" target="SYSTEM_OUT">
>       <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - 
> %msg%n"/>
>     </Console>
>     
>     <RollingFile name="RollingFile" fileName="logs/rrr.log"
>                  
> filePattern="logs/$${date:yyyy-MM}/app-%d{MM-dd-yyyy}-%i.log">
>       <PatternLayout>
>         <Pattern>%d %p %c{1.} [%t] %m%n</Pattern>
>       </PatternLayout>
>       <Policies>
>         <TimeBasedTriggeringPolicy />
>         <OnStartupTriggeringPolicy />
>         <SizeBasedTriggeringPolicy size="20 MB"/>
>       </Policies>
>     </RollingFile>
>     
>   </Appenders>
>   <Loggers>
>     <Root level="all">
>       <AppenderRef ref="RollingFile"/>
>       <AppenderRef ref="Console"/>
>     </Root>
>   </Loggers>
> </Configuration>
> {code}
> And here is my starting script:
> {code:java}
> SET RRR_RESOURCES=.
> SET JAVA_TOOL_OPTIONS=-Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8 -Ds=0
> chcp 65001
> java -version
> java -XshowSettings
> java -jar ${project.artifactId}-${project.version}-jar-with-dependencies.jar 
> start ./Resources
> {code}



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

Reply via email to