logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: PropertyConfigurator::configure file encoding
Date Mon, 07 Feb 2011 05:21:47 GMT
I'd suggest looking at System::GetProperty in system.cpp, specifically the last section that
calls apr_get_env.  It appears that the problem is specific to the introduction of environment
variables.  I'd suggest a native Windows alternative that calls GetEnvironmentVariableW which
bypasses the conversion to and from an single byte representation.  Alternatively, you could
look at the implementation of apr_get_env and try to determine whether log4cxx called it incorrectly
or whether it has a bug or limitation.

I would appreciate it if you could file a bug report at http://issues.apache.org/jira.

On Feb 3, 2011, at 11:24 AM, Jason S. Whitwill wrote:

> Thank you very much for your reply.
> The operating system is Windows 7 64 bits English version.
> Under region and language in the control panel, everything is set to English (United
> The user name has Chinese characters which are interpreted correctly in Windows Explorer
and in my Unicode MFC application.
> Log4cxx was built with Visual C++ 2005 and I don't recall changing anything in the default
configuration when it was built (it has been a while).
> The log4cxx version is 0.10.0
> When using environment variables for the filename (not the path) I get a file output
but the characters of the file name are garbled (from some other language).
> If I execute the following code snippet, it interprets the environment variable correctly
and the file is output with the correct path and file name.
>    wchar_t lPathPtr[2048];
>        size_t lPathSize = 0;
>        _wgetenv_s( &lPathSize, lPathPtr, 2048, L"APPDATA" );
>    if ( lPathPtr != NULL )
>    {
>        wchar_t lPath[2048];
>        StringCbPrintfW(lPath, 2048, L"%s\\unicode_test.txt", lPathPtr);
>        log4cxx::LayoutPtr layout(new log4cxx::SimpleLayout());
>        log4cxx::FileAppenderPtr appender(new log4cxx::FileAppender(layout, lPath, true));
>        LoggerPtr logger(Logger::getLogger("MyApp"));
>        logger->addAppender( appender );
>        wchar_t lString[512];
>        mTextBox.GetWindowTextW( lString, 512 );
>        LOG4CXX_INFO(logger, lString );
>    }
> However if I create a configuration file that looks like this...
> log4j.rootLogger=info, R
> log4j.appender.R=org.apache.log4j.RollingFileAppender
> log4j.appender.R.File=${TESTENV}
> log4j.appender.R.MaxFileSize=100KB
> log4j.appender.R.MaxBackupIndex=1
> log4j.appender.R.layout=org.apache.log4j.PatternLayout
> log4j.appender.R.layout.ConversionPattern=%r %p %t %c - %m%n
> ...and open that configuration file with a code snippet that looks like this...
>     LoggerPtr logger(Logger::getLogger("MyApp"));
>     PropertyConfigurator::configure("test.logcfg");
>     LOG4CXX_INFO(logger, "Entering application.");
> ... the file name ends up being garbled with funny characters.
> Obviously if I replace ${TESTENV} with ${APPDATA}/unicode_test.txt, I don't see any output
because the garbled folder path doesn't exist. This seems to be the case for European characters
outside of the ascii range as well (like the german umlaut or the accent aigu in French).
> Since I do have a copy of the log4cxx source code, is there a place you would recommend
I start if I was to work around the issue by modifying log4cxx?
> My main challenge is the fact that I need to have a default configuration file that outputs
to a location on Windows that doesn't require elevated UAC privileges. This wouldn't work
for our international customers who have non-western-european characters in their user name.
The problem is further complicated by the fact that our main library (not in the case of the
test applications I created to rule out the problem) delay loads log4cxx and manually creating
the layout and appender was giving us grief.
> Thanks again for your valuable time.
> Jason
> -----Original Message-----
> From: Curt Arnold [mailto:curt.arnld@gmail.com] On Behalf Of Curt Arnold
> Sent: Thursday, February 03, 2011 12:33 AM
> To: Log4CXX User
> Subject: Re: PropertyConfigurator::configure file encoding
> Property files in Java are by definition in ISO-8859-1 which cannot support Chinese characters
without using escape characters (see http://download.oracle.com/javase/6/docs/api/java/util/Properties.html).
 log4cxx follows this convention so that it is compatible with log4j configuration files.
> However, the issue is the substitution of the contents of the APPDATA environment variable
into the evaluation of the configuration which should occur after the properties file in parsed
and should happen in LogString (aka Unicode) space.
> I'm guessing things are failing since the evaluation of APPDATA does not match an existing
directory and therefore the appender fails.  It would be interesting to experiment with an
environment variable for the file name (not the path) to see how the name is mangled.
> There are a couple of things that would be very useful to know:
> What operating system and version is being used?
> What is the default character encoding (control panel or $ locale charmap)?
> What settings are used to build log4cxx?
> What is the observed behavior when using environment variables for the filename (not
the path)?  What were the expected behavior?
> I'm pretty confident that the property files are correctly always interpreted as ISO-8859-1
regardless of the default encoding.
> log4cxx depends on APR to get the environment variables and for file IO, so something
unexpected could be happening there or log4cxx could be mangling the substitution.
> _______________________
> Jason Whitwill
> Software Designer
> Pleora Technologies Inc.
> Phone: +1-613-270-0625 ext 153
> Fax: +1-613-270-1425
> Jason.Whitwill@pleora.com
> www.pleora.com
> This communication contains confidential information intended only for the addressee(s).
If you have received this communication in error, please notify us immediately and delete
this communication from your mail box.

View raw message