Log4cxx obliterates the TZ setting...
Ok... I think I found a work-around for my app anyway: I noticed that this whole thing happens when the property configurator is reading the file configuring things... so I now set my timezone (which I never had to do before), from an appliction .ini file setting AFTER the propertyconfigurator is initialized. There has got to be a better way to do this... will let you guys know if we find something. Renny Koshy President CEO RUBIX Information Technologies, Inc. www.rubixinfotech.com __ We have some code which started behaving strange after going to log4cxx for logging... I've isolated it down to the fact that log4cxx obliterates the TZ settings in timezone.cpp and dailyrollingfileappender.cpp Questions: Instead of changing to GMT to calculate the diff, why not use gmtime() or gmtime_r()? - I've done this in our code that had to calculate this difference for a LogFile class that dates back almost 8 years... - This way there is not side-effect... *IF* I change the code to work that way, any chance of having it included in the 'official' package? I also noticed that on Solaris using CC, if I compile the whole thing after a make clean, it works. But then if I go change a file recompile... it doesn't work. Looks like the problem is in the 'cache' files that Sun's CC uses for templates somehow during the build process, those files are either deleted or overwritten... and the next time, when you change a single file compile... the linker cannot file a bunch of templates... Regards Renny Koshy President CEO RUBIX Information Technologies, Inc. www.rubixinfotech.com
Log4cxx obliterates the TZ setting...
We have some code which started behaving strange after going to log4cxx for logging... I've isolated it down to the fact that log4cxx obliterates the TZ settings in timezone.cpp and dailyrollingfileappender.cpp Questions: Instead of changing to GMT to calculate the diff, why not use gmtime() or gmtime_r()? - I've done this in our code that had to calculate this difference for a LogFile class that dates back almost 8 years... - This way there is not side-effect... *IF* I change the code to work that way, any chance of having it included in the 'official' package? I also noticed that on Solaris using CC, if I compile the whole thing after a make clean, it works. But then if I go change a file recompile... it doesn't work. Looks like the problem is in the 'cache' files that Sun's CC uses for templates somehow during the build process, those files are either deleted or overwritten... and the next time, when you change a single file compile... the linker cannot file a bunch of templates... Regards Renny Koshy President CEO RUBIX Information Technologies, Inc. www.rubixinfotech.com
Re: Log4cxx obliterates the TZ setting...
I had noticed the potential for the problem and logged it as http://nagoya.apache.org/jira/browse/LOGCXX-11. Thanks for confirming that is actually a problem. My suspicion is that gmtime or gmtime_r is not adequate since log4cxx may need to format times to a time-zone other than the current time zone. However, it might be an optimization if the timezone for the layout and the current timezone are the same. I guess the first thing is to at least reset the value of TZ to the initial value after collecting time zone offsets. On Sep 1, 2004, at 11:40 AM, [EMAIL PROTECTED] wrote: We have some code which started behaving strange after going to log4cxx for logging... I've isolated it down to the fact that log4cxx obliterates the TZ settings in timezone.cpp and dailyrollingfileappender.cpp Questions: Instead of changing to GMT to calculate the diff, why not use gmtime() or gmtime_r()? - I've done this in our code that had to calculate this difference for a LogFile class that dates back almost 8 years... - This way there is not side-effect... *IF* I change the code to work that way, any chance of having it included in the 'official' package?
Re: Log4cxx obliterates the TZ setting...
Curt:
Added the changes to do this... (save/restore the TZ back)... HOWEVER... I'm seeing that there is some sort of static initialization that's resetting the TZ?
The following two files have my save restore code added around the tzset() these files have the tcout being used to display when I save / restore them... they should be commented out I guess...
However, I still see the following when executing my code. Notice how it goes from US/Eastern to '' ... and then to US/Eastern... and then to GMT... and the SmartACD.cpp:174 is the first print statement from MY code.. so I assume a static initializer or two is being kicked in... but where?? I don't use any static log4cxx stuff...
~~
TimeZone::TimeZone() - Old timezone being saved as 'US/Eastern' and setting to 'TZ=GMT'
TimeZone::TimeZone() - Restored timezone to TZ=US/Eastern
TimeZone::TimeZone() - Old timezone being saved as '' and setting to 'TZ='
TimeZone::TimeZone() - Restored timezone to TZ=
SmartACD.cpp:174 - TZ = 'US/Eastern' - TZName[0] = 'EST', TZName[1] = 'EDT'
SmartACD.cpp:181 - TZ = 'US/Eastern' - TZName[0] = 'EST', TZName[1] = 'EDT'
TimeZone::TimeZone() - Old timezone being saved as 'US/Eastern' and setting to 'TZ='
TimeZone::TimeZone() - Restored timezone to TZ=US/Eastern
TimeZone::TimeZone() - Old timezone being saved as 'GMT' and setting to 'TZ='
TimeZone::TimeZone() - Restored timezone to TZ=GMT
Could not connect to remote log4cxx server at [ultra60]. We will try again later.
Connection refused
TimeZone::TimeZone() - Old timezone being saved as '' and setting to 'TZ='
TimeZone::TimeZone() - Restored timezone to TZ=
Could not find value for key log4j.appender.sapp2
Could not instantiate appender named sapp2.
SmartACD.cpp:191 - TZ = 'GMT' - TZName[0] = 'GMT', TZName[1] = ' '
~~
My source code that created the above log entries...
~~
int main(int argc, char *argv[])
{
putenv(TZ=US/Eastern);
printf(%s:%d - TZ = '%s' - TZName[0] = '%s', TZName[1] = '%s'\n,
__FILE__, __LINE__,
getenv(TZ) ? getenv(TZ) : ,
tzname[0], tzname[1]);
openlog(SmartACD, LOG_PID, LOG_USER);
printf(%s:%d - TZ = '%s' - TZName[0] = '%s', TZName[1] = '%s'\n,
__FILE__, __LINE__,
getenv(TZ) ? getenv(TZ) : ,
tzname[0], tzname[1]);
sigset(SIGHUP,sig_hdlr);
sigset(SIGUSR2,sig_hdlr);
log4cxx::PropertyConfigurator::configureAndWatch(SmartACD.ini);
printf(%s:%d - TZ = '%s' - TZName[0] = '%s', TZName[1] = '%s'\n,
__FILE__, __LINE__,
getenv(TZ) ? getenv(TZ) : ,
tzname[0], tzname[1]);
~~
Renny Koshy
President CEO
RUBIX Information Technologies, Inc.
www.rubixinfotech.com
Curt Arnold [EMAIL PROTECTED]
09/01/2004 01:56 PM
Please respond to Log4CXX User
To:Log4CXX User log4cxx-user@logging.apache.org
cc:
Subject:Re: Log4cxx obliterates the TZ setting...
I had noticed the potential for the problem and logged it as
http://nagoya.apache.org/jira/browse/LOGCXX-11. Thanks for confirming
that is actually a problem. My suspicion is that gmtime or gmtime_r is
not adequate since log4cxx may need to format times to a time-zone
other than the current time zone. However, it might be an optimization
if the timezone for the layout and the current timezone are the same.
I guess the first thing is to at least reset the value of TZ to the
initial value after collecting time zone offsets.
On Sep 1, 2004, at 11:40 AM, [EMAIL PROTECTED] wrote:
We have some code which started behaving strange after going to
log4cxx for logging... I've isolated it down to the fact that log4cxx
obliterates the TZ settings in timezone.cpp and
dailyrollingfileappender.cpp
Questions:
Instead of changing to GMT to calculate the diff, why not use
gmtime() or gmtime_r()?
- I've done this in our code that had to calculate
this difference for a LogFile class that dates back almost 8 years...
- This way there is not side-effect...
*IF* I change the code to work that way, any chance of having
it included in the 'official' package?
timezone.cpp
Description: Binary data
dailyrollingfileappender.cpp
Description: Binary data
