Custom Search
|
Date: December 22, 2006
From: "Noordeen, Roxy" <Roxy.Noordeen@xxxxxxxxxxxxxxxxx>
Thanks. -----Original Message----- From: Curt Arnold [mailto:carnold@xxxxxxxxxx] Sent: Thursday, December 21, 2006 2:42 PM To: Log4CXX User Subject: Re: missing stacktrace for jdbc appenders On Dec 18, 2006, at 3:03 PM, Noordeen, Roxy wrote: > > Hi, > I am using below configurations. I am getting stack trace for my > console > appender, where as staketrace is null in my jdbc appender. > I am not sure what the issue with jdbc appender is. All my other > fields > are getting logged properly in the oracle database except the stack > trace. I tried both clob and varchar2 fields in oracle to store stack > trace. > > Please help. > Looks like a log4j question which should be posted on log4j-user, not log4cxx-user. log4j and JDK version could be helpful too.
Date: December 22, 2006
From: "Tomas Andersen" <tomas.andersen@xxxxxxxxxx>
In-reply-to:
<1C753C7B-DB65-49BD-8DED-BA4AB9B4D909@xxxxxxxxxx>
References:
<1C753C7B-DB65-49BD-8DED-BA4AB9B4D909@xxxxxxxxxx>
>>
>> One time I added
>> oss << std::ends;
>> before the LOG4CXX_DEBUG call.
>>
>>
>> This log line never appeared in the log and the nextMethodToCall()
>> method was never called. It seemed like the thread where this was
done
>> hanged in the LOG4CXX_DEBUG call!
>>
>> Great if you could check that. I'm using the head version of LOG4CXX
>> downloaded the 19. december this year =)
>>
>>
>The behavior sounds consistent with LOGCXX-162 (http://
>issues.apache.org/jira/browse/LOGCXX-162?page=all) which was marked as
resolved on 4-
>Dec-2006. Basically the charset decoder that called mbstowcs would go
into a loop if
>the string contained a null character. However, the charset decoder in
use depends on
>the platform and build settings and it is possible that the same defect
exists in some
>of the other charset decoders.
>
>Could you let us know what platform and compiler you are using and
>any build switches. If you are using the ant build, did the unit
>test suite complete successfully. The bug fix for LOGCXX-162 added a
test that should
>fail if the default character decoder has that type of flaw. I'm not
sure if "make
>check" works on the autotools build to do the same thing. There was a
recent patch that
>might have fixed it.
Hi! Thanks for the quick answer!.
Here's some info about the platform etc:
Platform: Linux CentOS 4.4
$ uname -a
Linux odin02.lokal.lan 2.6.9-42.ELsmp #1 SMP Sat Aug 12 09:39:11 CDT
2006 i686 i686 i386 GNU/Linux
$ g++ --version
g++ (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
I'm using the ant script for building and it seemed to me that all
unit-tests were successfully run.
There is however a possibility that you see something in the print that
I don't so here it is.
The build target 'run-unittest' prints:
[exec]
........................................................................
............................log4cxx: Empty conversion specifier
[exec] .log4cxx: Empty conversion specifier
[exec] .............................................log4cxx: Cannot
get information about host: unknown.host.local
[exec] Waiting until next second and 100 millis.Done
waiting.08:09:41,100 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test1:123 - Hello---0
[exec] 08:09:41,601 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test1:123 - Hello---1
[exec] 08:09:42,101 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test1:123 - Hello---2
[exec] 08:09:42,602 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test1:123 - Hello---3
[exec] 08:09:43,103 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test1:123 - Hello---4
[exec] 08:09:44,101 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test2:167 - Hello---0
[exec] 08:09:44,602 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test2:167 - Hello---1
[exec] 08:09:45,103 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test2:167 - Hello---2
[exec] 08:09:45,606 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test2:189 - Hello---3
[exec] 08:09:46,107 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test2:189 - Hello---4
[exec] Waiting until next second and 100 millis.Done
waiting.08:09:47,100 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test4:289 - Hello---0
[exec] 08:09:47,601 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test4:289 - Hello---1
[exec] 08:09:48,101 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test4:289 - Hello---2
[exec] 08:09:48,602 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test4:311 - Hello---3
[exec] 08:09:49,102 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test4:311 - Hello---4
[exec] Waiting until next second and 100 millis.Done
waiting.08:09:50,100 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test5:360 - Hello---0
[exec] 08:09:50,601 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test5:360 - Hello---1
[exec] 08:09:51,101 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test5:360 - Hello---2
[exec] 08:09:51,602 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test5:360 - Hello---3
[exec] 08:09:52,103 [0xb7c3cb20] DEBUG
log4j.TimeBasedRollingTest#test5:360 - Hello---4
[exec] ................................................log4cxx: No
appender could be found for logger (x).
[exec] log4cxx: Please initialize the log4cxx system properly.
[exec] ....................................................log4cxx:
Threshold ="".
[exec] log4cxx: Retreiving an instance of Logger.
[exec] log4cxx: Setting
[org.apache.log4j.rolling.FilterBasedRollingTest] additivity to [false].
[exec] log4cxx: Class name:
[org.apache.log4j.rolling.RollingFileAppender]
[exec] log4cxx: Parsing rolling policy of class:
"org.apache.log4j.rolling.FixedWindowRollingPolicy"
[exec] log4cxx: Setting option name=[fileNamePattern],
value=[output/filterBased-test1.%i]
[exec] log4cxx: Setting option name=[minIndex], value=[0]
[exec] log4cxx: Parsing triggering policy of class:
"org.apache.log4j.rolling.FilterBasedTriggeringPolicy"
[exec] log4cxx: Setting option name=[levelMin], value=[info]
[exec] log4cxx: OptionConverter::toLevel: no class name specified,
level=[info]
[exec] log4cxx: Parsing layout of class:
"org.apache.log4j.PatternLayout"
[exec] log4cxx: Setting option name=[ConversionPattern],
value=[%m%n]
[exec] log4cxx: Setting option name=[file],
value=[output/filterBased-test1.log]
[exec] log4cxx: Setting option name=[append], value=[false]
[exec] log4cxx: Adding appender named [ROLLING] to logger
[org.apache.log4j.rolling.FilterBasedRollingTest].
[exec] log4cxx: Level value for
org.apache.log4j.rolling.FilterBasedRollingTest is [debug].
[exec] log4cxx: OptionConverter::toLevel: no class name specified,
level=[debug]
[exec] log4cxx: org.apache.log4j.rolling.FilterBasedRollingTest
level set to DEBUG
[exec] log4cxx: Level value for root is [info].
[exec] log4cxx: OptionConverter::toLevel: no class name specified,
level=[info]
[exec] log4cxx: root level set to INFO
[exec] log4cxx: Class name: [org.apache.log4j.ConsoleAppender]
[exec] log4cxx: Parsing layout of class:
"org.apache.log4j.PatternLayout"
[exec] 2006-12-22 08:09:52,935 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---0
[exec] 2006-12-22 08:09:52,937 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---1
[exec] 2006-12-22 08:09:52,938 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---2
[exec] log4cxx: Setting option name=[ConversionPattern],
value=[%m%n]
[exec] 2006-12-22 08:09:52,941 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---3
[exec] log4cxx: Adding appender named [CONSOLE] to logger [root].
[exec] 2006-12-22 08:09:52,942 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---4
[exec] 2006-12-22 08:09:52,942 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---5
[exec] 2006-12-22 08:09:52,943 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---6
[exec] 2006-12-22 08:09:52,943 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---7
[exec] 2006-12-22 08:09:52,943 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---8
[exec] 2006-12-22 08:09:52,943 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---9
[exec] 2006-12-22 08:09:52,943 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--10
[exec] 2006-12-22 08:09:52,944 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--11
[exec] 2006-12-22 08:09:52,944 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--12
[exec] 2006-12-22 08:09:52,944 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--13
[exec] 2006-12-22 08:09:52,945 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--14
[exec] 2006-12-22 08:09:52,945 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--15
[exec] 2006-12-22 08:09:52,945 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--16
[exec] 2006-12-22 08:09:52,945 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--17
[exec] 2006-12-22 08:09:52,945 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--18
[exec] 2006-12-22 08:09:52,945 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--19
[exec] 2006-12-22 08:09:52,946 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--20
[exec] 2006-12-22 08:09:52,946 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--21
[exec] 2006-12-22 08:09:52,947 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--22
[exec] 2006-12-22 08:09:52,947 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--23
[exec] 2006-12-22 08:09:52,947 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--24
[exec] 2006-12-22 08:09:52,950 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---0
[exec] 2006-12-22 08:09:52,951 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---1
[exec] 2006-12-22 08:09:52,951 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---2
[exec] 2006-12-22 08:09:52,951 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---3
[exec] 2006-12-22 08:09:52,951 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---4
[exec] 2006-12-22 08:09:52,951 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---5
[exec] 2006-12-22 08:09:52,951 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---6
[exec] 2006-12-22 08:09:52,951 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---7
[exec] 2006-12-22 08:09:52,951 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---8
[exec] 2006-12-22 08:09:52,951 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---9
[exec] 2006-12-22 08:09:52,951 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--10
[exec] 2006-12-22 08:09:52,952 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--11
[exec] 2006-12-22 08:09:52,952 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--12
[exec] 2006-12-22 08:09:52,952 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--13
[exec] 2006-12-22 08:09:52,952 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--14
[exec] 2006-12-22 08:09:52,952 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--15
[exec] 2006-12-22 08:09:52,953 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--16
[exec] 2006-12-22 08:09:52,953 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--17
[exec] 2006-12-22 08:09:52,953 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--18
[exec] 2006-12-22 08:09:52,953 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--19
[exec] 2006-12-22 08:09:52,953 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--20
[exec] 2006-12-22 08:09:52,954 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--21
[exec] 2006-12-22 08:09:52,954 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--22
[exec] 2006-12-22 08:09:52,954 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--23
[exec] 2006-12-22 08:09:52,954 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--24
[exec] 2006-12-22 08:09:52,957 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---0
[exec] 2006-12-22 08:09:52,958 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---1
[exec] 2006-12-22 08:09:52,958 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---2
[exec] 2006-12-22 08:09:52,958 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---3
[exec] 2006-12-22 08:09:52,958 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---4
[exec] 2006-12-22 08:09:52,958 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---5
[exec] 2006-12-22 08:09:52,958 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---6
[exec] 2006-12-22 08:09:52,959 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---7
[exec] 2006-12-22 08:09:52,959 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---8
[exec] 2006-12-22 08:09:52,959 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---9
[exec] 2006-12-22 08:09:52,959 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--10
[exec] 2006-12-22 08:09:52,960 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--11
[exec] 2006-12-22 08:09:52,960 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--12
[exec] 2006-12-22 08:09:52,960 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--13
[exec] 2006-12-22 08:09:52,961 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--14
[exec] 2006-12-22 08:09:52,961 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--15
[exec] 2006-12-22 08:09:52,962 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--16
[exec] 2006-12-22 08:09:52,963 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--17
[exec] 2006-12-22 08:09:52,963 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--18
[exec] 2006-12-22 08:09:52,964 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--19
[exec] 2006-12-22 08:09:52,964 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--20
[exec] 2006-12-22 08:09:52,964 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--21
[exec] 2006-12-22 08:09:52,965 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--22
[exec] ............
[exec] 2006-12-22 08:09:52,966 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--23
[exec] 2006-12-22 08:09:52,966 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--24
[exec] 2006-12-22 08:09:52,970 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---0
[exec] 2006-12-22 08:09:52,971 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---1
[exec] 2006-12-22 08:09:52,971 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---2
[exec] 2006-12-22 08:09:52,971 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---3
[exec] 2006-12-22 08:09:52,971 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---4
[exec] 2006-12-22 08:09:52,971 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---5
[exec] 2006-12-22 08:09:52,972 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---6
[exec] 2006-12-22 08:09:52,972 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---7
[exec] 2006-12-22 08:09:52,972 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---8
[exec] 2006-12-22 08:09:52,972 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello---9
[exec] 2006-12-22 08:09:52,972 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--10
[exec] 2006-12-22 08:09:52,974 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--11
[exec] 2006-12-22 08:09:52,974 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--12
[exec] 2006-12-22 08:09:52,974 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--13
[exec] 2006-12-22 08:09:52,974 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--14
[exec] 2006-12-22 08:09:52,974 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--15
[exec] 2006-12-22 08:09:52,975 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--16
[exec] 2006-12-22 08:09:52,975 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--17
[exec] 2006-12-22 08:09:52,975 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--18
[exec] 2006-12-22 08:09:52,975 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--19
[exec] 2006-12-22 08:09:52,975 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--20
[exec] 2006-12-22 08:09:52,976 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--21
[exec] 2006-12-22 08:09:52,976 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--22
[exec] 2006-12-22 08:09:52,976 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--23
[exec] 2006-12-22 08:09:52,977 DEBUG
org.apache.log4j.rolling.SizeBasedRollingTest -Hello--24
[exec] OK (258 tests)
>I believe that "a" was interpreted as being a char or wchar_t value,
basically the same as if you did:
>
>"This is a number test: " + '\u0005';
>
>in Java. If you increase the value of a to 67 or so, you'd should see
an printable character in the log. That is
>a behavior that is built into std::basic_string and not much we can do
about it.;
>
>log4cxx does contain a logstream class that was intended to make a
std::basic_stream compatible logging interface,
>however there are some performance and usability issues around the
current implementation and no obvious way to
>maintain full compatibility with std::basic_string and eliminate the
performance problem.
>
>You could also create a formatting method that returned a std::string
and use that in place of the message.
>The macros would short circuit the evaluation of the formatter if the
threshold was not reached.
>Something like:
>
>LOG4CXX_DEBUG(logger, cfmt("This is a number test: %d", a));
Ok.. thanks... seems to be a good idea! I'll try that! Thanks for making
logging so much easier!
I have really improved the efficiency in creating c++ code when the log
system is so flexible =)
Tomas Andersen
moreCom AS
www.morecom.no
Date: December 21, 2006
From: Curt Arnold <carnold@xxxxxxxxxx>
In-reply-to:
<FF1C90C717AC6743855E6452A2338F270401187D@xxxxxxxxxxxxxxxxxxx>
References:
<FF1C90C717AC6743855E6452A2338F270401187D@xxxxxxxxxxxxxxxxxxx>
On Dec 18, 2006, at 3:03 PM, Noordeen, Roxy wrote:
Hi,I am using below configurations. I am getting stack trace for my consoleappender, where as staketrace is null in my jdbc appender.I am not sure what the issue with jdbc appender is. All my other fieldsare getting logged properly in the oracle database except the stack trace. I tried both clob and varchar2 fields in oracle to store stack trace. Please help.
Looks like a log4j question which should be posted on log4j-user, not log4cxx-user. log4j and JDK version could be helpful too.
Date: December 21, 2006
From: Curt Arnold <carnold@xxxxxxxxxx>
In-reply-to:
<938D7E14D9AF6B42936905D8DE7D452B59F15F@xxxxxxxxxxxxxxxxx>
References:
<938D7E14D9AF6B42936905D8DE7D452B59F15F@xxxxxxxxxxxxxxxxx>
On Dec 21, 2006, at 4:21 AM, Tomas Andersen wrote:
Hi!When using log4cxx I usually do something like this to build the log string.std::stringstream oss; oss << "This is my logging and the result is: "; int i=getANumber(); if( i == 1 ) { oss << "1"; } else { oss << "something else"; } LOG4CXX_DEBUG(logger, oss.str(); nextMethodToCall(); [This works ok.] One time I added oss << std::ends; before the LOG4CXX_DEBUG call.This log line never appeared in the log and the nextMethodToCall() method was never called. It seemed like thethread where this was done hanged in the LOG4CXX_DEBUG call!Great if you could check that. I'm using the head version of LOG4CXX downloaded the 19. december this year =)
The behavior sounds consistent with LOGCXX-162 (http:// issues.apache.org/jira/browse/LOGCXX-162?page=all) which was marked as resolved on 4-Dec-2006. Basically the charset decoder that called mbstowcs would go into a loop if the string contained a null character. However, the charset decoder in use depends on the platform and build settings and it is possible that the same defect exists in some of the other charset decoders.
Could you let us know what platform and compiler you are using and any build switches. If you are using the ant build, did the unit test suite complete successfully. The bug fix for LOGCXX-162 added a test that should fail if the default character decoder has that type of flaw. I'm not sure if "make check" works on the autotools build to do the same thing. There was a recent patch that might have fixed it.
Another thing while I'm at it:I have used the LOG4CXX_DEBUG command with concatuating several std::string(s) as parameters, ie: LOG4CXX_DEBUG(logger, "This is a string: " + myFirstString + " and this is another one: " + myOtherString );It does only work with strings. Do you have any plans of making this possible for other types aswell (as in log4j)..? (I know java has the advantage of toString() and that is probably why this doesn't work right?)int a = 5; LOG4CXX_DEBUG(logger, "This is a number test: " + a); It compiled but resulted in the following logline: .... - is a number test: The first word was cut and the integer was never printed.
I believe that "a" was interpreted as being a char or wchar_t value, basically the same as if you did:
"This is a number test: " + '\u0005';in Java. If you increase the value of a to 67 or so, you'd should see an printable character in the log. That is a behavior that is built into std::basic_string and not much we can do about it.;
log4cxx does contain a logstream class that was intended to make a std::basic_stream compatible logging interface, however there are some performance and usability issues around the current implementation and no obvious way to maintain full compatibility with std::basic_string and eliminate the performance problem.
You could also create a formatting method that returned a std::string and use that in place of the message. The macros would short circuit the evaluation of the formatter if the threshold was not reached. Something like:
LOG4CXX_DEBUG(logger, cfmt("This is a number test: %d", a));
Date: December 21, 2006
From: "Stephen Bartnikowski" <sbartnikowski@xxxxxxxxxxxxxxxxxx>
In-reply-to:
<938D7E14D9AF6B42936905D8DE7D452B59F15F@xxxxxxxxxxxxxxxxx>
References:
<938D7E14D9AF6B42936905D8DE7D452B59F15F@xxxxxxxxxxxxxxxxx>
Hi Tomas,
I don't have a whole lot of time to confirm your errors, but it looks like
you could get around some of your issues here by taking advantage of
log4cxx::logstream. I always do something like the following:
log4cxx::logstream oss(*sm_logger, log4cxx::Level::getDebug());
oss << "This is a number test: " << a;
oss.flush();
You could rig it up in your own macro and do things like:
MY_LOG4CXX_DEBUG( "This is a number test: " << a );
Hope this helps!
Stephen Bartnikowski
Barking Lizards Technology
www.barkinglizards.com
________________________________________
From: Tomas Andersen [mailto:tomas.andersen@xxxxxxxxxx]
Sent: Thursday, December 21, 2006 4:22 AM
To: log4cxx-user@xxxxxxxxxxxxxxxxxx
Subject: Possible error with logging a stringstream
Hi!
When using log4cxx I usually do something like this to build the log string.
std::stringstream oss;
oss << "This is my logging and the result is: ";
int i=getANumber();
if( i == 1 )
{
oss << "1";
}
else
{
oss << "something else";
}
LOG4CXX_DEBUG(logger, oss.str();
nextMethodToCall();
[This works ok.]
One time I added
oss << std::ends;
before the LOG4CXX_DEBUG call.
This log line never appeared in the log and the nextMethodToCall() method
was never called. It seemed like the
thread where this was done hanged in the LOG4CXX_DEBUG call!
Great if you could check that. I'm using the head version of LOG4CXX
downloaded the 19. december this year =)
Another thing while I'm at it:
I have used the LOG4CXX_DEBUG command with concatuating several
std::string(s) as parameters, ie:
LOG4CXX_DEBUG(logger, "This is a string: " + myFirstString + " and this is
another one: " + myOtherString );
It does only work with strings. Do you have any plans of making this
possible for other types aswell (as in log4j)..?
(I know java has the advantage of toString() and that is probably why this
doesn't work right?)
int a = 5;
LOG4CXX_DEBUG(logger, "This is a number test: " + a);
It compiled but resulted in the following logline:
.... - is a number test:
The first word was cut and the integer was never printed.
Happy Christmas from
Tomas Andersen
Consultant
www.morecom.no
Date: December 21, 2006
From: Nicolas Bastien <nibastien@xxxxxxxxxxxx>
Je serai absent(e) du 21/12/2006 au 04/01/2007.
Je répondrai à votre message dès mon retour.
----------------
L'acces immediat aux meilleurs tarifs Air France et au billet electronique sur http://www.airfrance.com
For immediate access to the best Air France fares and to electronic tickets, visit our website http://www.airfrance.com
----------------
Les donnees et renseignements contenus dans ce message sont personnels, confidentiels et secrets. Ce message est adresse a l'individu ou l'entite dont les coordonnees figurent ci-dessus. Si vous n'etes pas le bon destinataire, nous vous demandons de ne pas lire, copier, utiliser ou divulguer cette communication. Nous vous prions de notifier cette erreur a l'expediteur et d'effacer immediatement cette communication de votre systeme.
The information contained in this message is privileged, confidential, and protected from disclosure. This message is intended for the individual or entity adressed herein. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others; also please notify the sender by replying to this message, and then delete it from your system.
----------------
Pensez à l'environnement avant d'imprimer ce message.
Think of the environment before printing this mail
Date: December 21, 2006
From: "Tomas Andersen" <tomas.andersen@xxxxxxxxxx>
Date: December 20, 2006
From: "Charles Tuckey" <charles@xxxxxxxxx>
In-reply-to:
<a4ff0d310612191509y67f80f7fh891212371bc68c6@xxxxxxxxxxxxxx>
References:
<a4ff0d310612191509y67f80f7fh891212371bc68c6@xxxxxxxxxxxxxx>
Problem solved. Some of the log4cxx include files are auto generated. On the Windows platform, I was using a set of include files I had copied over from Linux. The log4cxx.h from Linux specified a UTF8 logchar, the proper one from Windows specifies a wchar logchar. I was using the Windows include files to build the log4cxx shared library, and the Linux include files to build my library. This meant anything with a LogString had a type mismatch. Thanks for listening. charlie On 12/19/06, Charles Tuckey <charles@xxxxxxxxx> wrote:
Hi,
I built the log4cxx library on WXP SP2 with no problems. But when I
try to link a very simple dll to it I get an unresolved symbol
problem. My problem is very similar to Sorin Popa (Nov 28 email). I
have some ideas on what the problem might be but I am not a very
strong C++ programmer and I have little experience on Windows as well
so I haven't been able to solve this. Details are below. Any help, or
gentle nudge in the right direction, would be greatly appreciated.
1) log4cxx build
- I'm using the HEAD from Nov. 13m 2006
- I built according to the instructions in INSTALL except:
- I added unxutils to my path so I could access the 'patch' command
- I ran setenv.cmd from Microsoft Platform SDK for Windows Server 2003 R2 dir
- my command line was 'ant build'
- I ended up with a debug lib
2) my library
- the source consists of two files: EngineAppender.h & EngineAppender.cpp
EngineAppender.h listing:
#include <log4cxx/appenderskeleton.h>
#include <log4cxx/spi/loggingevent.h>
#include <log4cxx/helpers/pool.h>
class EngineAppender : public log4cxx::AppenderSkeleton {
protected :
void append(const log4cxx::spi::LoggingEventPtr& event,
log4cxx::helpers::Pool& p);
public :
void close();
bool requiresLayout() const;
};
EngineAppender.cpp listing:
#include "EngineAppender.h"
#include "log4cxx/spi/loggingevent.h"
void EngineAppender::append(const log4cxx::spi::LoggingEventPtr& event,
log4cxx::helpers::Pool& p) {
event->getLoggerName();
}
void EngineAppender::close() { }
bool EngineAppender::requiresLayout() const {return 0;}
- before building I ran setenv.cmd to set up my environment
- then I ran
#include "EngineAppender.h"
#include "log4cxx/spi/loggingevent.h"
void EngineAppender::append(const log4cxx::spi::LoggingEventPtr&
event, log4cxx::helpers::Pool& p) {
event->getLoggerName();
}
void EngineAppender::close() { }
bool EngineAppender::requiresLayout() const {
return 0;
}
- I create the library with these two commands:
cl -DWIN32 -D_WIN32 -EHsc -Ilog4cxx/include -c EngineAppender.cpp
link -DLL EngineAppender.obj -out:test.dll log4cxxd.lib
It fails with the error:
EngineAppender.obj : error LNK2019: unresolved external symbol "public: class st
d::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >
const __thiscall log4cxx::spi::LoggingEvent::getLoggerName(void)const " (?getLog
gerName@LoggingEvent@spi@log4cxx@@QBE?BV?$basic_string@DU?$char_traits@D@std@@V?
$allocator@D@2@@std@@XZ) referenced in function "protected: virtual void __thisc
all EngineAppender::append(class log4cxx::helpers::ObjectPtrT<class log4cxx::spi
::LoggingEvent> const &,class log4cxx::helpers::Pool &)" (?append@EngineAppender
@@MAEXABV?$ObjectPtrT@VLoggingEvent@spi@log4cxx@@@helpers@log4cxx@@AAVPool@34@@Z
)
3) My troubleshooting
- In the log4cxx library the mangled name for getLoggerName is:
?getLoggerName@LoggingEvent@spi@log4cxx@@QBE?BV?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@XZ
This differs from the name the linker is looking for in the
parameterized type to basic_string. The log4cxx library has _W (wchar)
and my linker is looking for a char type (D). (Sorin's linker was
looking for an unsigned short, G).
Even though I thought it would have no effect since I am using VC 8 I
tried compiling with the -Zc:wchar_t option. No change.
So, I'm stumped. How do I make my object file compile using
basic_string<wchar>? I cannot find anything on goolge (that I can
understand) that would help me solve this.
Thanks for your help,
charlie
-- Regards, Charlie
Date: December 19, 2006
From: "Charles Tuckey" <charles@xxxxxxxxx>
Hi,
I built the log4cxx library on WXP SP2 with no problems. But when I
try to link a very simple dll to it I get an unresolved symbol
problem. My problem is very similar to Sorin Popa (Nov 28 email). I
have some ideas on what the problem might be but I am not a very
strong C++ programmer and I have little experience on Windows as well
so I haven't been able to solve this. Details are below. Any help, or
gentle nudge in the right direction, would be greatly appreciated.
1) log4cxx build
- I'm using the HEAD from Nov. 13m 2006
- I built according to the instructions in INSTALL except:
- I added unxutils to my path so I could access the 'patch' command
- I ran setenv.cmd from Microsoft Platform SDK for Windows Server 2003 R2 dir
- my command line was 'ant build'
- I ended up with a debug lib
2) my library
- the source consists of two files: EngineAppender.h & EngineAppender.cpp
EngineAppender.h listing:
#include <log4cxx/appenderskeleton.h>
#include <log4cxx/spi/loggingevent.h>
#include <log4cxx/helpers/pool.h>
class EngineAppender : public log4cxx::AppenderSkeleton {
protected :
void append(const log4cxx::spi::LoggingEventPtr& event,
log4cxx::helpers::Pool& p);
public :
void close();
bool requiresLayout() const;
};
EngineAppender.cpp listing:
#include "EngineAppender.h"
#include "log4cxx/spi/loggingevent.h"
void EngineAppender::append(const log4cxx::spi::LoggingEventPtr& event,
log4cxx::helpers::Pool& p) {
event->getLoggerName();
}
void EngineAppender::close() { }
bool EngineAppender::requiresLayout() const {return 0;}
- before building I ran setenv.cmd to set up my environment
- then I ran
#include "EngineAppender.h"
#include "log4cxx/spi/loggingevent.h"
void EngineAppender::append(const log4cxx::spi::LoggingEventPtr&
event, log4cxx::helpers::Pool& p) {
event->getLoggerName();
}
void EngineAppender::close() { }
bool EngineAppender::requiresLayout() const {
return 0;
}
- I create the library with these two commands:
cl -DWIN32 -D_WIN32 -EHsc -Ilog4cxx/include -c EngineAppender.cpp
link -DLL EngineAppender.obj -out:test.dll log4cxxd.lib
It fails with the error:
EngineAppender.obj : error LNK2019: unresolved external symbol "public: class st
d::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >
const __thiscall log4cxx::spi::LoggingEvent::getLoggerName(void)const " (?getLog
gerName@LoggingEvent@spi@log4cxx@@QBE?BV?$basic_string@DU?$char_traits@D@std@@V?
$allocator@D@2@@std@@XZ) referenced in function "protected: virtual void __thisc
all EngineAppender::append(class log4cxx::helpers::ObjectPtrT<class log4cxx::spi
::LoggingEvent> const &,class log4cxx::helpers::Pool &)" (?append@EngineAppender
@@MAEXABV?$ObjectPtrT@VLoggingEvent@spi@log4cxx@@@helpers@log4cxx@@AAVPool@34@@Z
)
3) My troubleshooting
- In the log4cxx library the mangled name for getLoggerName is:
?getLoggerName@LoggingEvent@spi@log4cxx@@QBE?BV?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@XZ
This differs from the name the linker is looking for in the
parameterized type to basic_string. The log4cxx library has _W (wchar)
and my linker is looking for a char type (D). (Sorin's linker was
looking for an unsigned short, G).
Even though I thought it would have no effect since I am using VC 8 I
tried compiling with the -Zc:wchar_t option. No change.
So, I'm stumped. How do I make my object file compile using
basic_string<wchar>? I cannot find anything on goolge (that I can
understand) that would help me solve this.
Thanks for your help,
charlie
Date: December 19, 2006
From: Curt Arnold <carnold@xxxxxxxxxx>
In-reply-to:
<9538CBC0A0444817AC431DE760324D62@taoyuxp>
References:
<9538CBC0A0444817AC431DE760324D62@taoyuxp>
On Dec 18, 2006, at 3:20 PM, Tao Yu wrote:
Hi, Does log4cxx support print out Chinese chars (GB and BIG5)? If it does, what should I do to enable it? Thanks, Tao
The subversion head provides both char* and wchar_t* versions of the logging request methods. In both cases, the arguments are converted to a single Unicode representation in the internals where char* is interpreted as being in the default character encoding of the platform. FileAppender and related appenders provide an encoding attribute that can be used to specify the target encoding for the log files. If your default character encoding for your platform is UTF-8, then you likely do not need to do anything to support Chinese or any other language. If your default encoding is not UTF-8, then you would need to use the wchar_t* versions of the logging request methods and specify an encoding that can represent your expected characters (for example, UTF-8 or UTF-16).
For more specific guidance, it would be helpful to know:
1. Your platform (Windows, Linux, Solaris, etc)
2. Your default encoding ("locale charmap" on most Unix).
3. Whether you are wanting to use the char* or wchar_t* logging methods.
4. Any specific problems that you are having.
5. What file encoding would you like to use
Date: December 18, 2006
From: "Hunger, Robert" <robert.hunger@xxxxxxxxxxxxxxxxx>
Hi all, Is there a (simple) way to dump the currently active configuration for all loggers and appenders? Preferably in a way, that it can be reused as configuration file? Thanks, Robert
Date: December 14, 2006
From: Peter Steiner <peter.steiner@xxxxxxxx>
Hello all Quite frequently I see the question popping, how you can have one log file per day, even when you use an INI file (a.k.a. properties) for the configuration. There are two roads: - use the DailyRollingFileAppender. This is documented as deprecated, but with the recent commits from Curt (486425 and earlier) this probably works out of the box (I have not tested this). - use the new style RollingFileAppender with a TimeBasedRollingPolicy. To configure the policy from properties, you need the patch (originally by Christian Steindl) from http://issues.apache.org/jira/browse/LOGCXX-102 Here is an example configuration for TimeBasedRollingPolicy and one log file per day: log4j.appender.D=org.apache.log4j.rolling.RollingFileAppender log4j.appender.D.rollingPolicy=TimeBasedRollingPolicy log4j.appender.D.rollingPolicy.FileNamePattern=%d.log Another example: if you want a new log file every hour, you can replace the FileNamePattern line with this one: log4j.appender.D.rollingPolicy.FileNamePattern=%d{yyyy-MM-dd-HH}.log There is another caveat (unrelated to properties) when using a configuration which needs to rename files (say when you use FixedWindowRollingPolicy with a MaxIndex). Whenever a rename happens, log4cxx will allocate a small amount of memory that won't be freed until the end of the application. To fix this, you need the 'mutex' patch from http://issues.apache.org/jira/browse/LOGCXX-161. HTH Peter -- _ _ Peter Steiner <peter.steiner@xxxxxxxx> / /_/ / Hug-Witschi AG <http://www.hugwi.ch/> / _ / Electronic Engineering /_/ /_/ _ _ Auriedstrasse 10 / / / / / / CH-3178 Boesingen / /_/ /_/ / Tel +41 31 740 44 44 /_ _ _ _ _/ Fax +41 31 740 44 45
Date: December 13, 2006
From: Bob Rossi <bob_rossi@xxxxxxx>
In-reply-to:
<20061213213940.GL11212@xxxxxxx>
References:
<20061212200539.GS18095@xxxxxxx> <20061213201305.GH11212@xxxxxxx> <20061213213940.GL11212@xxxxxxx>
On Wed, Dec 13, 2006 at 04:39:40PM -0500, Bob Rossi wrote:
> On Wed, Dec 13, 2006 at 03:13:05PM -0500, Bob Rossi wrote:
> > On Tue, Dec 12, 2006 at 03:05:39PM -0500, Bob Rossi wrote:
> > > Hi,
> > >
> > > OK, I'm planning on using log4cxx, along with apr. Is there anything
> > > special I should consider? Can I simply have log4cxx use the libapr that
> > > I already build?
> >
> > I got it to this point,
> >
> > loglog.cpp: In static member function `static void
> > log4cxx::helpers::LogLog::emit(const std::wstring&)':
> >
> >
> > loglog.cpp:89: error: `wcerr' is not a member of `std'
> >
> > make[1]: *** [loglog.lo] Error 1
> >
> > make[1]: Leaving directory `/home/bobbybrasko/log4cxx/logging-log4cxx/src'
> >
> > make: *** [all-recursive] Error 1
> >
> >
> > This is on windows with mingw compiler, using autotools.
>
>
> Apparently, include/log4cxx/private/log4cxx_private.h has
> #define LOG4CXX_HAS_STD_WCOUT 1
> and loglog.cpp does
> #if LOG4CXX_HAS_WCHAR_T
> void LogLog::emit(const std::wstring& msg) {
> #if LOG4CXX_HAS_STD_WCOUT
> std::wcerr << L"log4cxx: " << msg << std::endl;
> #else
> LOG4CXX_ENCODE_CHAR(encoded, msg);
> std::cerr << "log4cxx: " << encoded << std::endl;
> #endif
> }
>
> If I comment out the WCOUT macro, I get,
> loglog.cpp: In static member function `static void
> log4cxx::helpers::LogLog::emit(const std::wstring&)':
>
>
> loglog.cpp:91: error: no matching function for call to
> `log4cxx::helpers::Transcoder::encode(const std::
> basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t>
> >&, std::string&)'
> ../include/log4cxx/helpers/transcoder.h:63: note: candidates are: static
> void log4cxx::helpers::Transcod
> er::encode(const log4cxx::LogString&, std::string&)
>
> ../include/log4cxx/helpers/transcoder.h:81: note: static
> void log4cxx::helpers::Transcod
> er::encode(const log4cxx::LogString&, std::wstring&)
>
> make[1]: *** [loglog.lo] Error 1
>
> make[1]: Leaving directory `/home/bobbybrasko/log4cxx/logging-log4cxx/src'
>
> make: *** [all-recursive] Error 1
>
It's a combination of 3 defines that are confused during the build
process. That is,
LOG4CXX_HAS_WCHAR_T
LOG4CXX_HAS_STD_WCOUT
LOG4CXX_LOGCHAR_IS_UTF8
the configure script says,
checking for wchar_t... yes
checking logchar type... utf-8
For some reason WCOUT is true, but mingw complains about it. Does mingw
support this? The problem code is here,
#if LOG4CXX_HAS_WCHAR_T
void LogLog::emit(const std::wstring& msg) {
#if LOG4CXX_HAS_STD_WCOUT
std::wcerr << L"log4cxx: " << msg << std::endl;
#else
LOG4CXX_ENCODE_CHAR(encoded, msg);
std::cerr << "log4cxx: " << encoded << std::endl;
#endif
}
#endif
Since wcerr isn't available, I've changed LOG4CXX_HAS_WCHAR_T to not be
defined. This calls the LOG4CXX_ENCODE_CHAR macro now. However, the
encode function looks like,
static void encode(const LogString& src, std::string& dst);
and LogString is defined as a char because of logchar type shown in the
configure above. In logstring.h,
#if LOG4CXX_LOGCHAR_IS_UTF8
typedef char logchar;
typedef std::basic_string<logchar> LogString;
So, log4cxx attempts to pass a wstring into a LogString, but a LogString
is a really string.
Please advise on how to fix this, and I'll sumbit a patch. If I've messe
up the ./configure line, please let me know.
Thanks,
Bob Rossi
Date: December 13, 2006
From: Bob Rossi <bob_rossi@xxxxxxx>
In-reply-to:
<20061213201305.GH11212@xxxxxxx>
References:
<20061212200539.GS18095@xxxxxxx> <20061213201305.GH11212@xxxxxxx>
On Wed, Dec 13, 2006 at 03:13:05PM -0500, Bob Rossi wrote:
> On Tue, Dec 12, 2006 at 03:05:39PM -0500, Bob Rossi wrote:
> > Hi,
> >
> > OK, I'm planning on using log4cxx, along with apr. Is there anything
> > special I should consider? Can I simply have log4cxx use the libapr that
> > I already build?
>
> I got it to this point,
>
> loglog.cpp: In static member function `static void
> log4cxx::helpers::LogLog::emit(const std::wstring&)':
>
>
> loglog.cpp:89: error: `wcerr' is not a member of `std'
>
> make[1]: *** [loglog.lo] Error 1
>
> make[1]: Leaving directory `/home/bobbybrasko/log4cxx/logging-log4cxx/src'
>
> make: *** [all-recursive] Error 1
>
>
> This is on windows with mingw compiler, using autotools.
Apparently, include/log4cxx/private/log4cxx_private.h has
#define LOG4CXX_HAS_STD_WCOUT 1
and loglog.cpp does
#if LOG4CXX_HAS_WCHAR_T
void LogLog::emit(const std::wstring& msg) {
#if LOG4CXX_HAS_STD_WCOUT
std::wcerr << L"log4cxx: " << msg << std::endl;
#else
LOG4CXX_ENCODE_CHAR(encoded, msg);
std::cerr << "log4cxx: " << encoded << std::endl;
#endif
}
If I comment out the WCOUT macro, I get,
loglog.cpp: In static member function `static void
log4cxx::helpers::LogLog::emit(const std::wstring&)':
loglog.cpp:91: error: no matching function for call to
`log4cxx::helpers::Transcoder::encode(const std::
basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >&,
std::string&)'
../include/log4cxx/helpers/transcoder.h:63: note: candidates are: static void
log4cxx::helpers::Transcod
er::encode(const log4cxx::LogString&, std::string&)
../include/log4cxx/helpers/transcoder.h:81: note: static void
log4cxx::helpers::Transcod
er::encode(const log4cxx::LogString&, std::wstring&)
make[1]: *** [loglog.lo] Error 1
make[1]: Leaving directory `/home/bobbybrasko/log4cxx/logging-log4cxx/src'
make: *** [all-recursive] Error 1
Please advise,
Bob Rossi
Date: December 13, 2006
From: "Stephen Bartnikowski" <sbartnikowski@xxxxxxxxxxxxxxxxxx>
In-reply-to:
<56F397A1-DD71-422E-9F87-5103198192DF@xxxxxxxxxx>
References:
<56F397A1-DD71-422E-9F87-5103198192DF@xxxxxxxxxx>
> There are two scenarios where I have seen this type of problem (three > if you include deviations from spec in earlier gcc's): destruction of > the Level constants (Level::OFF etc) that appear at the end of src/ > level.cpp and logging taking place during the destruction of static > objects. > You might try commenting out Level::OFF et al from include/log4cxx/ > level.h and the constructors at the bottom of src/level.cpp. log4cxx > shouldn't need them since it uses the equivalent Level::getOff() et > al methods. They have been kept for compatibility with earlier > versions of log4cxx but been problematic and should likely be > removed. I can't tell from the stack trace if you are running into > this problem or something else. Hi Curt, Thanks for the idea. I gave it shot, but I think my problem is unrelated. This crash I'm getting is happening with a LoggerPtr object that I've declared as static. When the LoggerPtr object is being cleaned up on exit, the ObjectPtrT destructor is called, which ultimately calls apr_atomic_casptr that blows up. It looks like the apr method is trying to lock a mutex that's already been cleaned up. If I make the offending LoggerPtr object a class member, exit continues until the next statically-allocated LoggerPtr object. Making each LoggerPtr object a member rather than a static member is less than ideal for my application, so I'd prefer not to go that route. Is there a way to de-initialize a statically-allocated LoggerPtr before exit is called? Maybe if the static members are allocated with new memory, and then delete them before exit? Is there an easier way to get around this? Thanks! Steve
Date: December 13, 2006
From: Bob Rossi <bob_rossi@xxxxxxx>
In-reply-to:
<20061212200539.GS18095@xxxxxxx>
References:
<20061212200539.GS18095@xxxxxxx>
On Tue, Dec 12, 2006 at 03:05:39PM -0500, Bob Rossi wrote:
> Hi,
>
> OK, I'm planning on using log4cxx, along with apr. Is there anything
> special I should consider? Can I simply have log4cxx use the libapr that
> I already build?
I got it to this point,
loglog.cpp: In static member function `static void
log4cxx::helpers::LogLog::emit(const std::wstring&)':
loglog.cpp:89: error: `wcerr' is not a member of `std'
make[1]: *** [loglog.lo] Error 1
make[1]: Leaving directory `/home/bobbybrasko/log4cxx/logging-log4cxx/src'
make: *** [all-recursive] Error 1
This is on windows with mingw compiler, using autotools.
please advise,
Bob Rossi
Date: December 13, 2006
From: Renato Fernandes Cantão <cantao@xxxxxxxxxxxxxxxxxxxxx>
Hi! I'm using log4cxx from SVN revision 486683, on a x86 Gentoo Linux system. According to http://issues.apache.org/jira/browse/LOGCXX-150 logstream has a problem with classes inside a namespace with a operator<<(...), which happens to be my case. I moved all operator<<(...) definitions of stream.h and logstream.cpp inside the log4cxx namespace, which solved the problem, but other one just appeared. The code: // MyClass has a friend ostream& operator<<( ostream& os, const MyClass& m ) MyNamespace::MyClass m; log4cxx::logstream Log( some_logger, log4cxx::Level::DEBUG ); Log << m << LOG4CXX_ENDMSG; results on a compilation error with lots of basic_ostream errors. Basically the compiler can't decide what is the correct operator<<(...) it must use. The only way I have found to get rid of the problem was to define an extra operator: log4cxx::logstream& operator<<( log4cxx::logstream& os, const MyClass& m ) Everything then worked as expected, but it's a little cumbersome to define 2 operators per class (using a template on the first argument resulted on the same indecision from the compiler). Any hints about what could possibly be wrong? Thanks a lot, Cantão!
Date: December 13, 2006
From: Curt Arnold <carnold@xxxxxxxxxx>
In-reply-to:
<002301c71e44$5cd87ed0$3701a8c0@OCTOBER
>
References:
<002301c71e44$5cd87ed0$3701a8c0@OCTOBER
>
On Dec 12, 2006, at 5:22 PM, Stephen Bartnikowski wrote:
Hi,I'm having a problem on shutdown of my application, but only on Linux. I've attached the stack trace of the last thread at the bottom of this message.From what I can tell, in frame 3, apr_atomic_casptr is attempting to lock a mutex, but the mutex has already been destroyed. This consistently causes myapplication to abort. The mutex is initialized the first time APRInitializer::getInstance is called.I'm wondering if the call order could be changed somehow on destruction.However, frame 6 of my core dump is showing me that the object beingdestroyed is a static class member variable, and I don't have any controlover when those are initialized or destroyed.I think it may be related to bug 159, but that bug is reporting a seg fault, so I'm not sure if this is related. Does any one have any suggestions forworking around this? Thanks, Steve
There are two scenarios where I have seen this type of problem (three if you include deviations from spec in earlier gcc's): destruction of the Level constants (Level::OFF etc) that appear at the end of src/ level.cpp and logging taking place during the destruction of static objects.
You might try commenting out Level::OFF et al from include/log4cxx/ level.h and the constructors at the bottom of src/level.cpp. log4cxx shouldn't need them since it uses the equivalent Level::getOff() et al methods. They have been kept for compatibility with earlier versions of log4cxx but been problematic and should likely be removed. I can't tell from the stack trace if you are running into this problem or something else.
Date: December 12, 2006
From: "Stephen Bartnikowski" <sbartnikowski@xxxxxxxxxxxxxxxxxx>
Hi, I'm having a problem on shutdown of my application, but only on Linux. I've attached the stack trace of the last thread at the bottom of this message. >From what I can tell, in frame 3, apr_atomic_casptr is attempting to lock a mutex, but the mutex has already been destroyed. This consistently causes my application to abort. The mutex is initialized the first time APRInitializer::getInstance is called. I'm wondering if the call order could be changed somehow on destruction. However, frame 6 of my core dump is showing me that the object being destroyed is a static class member variable, and I don't have any control over when those are initialized or destroyed. I think it may be related to bug 159, but that bug is reporting a seg fault, so I'm not sure if this is related. Does any one have any suggestions for working around this? Thanks, Steve #0 0xffffe410 in __kernel_vsyscall () #1 0xb76fe7d0 in raise () from /lib/libc.so.6 #2 0xb76ffea3 in abort () from /lib/libc.so.6 #3 0xb7ae118e in apr_atomic_casptr () from /usr/local/lib/liblog4cxx.so #4 0xb79fc34d in log4cxx::helpers::ObjectPtrBase::exchange () from /usr/local/lib/liblog4cxx.so #5 0x0805ff67 in ~ObjectPtrT (this=0xb7b7c7e4) at /usr/local/include/log4cxx/helpers/objectptr.h:73 #6 0xb7b63ecc in __tcf_1 () at Message.cpp:14 #7 0xb7701566 in __cxa_finalize () from /lib/libc.so.6 #8 0xb7b63c63 in __do_global_dtors_aux () from /home/sbart/blt/projects/blt/server/blits/server/sdk/impl/libgsutil.so.1_5 #9 0xb7b7556c in _fini () from /home/sbart/blt/projects/blt/server/blits/server/sdk/impl/libgsutil.so.1_5 #10 0xb7f8adc5 in _dl_fini () from /lib/ld-linux.so.2 #11 0xb770126d in exit () from /lib/libc.so.6 #12 0xb76eb884 in __libc_start_main () from /lib/libc.so.6 #13 0x08056201 in _start ()
Date: December 12, 2006
From: Bob Rossi <bob_rossi@xxxxxxx>
Hi, OK, I'm planning on using log4cxx, along with apr. Is there anything special I should consider? Can I simply have log4cxx use the libapr that I already build? Thanks, Bob Rossi
Date: December 11, 2006
From: Curt Arnold <carnold@xxxxxxxxxxxxxx>
In-reply-to:
<20061211152030.GB18095@xxxxxxx>
References:
<20061211152030.GB18095@xxxxxxx>
On Dec 11, 2006, at 9:20 AM, Bob Rossi wrote:
Hi,I'm currently evaluating several logging libraries for use in a project.I've played with log4cpp, and am now looking at log4cxx. Is log4cxx mature? My general feeling from looking at the website is that theproject should not be used yet in stable software. This is because I'venoticed that the current release comes with a huge notice that itshouldn't be used. However, no other releases have been posted. Is therea reason for this? If possible, I would appreciate feedback from users/developers letting me know if they consider the current svn snapshot of log4cxx to be mature enough to be incorporated into stable software.I'm already using apr. If log4cxx is considered stable, I'd like to useit in the native mingw environment. Is this currently possible? I'm using autotools. If it's not currently possible, and log4cxx is considered mature, I could do some work to get the autotools stuffcorrect. Although, I wouldn't be interested in maintaining it long term.Thanks, Bob Rossi
The log4cxx 0.9.7 release was released before log4cxx was donated to Apache Software Foundation. There has not be a subsequent release since it has been in the ASF, due to procedural and technical issues. Most of the procedural issues have been resolved and there are a few outstanding technical issues that are listed as blocking a 0.10.0 release (http://issues.apache.org/jira/browse/LOGCXX-62). Basically all it should require is a development sprint to get the issues knocked off and I'm hoping to use some time around Christmas to give everybody something under their tree.
log4cxx is not "stable" in the sense of the API's being frozen and guaranteed binary compatibility between versions. However, many people have reported using svn snapshots in production environments. The topic comes up frequently enough that you should find discussion on it fairly easy by checking the mailing list archives, for example http://marc.theaimsgroup.com/?l=log4cxx-user&m=114546446721447&w=2.
I haven't checked MinGW for a while. We have submitted changes back to APR regarding MinGW, but I haven't attempted to build there for a while.
Date: December 11, 2006
From: "Charles Tuckey" <charles@xxxxxxxxx>
In-reply-to:
<a4ff0d310612111130n5462952fg297c995b32489f62@xxxxxxxxxxxxxx>
References:
<a4ff0d310612111128x20ee683ene26f5b069d3113fe@xxxxxxxxxxxxxx> <a4ff0d310612111130n5462952fg297c995b32489f62@xxxxxxxxxxxxxx>
On 12/11/06, Charles Tuckey <charles@xxxxxxxxx> wrote:
[This reply was received from Curt Arnold via private email.] I have not had reports of errors due to between conflicts between the APR instance used by log4cxx and APR in use by the calling application. Any specifics on compiler, platform, stack trace, failure scenario, and what made you think it was a conflict between APR versions would be appreciated. No APR resource should be exposed through log4cxx, so the calling program should be unaware that APR is being used by log4cxx internally.
I have noticed the problem on both FC5, 32 bit and FC6 64 bit systems. I no longer have access to the FC5 system (hard drive failure) but on the FC6 system I am using: gcc version 4.1.1 20061011 (Red Hat 4.1.1-30) /usr/lib64/libapr-1.so.0.2.7 /usr/lib64/libaprutil-1.so.0.2.7 log4cxx HEAD version of 061113 I didn't do anything special to build log4cxx; I just followed the instructions in INSTALL. I believe the seg fault is occurring because the pango library is accessing apr functions from the log4cxx library instead of the shared apr libraries.
You can build log4cxx to use a shared instance of APR and APR-util by specifying ant -Dapr.lib.type=shared -Daprutil.lib.type=shared Likely a way to do it on the autotools build, but don't know it offhand.
I did look at the configure script to see if there was a way to specify shared libraries but I didn't think to look at the ant scripts. I will try this.
[From Curt Arnold]
-- Regards, Charlie
Date: December 11, 2006
From: "Charles Tuckey" <charles@xxxxxxxxx>
In-reply-to:
<a4ff0d310612111128x20ee683ene26f5b069d3113fe@xxxxxxxxxxxxxx>
References:
<a4ff0d310612111128x20ee683ene26f5b069d3113fe@xxxxxxxxxxxxxx>
[This reply was received from Curt Arnold via private email.] On 12/11/06, Charles Tuckey <charles@xxxxxxxxx> wrote:
Hi,
I am using log4cxx in a program that also uses libpangoft2
(/usr/lib64/libpangoft2-1.0.so.0.1400.8) - running on Fedora Core 6.
I am building log4cxx from CVS. The build integrates functions from
apr, apr-util and expat directly into the log4cxx library. These
functions conflict with what pangoft2 is expecting and my program seg
faults. I built log4cxx without the apr functions and I don't get the
seg fault.
My question is why the apr functions are automatically built-in to
log4cxx? Shouldn't a check be made to see if they already exist as a
shared library and, if so, use the existing shared libraries instead?
--
Regards,
Charlie
I have not had reports of errors due to between conflicts between the APR instance used by log4cxx and APR in use by the calling application. Any specifics on compiler, platform, stack trace, failure scenario, and what made you think it was a conflict between APR versions would be appreciated. No APR resource should be exposed through log4cxx, so the calling program should be unaware that APR is being used by log4cxx internally. You can build log4cxx to use a shared instance of APR and APR-util by specifying ant -Dapr.lib.type=shared -Daprutil.lib.type=shared Likely a way to do it on the autotools build, but don't know it offhand. [From Curt Arnold]
Date: December 11, 2006
From: "Charles Tuckey" <charles@xxxxxxxxx>
Hi, I am using log4cxx in a program that also uses libpangoft2 (/usr/lib64/libpangoft2-1.0.so.0.1400.8) - running on Fedora Core 6. I am building log4cxx from CVS. The build integrates functions from apr, apr-util and expat directly into the log4cxx library. These functions conflict with what pangoft2 is expecting and my program seg faults. I built log4cxx without the apr functions and I don't get the seg fault. My question is why the apr functions are automatically built-in to log4cxx? Shouldn't a check be made to see if they already exist as a shared library and, if so, use the existing shared libraries instead? -- Regards, Charlie
Date: December 11, 2006
From: Bob Rossi <bob_rossi@xxxxxxx>
Hi, I'm currently evaluating several logging libraries for use in a project. I've played with log4cpp, and am now looking at log4cxx. Is log4cxx mature? My general feeling from looking at the website is that the project should not be used yet in stable software. This is because I've noticed that the current release comes with a huge notice that it shouldn't be used. However, no other releases have been posted. Is there a reason for this? If possible, I would appreciate feedback from users/developers letting me know if they consider the current svn snapshot of log4cxx to be mature enough to be incorporated into stable software. I'm already using apr. If log4cxx is considered stable, I'd like to use it in the native mingw environment. Is this currently possible? I'm using autotools. If it's not currently possible, and log4cxx is considered mature, I could do some work to get the autotools stuff correct. Although, I wouldn't be interested in maintaining it long term. Thanks, Bob Rossi
Date: December 06, 2006
From: val <yuri1000@xxxxxxx>
In-reply-to:
<25773400-8957-4EC8-98D1-D23708325E5B@xxxxxxxxxx>
References:
<6076013.post@xxxxxxxxxxxxxxx> <7680622.post@xxxxxxxxxxxxxxx> <25773400-8957-4EC8-98D1-D23708325E5B@xxxxxxxxxx>
Curt Arnold wrote:
>
> On Dec 4, 2006, at 9:37 AM, val wrote:
>
>>
>>
>> Since last time i used
>>
>> Configuration for LOG4CXX 0.9.7:
>>
>> log4j.rootLogger=DEBUG, R
>> log4j.appender.R=org.apache.log4j.DailyRollingFileAppender
>> log4j.appender.R.File=output/temp
>> log4j.appender.R.DatePattern=.%Y-%m-%d-%H-%M
>> log4j.appender.R.layout=org.apache.log4j.PatternLayout
>> log4j.appender.R.layout.ConversionPattern=%d{%Y-%m-%d %H:%M:%S,%Q}
>> [%t] %-5p
>> %.16c - %m%n
>
>>
>> it works very well. But now i use version 0.10.0
>> and this configuration doesn't work wel:
>> log4j.rootLogger=DEBUG, R
>> log4j.appender.R=org.apache.log4j.rolling.RollingFileAppender
>> log4j.appender.R.File=output/temp
>> log4j.appender.R.DatePattern=.%Y-%m-%d-%H-%M
>> log4j.appender.R.layout=org.apache.log4j.PatternLayout
>> log4j.appender.R.layout.ConversionPattern=%d{yyyy-MM-dd
>> HH:mm:ss,SSS} [%t]
>> %-5p %.16c - %m%n
>>
>> What is difference between 0.9.7 and 0.10.0 for
>> DailyRollingFileAppender
>> Configurator.
>>
>
> log4cxx 0.9.7 only supported strftime ("%Y...") type format
> specifiers which were not supported by log4j. 0.10.0 now supports
> java.util.SimpleDateFormat style format specifiers (to be compatible
> with log4j configuration files) but will try to detect strftime
> format specifiers for compatibility with log4cxx 0.9.7 configuration
> files. the 0.10.0 implementation uses apr_strftime which may behave
> differently than the native strftime (most commonly %Q is not
> supported).
>
> I would suggest changing the DatePattern to a SimpleDateTime format
> specifier and see what happens. That is:
>
> log4j.appender.R.DatePattern='.'yyyy-MM-dd_HH_mm
>
> I don't know why the period is quoted in the tests/input/rolling/
> obsoleteDRFA1.properties where I borrowed the fragment.
>
> I did modify tests/input/rolling/obsoleteDRFA1.properties in my
> working copy to use strftime style format specifiers but the test
> still passed, so I'm not sure what problem you are seeing.
>
> Your format string would not get you one file per day, but would get
> you one file per minute, but I assume that you knew that.
>
>
hi
It seems that log4j.appender.R.DatePattern='.'yyyy-MM-dd_HH_mm doesn't work
even for logging every minute.
But still log to to one file: /output/temp without div like in version
0.9.7
Maybe problem isn't here?
///MY LAST CONFIG:
log4j.rootLogger=DEBUG, R
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.Append=true
log4j.appender.R.File=output/temp
log4j.appender.R.DatePattern='.'yyyy-MM-dd_HH_mm
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss,SSS} [%t]
%-5p %.16c - %m%n
#####
--
View this message in context:
http://www.nabble.com/How-create-1-log-file-for-a-day--tf2195568.html#a7721616
Sent from the Log4cxx - Users mailing list archive at Nabble.com.
Date: December 06, 2006
From: Jing Zheng <jingzheng@xxxxxxxxx>
In-reply-to:
<7013834.post@xxxxxxxxxxxxxxx>
References:
<7013834.post@xxxxxxxxxxxxxxx>
Hi Curt, do you think this patch is good? Jing Zheng wrote: > > Hi Curt, Iwan Tomlow suggested a patch for DailyRollingFileAppender in > http://comments.gmane.org/gmane.comp.apache.logging.log4cxx.user/842 > dailyrollingfileappender.h, Ln 50: > class DailyRollingFileAppender : public log4cxx::helpers::ObjectImpl, > Appender { > DECLARE_LOG4CXX_OBJECT(DailyRollingFileAppender) > BEGIN_LOG4CXX_CAST_MAP() > LOG4CXX_CAST_ENTRY(DailyRollingFileAppender) > LOG4CXX_CAST_ENTRY(Appender) > + LOG4CXX_CAST_ENTRY(spi::OptionHandler) > END_LOG4CXX_CAST_MAP() > > I tried this patch and DailyRollingFileAppender began to work without the > error "log4cxx: No output stream or file set for the appender named ...". > Any potential problem to commit this change into svn? It has been there > for a while... > thanks. > -- View this message in context: http://www.nabble.com/a-proposed-patch-for-DailyRollingFileAppender-by-Iwan-Tomlow-tf2514825.html#a7720219 Sent from the Log4cxx - Users mailing list archive at Nabble.com.
Date: December 06, 2006
From: Curt Arnold <carnold@xxxxxxxxxx>
In-reply-to:
<7668080.post@xxxxxxxxxxxxxxx>
References:
<loom.20061202T061037-589@xxxxxxxxxxxxxx> <loom.20061202T170737-416@xxxxxxxxxxxxxx> <7668080.post@xxxxxxxxxxxxxxx>
On Dec 3, 2006, at 4:28 PM, Marc Rossi wrote:
Went ahead and added the following line to the end of the XMLSocketAppender::renderEvent() method: os1->write(output) and it is now sending out the xml event info (although it still isn'tdisplaying properly in chainsaw). Not sure why this line wasn't alreadythere (almost the same line was commented out in the original source).
Logged and resolved as http://issues.apache.org/jira/browse/ LOGCXX-164. Also logged https://issues.apache.org/jira/browse/ LOGCXX-165 as the original 0.9.7 and the current implementation could result in corrupted XML due to a mismatch of the expected UTF-8 encoding and the actual encoding, however fixing that would probably warrant a complete review of SocketAppender and XMLSocketAppender in log4cxx.
The code using the Microsoft Platform SDK macro T2A was removed during the migration to supporting both single char and wide char logging simultaneously. It just wasn't restored when things were put back together.
Date: December 05, 2006
From: Curt Arnold <carnold@xxxxxxxxxx>
In-reply-to:
<456F1235.7000605@xxxxxxxxxxxx>
References:
<456F1235.7000605@xxxxxxxxxxxx>
On Nov 30, 2006, at 11:17 AM, George Uecker wrote:
I have a custom appender that is in a separate library because it has dependencies on some 3rd-party commercial libs. When I try to configure this appender, the DOMConfigurator says it can't find the class. What do I have to do to be able to use a custom appender that does NOT reside in the log4cxx lib?TIA, George
The problem is likely due to the registration either not occurring or occurring after the configuration file is processed. You somehow need to force the appender registration to occur before the configuration file is processed. To figure out how to force the order, you would need to know how configuration is triggered (explicit call or default configuration) and when (are their logging statements in static constructors that are triggering default configuration) and to make sure that your appender containing library is loaded and its registration code called before that.
How are you forcing your appender library to be loaded? Does your custom library show up when you look at the executable with depends, ldd or equivalent? You might try adding a call to MyAppender::registerClass() to your app somewhere that will precede the configuration. Calling registerClass() repeatedly is not harmful and should not be all that expensive.
If that doesn't fix the issue, then set break points on the registration code and default configuration and check that the registration code is being executed and whether it is prior to configuration?
Date: December 05, 2006
From: Curt Arnold <carnold@xxxxxxxxxx>
In-reply-to:
<7680622.post@xxxxxxxxxxxxxxx>
References:
<6076013.post@xxxxxxxxxxxxxxx> <7680622.post@xxxxxxxxxxxxxxx>
On Dec 4, 2006, at 9:37 AM, val wrote:
Since last time i used Configuration for LOG4CXX 0.9.7: log4j.rootLogger=DEBUG, R log4j.appender.R=org.apache.log4j.DailyRollingFileAppender log4j.appender.R.File=output/temp log4j.appender.R.DatePattern=.%Y-%m-%d-%H-%M log4j.appender.R.layout=org.apache.log4j.PatternLayoutlog4j.appender.R.layout.ConversionPattern=%d{%Y-%m-%d %H:%M:%S,%Q} [%t] %-5p%.16c - %m%n it works very well. But now i use version 0.10.0 and this configuration doesn't work wel: log4j.rootLogger=DEBUG, R log4j.appender.R=org.apache.log4j.rolling.RollingFileAppender log4j.appender.R.File=output/temp log4j.appender.R.DatePattern=.%Y-%m-%d-%H-%M log4j.appender.R.layout=org.apache.log4j.PatternLayoutlog4j.appender.R.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss,SSS} [%t]%-5p %.16c - %m%nWhat is difference between 0.9.7 and 0.10.0 for DailyRollingFileAppenderConfigurator.
log4cxx 0.9.7 only supported strftime ("%Y...") type format specifiers which were not supported by log4j. 0.10.0 now supports java.util.SimpleDateFormat style format specifiers (to be compatible with log4j configuration files) but will try to detect strftime format specifiers for compatibility with log4cxx 0.9.7 configuration files. the 0.10.0 implementation uses apr_strftime which may behave differently than the native strftime (most commonly %Q is not supported).
I would suggest changing the DatePattern to a SimpleDateTime format specifier and see what happens. That is:
log4j.appender.R.DatePattern='.'yyyy-MM-dd_HH_mmI don't know why the period is quoted in the tests/input/rolling/ obsoleteDRFA1.properties where I borrowed the fragment.
I did modify tests/input/rolling/obsoleteDRFA1.properties in my working copy to use strftime style format specifiers but the test still passed, so I'm not sure what problem you are seeing.