I done yet another iteration of character encoding. The structure is
still based on the JDK 1.4 CharsetDecoder and CharsetEncoder, but now
most of the heavy lifting is done with a small set of implementations
within log4cxx. apr_xlate is used as a fallback in case the nature of
wchar_t is not obvious. apr-iconv is no longer needed and is not built
as part of log4cxx's build process. I'm sure that there will need to
be some tweaks to support some platforms (usually would be indicated by
some missing definitions during compilation or linking). Non-windows
platforms where __STDC_ISO_10646__ is not set will likely fail due to
missing functions in UnicodeHelper. For those platforms, either iconv
needs to be available or functions that convert between UCS-4 and
wchar_t values need to be provided. At some later time, I'll review
the apr-iconv source and see if I can see how they anticipated those
platforms. Eventually, will probably provide a build option to
hard-code the external encoding to UTF-8 which would allow all the
encoding/decoding steps to be short-circuited with copies when you know
at compile time that would be safe.
I've integrated a patch submitted by Andreas Fester which contained
reworks for the TelnetAppender and supporting classes implemented with
APR's socket implementation. I haven't tested it and had to hack some
things to get it to compile on Windows. If you have any comments or
issues with it, please let the list know or add a comment to
http://issues.apache.org/jira/browse/LOGCXX-80
My next task will be to jump over to log4j to address and issue with
the RollingFileAppender's to get them ready to be ported over to
log4cxx.
- Re: Recent updates Curt Arnold
- Re: Recent updates Ceki G�lc�
- Call for developers (Re: Recent updates) Curt Arnold
- Re: Call for developers (Re: Recent updates) Ceki G�lc�
- Re: Call for developers (Re: Recent update... Curt Arnold
- Re: Call for developers (Re: Recent u... Ceki G�lc�
- Re: Call for developers (Re: Recent u... Tommi M�kitalo
