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 States)
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.ar...@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.whitw...@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.
