The issues that would benefit from use of APR:
Time and timezone related bugs: log4cxx currently changes the TZ environment variable which could have serious side-effects on the calling application and calls non-thread safe formatting methods (bugs LOGCXX-11, LOGCXX-15 and LOGCXX-17). I consider this a killer set of bugs and don't see any real value in doing another release until they are fixed and there doesn't appear to be a easy fix without adding a dependency on APR and/or ICU. APR provides portable datetime query and formatting methods and can use non-default timezone offsets, but does not provide any mechanism to determine a offset for an arbitrary timezone identifier. ICU4C provides timezone objects, calendars and formatting but requires time values from another source.
Threading related bugs: There have been several thread related issues mentioned on the mailing list (http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4cxx- [EMAIL PROTECTED]&msgId=1895759, http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4cxx- [EMAIL PROTECTED]&msgId=1629914) in addition to LOGCXX-36.
Unicode: Both APR and ICU provide character encoding methods needed to support Unicode and arbitrary encoding on FileAppenders.
My thinking is that log4cxx would be required to build log4cxx and that APR types and methods should be used where at all possible. ICU4C or the Win32 API would be needed to support timezones other the the default and GMT, but if desired, log4cxx could be built without it.
I'd appreciate any comments. I might do some exploratory development, but won't commit anything till we take a vote.
