On May 30, 2007, at 3:54 AM, Bala wrote:
Curt Arnold <carnold <at> apache.org> writes:
If you used the make build for apr-util, what happens if you run
"make check"? If you didn't, could you try it. I believe there is a
test of apr_xlate in the suite, but haven't checked.
The testxlate fails for UTF-8 <-> ISO-8859-1 . it passes for utf-8-
utf-8
Sounds like there is an issue with apr-util on the platform, if you
find that problem it will likely fix the log4cxx issue. I'll be
unavailable the next few days, so your best resource is the APR bug
list or [EMAIL PROTECTED] Before reporting it, you should check
if it still occurs with the latest APR. If it doesn't, then update
log4cxx to use the latest APR.
Is iconv installed on your machine?
iconv is installed in the system
Do you see a list of encodings if you do "iconv -l"?
yes i see a a list of encodings.
If you were specifying an encoding, is it one that appears in the
list? (If not, change it to an supported encoding).
I have not specified any encoding
If you were not specifying an encoding, does the problem disappear if
you do specify one of the encodings from the list?
Are you calling setlocale(LC_ALL, "") sometime before log4cxx is
initialized? If not, then the value of the default encoding
retrieved by log4cxx may not meet your expectations. There is an
open bug related to the issue so hopefully eventually log4cxx will
track changes to the locale, but right now it only determines the
default encoding once and does not respond to subsequent changes.
I havenot done this before initialization, but doing this also
doesnt help
I am still getting the escape sequences. i am building log4cxx with
logchar
wchar_t. Will that be of an issue?
wchar_t should not be an issue.
Looks like your immediate work-around is to specify encoding=utf-8 in
your configuration file for your appender.
