Curt Arnold wrote:
> On Feb 27, 2006, at 3:12 PM, Andreas Fester wrote:
>> I indent to commit the attached patch. It adds the
[...]
>> Its primarily a preparation for LOGCXX-126:
>> it will allow to set a system property like "log4cxx.useWideStreams"
>> very early in the application to switch to wide streams output
>> (We need a runtime configuration there; see my comment
>> at http://issues.apache.org/jira/browse/LOGCXX-126#action_12367428).
>>
>
> I'll add comments back to that bug report. I'm scrambling on this, but
same to me; seems like a nightmare ;-)
> it looks like appropriate use of fwide() could ensure that
I read about that some time ago, but IIRC there were also some
portability issues. Need to have a look at it...
> ConsoleAppender uses the correct mode if somebody else already wrote to
> stdout before the first call to ConsoleAppender. Using a system
> property to control this is down on my list of ways to approach the
> problem, I'd rather had configuration parameters or a distinct
> WideConsoleAppender before depending on a system property.
I thought about that, but there is also the internal LogLog logger
which can not be configured through a ConsoleAppender parameter.
Thats why I took the "global" approach, to make sure that *all* output
is always printed through the same stream.
>> Index: include/log4cxx/helpers/properties.h
>> ===================================================================
[...]
> Looks okay, follows the JDK's Properties.containsKey()
Ok.
>> Index: include/log4cxx/helpers/system.h
>> ===================================================================
[...]
> Been trying to avoid non-local static variables. In this case, I doubt
> that props is ever reclaimed. I'd prefer something like:
>
> static PropertiesPtr getProperties() {
> static PropertiesPtr properties(new Properties());
> return properties;
> }
Agree.
>> Index: src/system.cpp
>> ===================================================================
[...]
> I could be misinterpreting this code since I'm looking at the patch
> itself and not the patched code. It looks like your patch would likely
> cache the values of java.io.tmpdir, user.home, environment at
Thats true. The values are written once into the appropriate system
properties.
> initialization and would not reflect changes that occur after that time.
They can be changed by the application by calling System::setProperty().
I dont know the internal implementation of the apr_()-Functions,
but is it possible that their return values (user name, temporary directory,
...) change at runtime?
Thanks,
Andreas
