I finally got back to this. This work around worked for me, thanks. In addition to making mods to allow configure to set LOG4CXX_LOCALE_ENCODING_UTF8, it appears that charsetencoding.cpp needs to include log4cxx_private.h, so it can see this define.
Russ -----Original Message----- From: Curt Arnold [mailto:[EMAIL PROTECTED] Sent: Saturday, June 25, 2005 9:18 PM To: Log4CXX User Subject: Re: Loggers and threading On Jun 24, 2005, at 5:53 PM, Moul, Russell G wrote: > I'm encountering problems using multiple threads that log to the same > logger. The following is a simple test I put together to issolate the > problem and a backtrace from the failure. Any suggestions would be > welcome. > Thanks for the report. I don't have time to research it at the moment, but I wanted to share my thoughts from just looking at the stack trace. If someone else wants to dig deeper, please feel free. Any chance that your implementation of standard template library is not reentrant? The call itself looks like something going wrong on a call to STL on a resource on the stack. Maybe things got dorked somewhere else, but it looks really clean for some type of overwrite or collision on a shared resource. The back trace appears to be in the char* to wchar_t* decoder implemented using apr_xlate. If you just need a work-around, one of the other decoder/encoder combinations might not suffer from the same issue (or it may be totally unrelated to the encoding and something else entirely). If you know that your locale encoding is UTF-8, you can bypass all the encoding/decoding hassle by specifying the preprocessor macro LOG4CXX_LOCALE_IS_UTF8=1 (unfortunately neither of the builds has an option to specify that at this time) and LOG4CXX_LOGCHAR_IS_UTF8=1 (I think -Dlogchar=utf-8 on the Ant build) which is cause the "trivial" decoder/encoder pair to be used for conversion from the locale's char* to the internal character representation.
