Re: Create a new log file at every start of the programm
> Hi Anand, > > thanks for your reply. But I think it should be a normal function for a > logging library to create logfiles for each start of an application. The > renaming was only an example. Of course it would also be okay using the > rollOver Function of log4cxx. > > But logging seems either size or time related. > > Hm, if there's no alternative I've got to do it my own. > > Best regards, > Alex > > Hi Alex, Did you find solution to your problem? Can you please share it? Regards, Anand.
Re: Log messages in memory
Did you take a look at "ImmediateFlush" option? Is that what you want? On 7/24/07, Andrew La Motte-Mitchell <[EMAIL PROTECTED]> wrote: I didn't see any response to this question... was the discussion taken off-line? If anyone knows anything about this caching feature I'd really be interested to know. -Andrew >From: "Boer den, Johan J (NSC)" <[EMAIL PROTECTED]> >Reply-To: "Log4CXX User" >To: >Subject: Log messages in memory >Date: Fri, 20 Jul 2007 09:19:00 +0200 > >Hi, > >I want to log messages in memory and later I want when a certain >condition occurs flush memory to a logfile. Does anyone know if there is >a memoryappender available. > >Johan > >-- >Deze e-mail, inclusief eventuele bijlage(n), is uitsluitend bestemd voor >gebruik door de >geadresseerde(n). Indien u dit bericht abusievelijk heeft ontvangen, mag de >informatie >daarvan niet worden gebruikt of openbaar gemaakt, noch aan derden worden >verstrekt. Wij verzoeken u om in dat geval direct contact op te nemen met >de >afzender en de e-mail te vernietigen. > >This e-mail, including any appendix or appendices, is intended solely for >use by the >addressee(s). If you have received this message in error, the information >it contains >may not be used or disclosed, nor may it be revealed to third parties. In >that case, >please contact the sender immediately and destroy the e-mail. _ http://newlivehotmail.com
Re: AIX segfault
On 6/29/07, Marshall Powers <[EMAIL PROTECTED]> wrote:
I'm getting a segfault on 64-bit AIX 5.3. I'm using static libraries of
log4cxx, apr, and aprutil. Here is a test program and Makefile I am using
that causes the crash:
_*main.cpp*_
#include
#include
#include
using namespace log4cxx;
using namespace log4cxx::rolling;
int main(int argc, char * argv[]) {
LoggerPtr root = Logger::getRootLogger();
BasicConfigurator::configure();
RollingFileAppenderPtr rfa;
if(argc > 1) {
rfa = new RollingFileAppender();
}
LOG4CXX_DEBUG(root, "HELLO WORLD!");
return 0;
}
_*Makefile*_
LOG4CXX=/path_to_log4cxx
INCLUDE=-I$(LOG4CXX)/include
LIBDIR=-L$(LOG4CXX)/lib
LIBS=-llog4cxxd -lapr-1d -laprutil-1d -liconv -pthread
FLAGS=-g -maix64
BIN=testptr
$(BIN): main.cpp
g++ $(FLAGS) $(INCLUDE) $(LIBDIR) $(LIBS) main.cpp -o $(BIN)
clean:
rm -f core $(BIN)
run:
./$(BIN)
all: main.cpp
Basically, it does some very basic logging. If you give no command-line
args, the program runs just fine, no trouble. If you pass any arguments, it
will instantiate a RollingFileAppender before doing the logging. However, if
you do create that object, you get a segfault. GDB shows this:
(gdb) set args 1
(gdb) run
Starting program: /home/mpowers/log4cxx_smart/testptr 1
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1]
0x090523ec in malloc_y () from /usr/lib/libc.a(shr_64.o)
(gdb) bt
#0 0x090523ec in malloc_y () from /usr/lib/libc.a(shr_64.o)
#1 0x0904f478 in malloc_common_52_36 () from
/usr/lib/libc.a(shr_64.o)
#2 0x093d499c in iconv_open (t_name=0x1002a3808 "UTF-8",
f_name=0x9001000a0001108 "ISO8859-1")
at ../../../../../../../src/bos/usr/ccs/lib/libiconv/iconv.c:431
#3 0x00010005386c in apr_xlate_open (convset=0x1100cec58,
topage=0x1002a3808 "UTF-8", frompage=0x9001000a0001108 "ISO8859-1",
pool=0x1100cec98)
at /home.local/mpowers/new_log4cxx/lib/apr-util-1.2.7
/xlate/xlate.c:251
#4 0x00010004f93c in
log4cxx::helpers::APRCharsetDecoder::APRCharsetDecoder(char const*)
(this=0x1100cec30, frompage=0x1 "")
at /home.local/mpowers/new_log4cxx/src/charsetdecoder.cpp:64
#5 0x000100050168 in
log4cxx::helpers::CharsetDecoder::createDefaultDecoder() () at
/home.local/mpowers/new_log4cxx/src/charsetdecoder.cpp:460
#6 0x000100050260 in
log4cxx::helpers::CharsetDecoder::getDefaultDecoder() () at
/home.local/mpowers/new_log4cxx/src/charsetdecoder.cpp:467
#7 0x00010004d150 in log4cxx::helpers::Transcoder::decode(char
const*, unsigned long, std::string&) (src=0x1100ccbe8 "HELLO WORLD!",
len=12,
[EMAIL PROTECTED]) at
/home.local/mpowers/new_log4cxx/src/transcoder.cpp:57
#8 0x0001000bf6c4 in void
log4cxx::helpers::Transcoder::decode(std::string const&,
std::string&) ([EMAIL PROTECTED],
[EMAIL PROTECTED]) at
/home.local/mpowers/new_log4cxx/include/log4cxx/helpers/transcoder.h:49
#9 0x0001000c5ac8 in
log4cxx::Logger::forcedLog(log4cxx::helpers::ObjectPtrT
const&, std::string const&, log4cxx::spi::LocationInfo const&)
(this=0x1100c4a70, [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]) at
/home.local/mpowers/new_log4cxx/src/logger.cpp:109
#10 0x00010ad8 in main (argc=2, argv=0xab8) at
main.cpp:17
This crash seems to occur if I instantiate any object and give it to a
smart pointer (*Ptr) variable. It's not limited to RollingFileAppender. Any
ideas for resolving this problem? Can anyone else reproduce this on their
own AIXes? I've tested this code on other OSes such as HPUX, windows,
solaris, and linux without trouble.
Thanks for the help,
Marshall
Hi,
Looks like you are facing similar problem that I had faced few days back.
But I was on SPARC Solaris. I'm producing the problem statement and its
resolution below.
On Jun 19, 2007, at 7:58 AM, Anand Sherkhane wrote:
> Hi,
>
> I'm seeing a crash in CharsetDecoder when I execute following
> statement in a test program:
> Logger::getLogger("test");
>
> Complete stack trace is as follows:
>
> ff01e42c _lwp_kill (6, 0, ffbff178, ff088f18, 1, ffbff1e4) + 8
> fefb5c60 abort(ff0e1afc, 1bf, ff0ad104, ff088238, 1, ffbfef0d)
> + 100
> ff0e1ac4 _ZN10__cxxabiv111__terminateEPFvvE (fefb5b60, ffbfeba0,
> 474e5543, 432b2b00, 0, ff1099c8) + 4
> ff0e1afc _ZSt9terminatev (0, fefb5b60, ff0e1ae0, ff1099cc,
> 474e5543, 432b2b00) + 1c
> ff0e1c6c __cxa_throw (2d850, ff32cc88, ff2a4fc4, 0, 0, 2024) + 8c
> ff2a7dac _ZN7log4cxx7helpers17APRCharsetDecoderC1EPKc (23548, 1,
> 2d868, 23218, 1, ffbff43c) + 110
> ff220e4c
> _ZN7log4cxx7helpers14CharsetDecoder20createDefaultDecoderEv
> (ff292f10, 142, ff2153c8, ff199f4c, 1
Re: log4cxx v0.10.0 crash in CharsetDecoder
On 6/19/07, Curt Arnold <[EMAIL PROTECTED]> wrote:
On Jun 19, 2007, at 7:58 AM, Anand Sherkhane wrote:
> Hi,
>
> I'm seeing a crash in CharsetDecoder when I execute following
> statement in a test program:
> Logger::getLogger("test");
>
> Complete stack trace is as follows:
>
> ff01e42c _lwp_kill (6, 0, ffbff178, ff088f18, 1, ffbff1e4) + 8
> fefb5c60 abort(ff0e1afc, 1bf, ff0ad104, ff088238, 1, ffbfef0d)
> + 100
> ff0e1ac4 _ZN10__cxxabiv111__terminateEPFvvE (fefb5b60, ffbfeba0,
> 474e5543, 432b2b00, 0, ff1099c8) + 4
> ff0e1afc _ZSt9terminatev (0, fefb5b60, ff0e1ae0, ff1099cc,
> 474e5543, 432b2b00) + 1c
> ff0e1c6c __cxa_throw (2d850, ff32cc88, ff2a4fc4, 0, 0, 2024) + 8c
> ff2a7dac _ZN7log4cxx7helpers17APRCharsetDecoderC1EPKc (23548, 1,
> 2d868, 23218, 1, ffbff43c) + 110
> ff220e4c
> _ZN7log4cxx7helpers14CharsetDecoder20createDefaultDecoderEv
> (ff292f10, 142, ff2153c8, ff199f4c, 1, ffbff4bc) + 10
> ff220e74 _ZN7log4cxx7helpers14CharsetDecoder17getDefaultDecoderEv
> (ff33db58, 46, ff3840a8, ff19575c, 2, ff33db58) + 4
> ff292f10 _ZN7log4cxx7helpers10Transcoder6decodeEPKcjRSs (10f78, 4,
> ffbff548, ff33db50, 81010100, ff) + f8
> ff2552f0 _ZN7log4cxx6Logger9getLoggerEPKc (10f78, ff00, 3,
> ffbff5d8, ff148484, 23528) + 48
>
>
> I'm on a Solaris box, details:
> bash-2.05$ uname -a
> SunOS 5.9 Generic_112233-07 sun4u sparc SUNW,Ultra-5_10
>
>
> I read following suggestion somewhere on the web:
> change implmentation of CharsetDecoder::getDefaultDecoder() to replace
>
>
> static CharsetDecoderPtr decoder(createDefaultDecoder());
> return decoder;
>
>
> with
>
> return createDefaultDecoder();
>
> I tried, but I still the crash and the same stack trace.
>
> Any pointers? I'm in urgent need.
>
> Thanks and Regards,
> Anand.
>
Your stack trace is likely due to apr_xlate_open returning null in
APRCharsetDecoder::APRCharsetDecoder which should throws an
IllegalArgumentException which isn't handled well. It would be
interesting if you could debug that routine and see what happens
after the initial failure around line 61. The code that checks for
"646" was specifically added to avoid the problem for Solaris.
Possible resolutions:
Ensure that setlocale(LC_ALL, "") or setlocale(LC_CTYPE, "") is
called before any call to Logger::getLogger() to initialize the
locale based on the current state of environment variables. It can't
be done within log4cxx since that is a pretty significant side
effect, see https://issues.apache.org/jira/browse/LOGCXX-167
Attempt "make check" with apr-util. If that fails, see if a later
version of apr-util fixes the problem. Upgrade log4cxx to use that
later version of apr_util.
Set LOG4CXX_LOCALE_ENCODING_UTF8, LOG4CXX_LOCALE_ENCODING_ISO_8859_1
or LOG4CXX_LOCALE_ENCODING_US_ASCII to bypass use of APR decoding.
I made changes as suggested by you(setlocale, apr-util) but I was still
seeing the crash. So I changed CharsetDecoder::createDefaultDecoder() and
CharsetEncoder::createDefaultEncoder() to *always* return
UTF8Charset(De|En)coder.
In my case, since UTF8 support was sufficient, I could make this change.
Re: Crash in log4cxx v0.10.0 - forward_iterator_tag
Hi,
Yes, it is possible that 'plainMsg' was NULL.
I checked this behavior in a test program(passed NULL to LogRawMesg) and I
see similar crash.
Thanks for pointing it out.
Regards,
Anand.
On 6/23/07, Curt Arnold <[EMAIL PROTECTED]> wrote:
On Jun 22, 2007, at 12:34 AM, Anand Sherkhane wrote:
Right. So here I produce some more details.
Stack trace with some more info:
fee20218 _lwp_kill (6, 0, fa77a410, fee88ef8, 1, fa77a47c) + 8
fedb6e98 abort (feee1afc, 1bf, feead104, fee88248, 1, fa77a1a5) + 100
feee1ac4 _ZN10__cxxabiv111__terminateEPFvvE (7178ac, fa779e38, 474e5543,
432b2b00, 0, fef099c8) + 4
feee1afc _ZSt9terminatev (0, 7178ac, feee1ae0, fef099cc, 474e5543,
432b2b00) + 1c
feee1c6c __cxa_throw (fa0748, fef05614, feed65c4, 0, 1, 34c) + 8c
feeba748 _ZSt19__throw_logic_errorPKc (feee3f98, 1, fa0760, 19089c0,
bd0368, bd0370) + 6c
feedb754 _ZNSs12_S_constructIPKcEEPcT_S3_RKSaIcESt20forward_iterator_tag
(0, , fa77a7a8, fa77a6f7, 2710, f71bd080) + 5c
feed8a44 _ZNSsC1EPKcRKSaIcE (fa77a7a0, 0, fa77a7a8, 800, fa77a3a0,
fa77a7a8) +
24
fe3a9430 _ZN9ApacheLog10LogRawMesgEiPKc (b641c0, 64, 0, 1bc37f8, fd96eea0,
8000) + 644
f16c8d68 ObAnPluginFn (92bfb8, 13153d0, f41818, fa77ad1c, 7567696e, 9000)
+ 1c3c
ApacheLog is a wrapper class and LogRawMesg is a method of that class.
Implementation:
void ApacheLog::LogRawMesg(int level, const char* plainMsg)
{
switch(level) {
case LOGFATAL: LOG4CXX_FATAL(logger, plainMsg ); break;
case LOGINFO: LOG4CXX_INFO(logger, plainMsg ); break;
case LOGWARN: LOG4CXX_WARN(logger, plainMsg ); break;
case LOGERROR: LOG4CXX_ERROR(logger, plainMsg ); break;
case LOGDEBUG: LOG4CXX_DEBUG(logger, plainMsg ); break;
}
}
ApacheLog::logger is a member variable that is initialized in constructor
of ApacheLog using Logger::getLogger()
ApacheLog::LogRawMesg() is called from a shared object.
BTW: I checked if length message size was an issue and it doesn't look
like it is.
Environment details:
OS: Solaris 9(SPARC)
Compiler: g++ 3.3.2
log4cxx v0.10.0
Regards,
Anand.
Any chance that plainMsg is NULL? The LOG4CXX_ macros will eventually
result in a call to
void Logger::forcedLog(const LevelPtr& level, const std::string&
message,
const log4cxx::spi::LocationInfo& location);
which will result in the transparent construction and destruction of a
std::string to contain the message. The std::string constructor would
likely not like a NULL argument and could die with a stack trace something
like you are seeing.
Re: Crash in log4cxx v0.10.0 - forward_iterator_tag
Right. So here I produce some more details.
Stack trace with some more info:
fee20218 _lwp_kill (6, 0, fa77a410, fee88ef8, 1, fa77a47c) + 8
fedb6e98 abort (feee1afc, 1bf, feead104, fee88248, 1, fa77a1a5) + 100
feee1ac4 _ZN10__cxxabiv111__terminateEPFvvE (7178ac, fa779e38, 474e5543,
432b2b00, 0, fef099c8) + 4
feee1afc _ZSt9terminatev (0, 7178ac, feee1ae0, fef099cc, 474e5543, 432b2b00)
+ 1c
feee1c6c __cxa_throw (fa0748, fef05614, feed65c4, 0, 1, 34c) + 8c
feeba748 _ZSt19__throw_logic_errorPKc (feee3f98, 1, fa0760, 19089c0, bd0368,
bd0370) + 6c
feedb754 _ZNSs12_S_constructIPKcEEPcT_S3_RKSaIcESt20forward_iterator_tag (0,
, fa77a7a8, fa77a6f7, 2710, f71bd080) + 5c
feed8a44 _ZNSsC1EPKcRKSaIcE (fa77a7a0, 0, fa77a7a8, 800, fa77a3a0, fa77a7a8)
+
24
fe3a9430 _ZN9ApacheLog10LogRawMesgEiPKc (b641c0, 64, 0, 1bc37f8, fd96eea0,
8000) + 644
f16c8d68 ObAnPluginFn (92bfb8, 13153d0, f41818, fa77ad1c, 7567696e, 9000) +
1c3c
ApacheLog is a wrapper class and LogRawMesg is a method of that class.
Implementation:
void ApacheLog::LogRawMesg(int level, const char* plainMsg)
{
switch(level) {
case LOGFATAL: LOG4CXX_FATAL(logger, plainMsg ); break;
case LOGINFO: LOG4CXX_INFO(logger, plainMsg ); break;
case LOGWARN: LOG4CXX_WARN(logger, plainMsg ); break;
case LOGERROR: LOG4CXX_ERROR(logger, plainMsg ); break;
case LOGDEBUG: LOG4CXX_DEBUG(logger, plainMsg ); break;
}
}
ApacheLog::logger is a member variable that is initialized in constructor of
ApacheLog using Logger::getLogger()
ApacheLog::LogRawMesg() is called from a shared object.
BTW: I checked if length message size was an issue and it doesn't look like
it is.
Environment details:
OS: Solaris 9(SPARC)
Compiler: g++ 3.3.2
log4cxx v0.10.0
Regards,
Anand.
On 6/21/07, Curt Arnold <[EMAIL PROTECTED]> wrote:
On Jun 21, 2007, at 12:38 AM, Anand Sherkhane wrote:
Hi,
Any updates?
Regards,
Anand.
On 6/20/07, Anand Sherkhane <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'm seeing a crash in my app that uses log4cxx v0.10.0. Relevant stack
> trace is produced below:
>
> fee20218 _lwp_kill (6, 0, fa77a410, fee88ef8, 1, fa77a47c) + 8
> fedb6e98 abort (feee1afc, 1bf, feead104, fee88248, 1, fa77a1a5) + 100
> feee1ac4 _ZN10__cxxabiv111__terminateEPFvvE (7178ac, fa779e38, 474e5543,
> 432b2b00, 0, fef099c8) + 4
> feee1afc _ZSt9terminatev (0, 7178ac, feee1ae0, fef099cc, 474e5543,
> 432b2b00) + 1c
> feee1c6c __cxa_throw (fa0748, fef05614, feed65c4, 0, 1, 34c) + 8c
> feeba748 _ZSt19__throw_logic_errorPKc (feee3f98, 1, fa0760, 19089c0,
> bd0368, bd0370) + 6c
> feedb754 _ZNSs12_S_constructIPKcEEPcT_S3_RKSaIcESt20forward_iterator_tag
> (0, , fa77a7a8, fa77a6f7, 2710, f71bd080) + 5c
> feed8a44 _ZNSsC1EPKcRKSaIcE (fa77a7a0, 0, fa77a7a8, 800, fa77a3a0,
> fa77a7a8) + 24
>
>
> Any idea where that points to?
>
> Is it happening because the message being passed to the logger is more
> than it can handle?
>
> By the way: What is the maximum size of message that log4cxx v0.10.0 can
> handle?
>
> Regards,
> Anand.
>
>
Isn't obvious that the stack trace is log4cxx related. Was next line
snipped of the stack trace an identifiable line in your code that was making
a call to log4cxx?
Knowing platform, compiler, et al would be helpful. But without either a
stack trace that clearly identifies a location in log4cxx or a test, there
is not enough to go on.
I don't believe that log4cxx imposes its own limit of message size, so you
are probably limited to available memory or the max size of
std::basic_string.
Crash in log4cxx v0.10.0 - forward_iterator_tag
Hi, Any updates? Regards, Anand. On 6/20/07, Anand Sherkhane <[EMAIL PROTECTED]> wrote: Hi, I'm seeing a crash in my app that uses log4cxx v0.10.0. Relevant stack trace is produced below: fee20218 _lwp_kill (6, 0, fa77a410, fee88ef8, 1, fa77a47c) + 8 fedb6e98 abort (feee1afc, 1bf, feead104, fee88248, 1, fa77a1a5) + 100 feee1ac4 _ZN10__cxxabiv111__terminateEPFvvE (7178ac, fa779e38, 474e5543, 432b2b00, 0, fef099c8) + 4 feee1afc _ZSt9terminatev (0, 7178ac, feee1ae0, fef099cc, 474e5543, 432b2b00) + 1c feee1c6c __cxa_throw (fa0748, fef05614, feed65c4, 0, 1, 34c) + 8c feeba748 _ZSt19__throw_logic_errorPKc (feee3f98, 1, fa0760, 19089c0, bd0368, bd0370) + 6c feedb754 _ZNSs12_S_constructIPKcEEPcT_S3_RKSaIcESt20forward_iterator_tag (0, , fa77a7a8, fa77a6f7, 2710, f71bd080) + 5c feed8a44 _ZNSsC1EPKcRKSaIcE (fa77a7a0, 0, fa77a7a8, 800, fa77a3a0, fa77a7a8) + 24 Any idea where that points to? Is it happening because the message being passed to the logger is more than it can handle? By the way: What is the maximum size of message that log4cxx v0.10.0 can handle? Regards, Anand.
Crash in log4cxx v0.10.0
Hi, I'm seeing a crash in my app that uses log4cxx v0.10.0. Relevant stack trace is produced below: fee20218 _lwp_kill (6, 0, fa77a410, fee88ef8, 1, fa77a47c) + 8 fedb6e98 abort (feee1afc, 1bf, feead104, fee88248, 1, fa77a1a5) + 100 feee1ac4 _ZN10__cxxabiv111__terminateEPFvvE (7178ac, fa779e38, 474e5543, 432b2b00, 0, fef099c8) + 4 feee1afc _ZSt9terminatev (0, 7178ac, feee1ae0, fef099cc, 474e5543, 432b2b00) + 1c feee1c6c __cxa_throw (fa0748, fef05614, feed65c4, 0, 1, 34c) + 8c feeba748 _ZSt19__throw_logic_errorPKc (feee3f98, 1, fa0760, 19089c0, bd0368, bd0370) + 6c feedb754 _ZNSs12_S_constructIPKcEEPcT_S3_RKSaIcESt20forward_iterator_tag (0, , fa77a7a8, fa77a6f7, 2710, f71bd080) + 5c feed8a44 _ZNSsC1EPKcRKSaIcE (fa77a7a0, 0, fa77a7a8, 800, fa77a3a0, fa77a7a8) + 24 Any idea where that points to? Is it happening because the message being passed to the logger is more than it can handle? By the way: What is the maximum size of message that log4cxx v0.10.0 can handle? Regards, Anand.
log4cxx v0.10.0 crash in CharsetDecoder
Hi,
I'm seeing a crash in CharsetDecoder when I execute following statement in a
test program:
Logger::getLogger("test");
Complete stack trace is as follows:
ff01e42c _lwp_kill (6, 0, ffbff178, ff088f18, 1, ffbff1e4) + 8
fefb5c60 abort(ff0e1afc, 1bf, ff0ad104, ff088238, 1, ffbfef0d) + 100
ff0e1ac4 _ZN10__cxxabiv111__terminateEPFvvE (fefb5b60, ffbfeba0, 474e5543,
432b2b00, 0, ff1099c8) + 4
ff0e1afc _ZSt9terminatev (0, fefb5b60, ff0e1ae0, ff1099cc, 474e5543,
432b2b00) + 1c
ff0e1c6c __cxa_throw (2d850, ff32cc88, ff2a4fc4, 0, 0, 2024) + 8c
ff2a7dac _ZN7log4cxx7helpers17APRCharsetDecoderC1EPKc (23548, 1, 2d868,
23218, 1, ffbff43c) + 110
ff220e4c _ZN7log4cxx7helpers14CharsetDecoder20createDefaultDecoderEv
(ff292f10, 142, ff2153c8, ff199f4c, 1, ffbff4bc) + 10
ff220e74 _ZN7log4cxx7helpers14CharsetDecoder17getDefaultDecoderEv (ff33db58,
46, ff3840a8, ff19575c, 2, ff33db58) + 4
ff292f10 _ZN7log4cxx7helpers10Transcoder6decodeEPKcjRSs (10f78, 4, ffbff548,
ff33db50, 81010100, ff) + f8
ff2552f0 _ZN7log4cxx6Logger9getLoggerEPKc (10f78, ff00, 3, ffbff5d8,
ff148484, 23528) + 48
I'm on a Solaris box, details:
bash-2.05$ uname -a
SunOS 5.9 Generic_112233-07 sun4u sparc SUNW,Ultra-5_10
I think log4cxx is not reaching at a point where it reads the config file
but I produce it here anyways:
log4j.rootLogger=root, TEST_EVEN_LOGGER
log4j.appender.TEST_EVEN_LOGGER=org.apache.log4j.RollingFileAppender
log4j.appender.TEST_EVEN_LOGGER.Threshold=debug
log4j.appender.TEST_EVEN_LOGGER.File=mylog.log
log4j.appender.TEST_EVEN_LOGGER.layout=org.apache.log4j.PatternLayout
log4j.appender.TEST_EVEN_LOGGER.layout.ConversionPattern=%d{%d %b %Y
%H:%M:%S} %p %t %c - %m%n
log4j.appender.TEST_EVEN_LOGGER.ImmediateFlush=true
log4j.appender.TEST_EVEN_LOGGER.Append=true
log4j.appender.TEST_EVEN_LOGGER.MaxBackupIndex=5
log4j.appender.TEST_EVEN_LOGGER.MaxFileSize=512KB
I read following suggestion somewhere on the web:
change implmentation of CharsetDecoder::getDefaultDecoder() to replace
static CharsetDecoderPtr decoder(createDefaultDecoder());
return decoder;
with
return createDefaultDecoder();
I tried, but I still the crash and the same stack trace.
Any pointers? I'm in urgent need.
Thanks and Regards,
Anand.
Need help regarding a message printed from log4cxx
Hi,
I'm seeing this message printed on console: "log4cxx: Large window sizes are
not allowed"
Any idea why this is happening?
My conf file looks like this:
log4j.rootLogger=DEBUG, abc
log4j.appender.abc=org.apache.log4j.RollingFileAppender
log4j.appender.abc.Threshold=DEBUG
log4j.appender.abc.File=../../../logs/auth_plugins.log
log4j.appender.abc.layout=org.apache.log4j.PatternLayout
log4j.appender.abc.layout.ConversionPattern=%d{ISO8601} %d{%Z} %-20c [%-6p]
- %m%n
log4j.appender.abc.ImmediateFlush=true
log4j.appender.abc.Append=true
log4j.appender.abc.MaxBackupIndex=5
log4j.appender.abc.MaxFileSize=1024KB
log4j.logger.xyz=INHERIT, abc
log4j.additivity.xyz=false
Regards,
Anand.
Re: Official word on next release of log4cxx
Hi, I'm terribly sorry for my incomplete previous mail(my browser has mapped few keys and it was sent accidentally) Here it is again. I was using log4cxx v0.9.7 and during trial runs, it started crashing(I think the reason was as mentioned in http://issues.apache.org/jira/browse/LOGCXX-4). Our customer got skeptical(obviously) when he read following statement at http://logging.apache.org/log4cxx: "At this point, log4cxx-0.9.7 is substantially out of date, has known serious deficiencies that have been resolved in the CVS, and should be avoided for new code" He even suggested to switch to another logging framework. We convinced them that we can use a newer version of log4cxx and everything will work fine. I switched to log4cxx v0.10.0 and its working fine. However, there is no official word on this release. How do I justify to our customers the use of this log4cxx version. Is there any tentative date for official new release. Even a clarification on this thread from log4cxx team that log4cxx v0.10.0 is stable enough for use in production systems will be sufficient for me for time being(until Apache makes it official). Regards, Anand. P.S. I'm sorry if this mail does not belong to this mailing list. Please suggest me an appropriate place to post this query. On 3/29/07, Anand Sherkhane <[EMAIL PROTECTED]> wrote: Hi, I was using log4cxx 0.9.7 and during trial runs, it started crashing. Our customer got paranoid when he read following statement at http://logging.apache.org/log4cxx : Regards, Anand.
Official word on next release of log4cxx
Hi, I was using log4cxx 0.9.7 and during trial runs, it started crashing. Our customer got paranoid when he read following statement at http://logging.apache.org/log4cxx: Regards, Anand.
Re: Create a new log file at every start of the programm
Hi, I do not know if log4cxx supports this out-of-the-box but for your application to do it should be a simple task, I guess. Upon exit OR start, the application checks if their exists a log file and renames it(with current timestamp, say), if it is. Regards, Anand. On 3/27/07, Alexander Baur <[EMAIL PROTECTED]> wrote: Hi, I'm using log4cxx on a windows machine. Everything works fine up to now. But I've got a problem: Is there any possibility to create a new log file every time i start my program? So I don't want to base file rolling on the file size but on the start of my application. For example I start my program for the first time and this creates the log file "logfile.log". Now when I close the application and restart it, the old file should be renamed to "logfile_1.log" and the new one to "logfile.log". With the RollingFileAppender I can only roll over the old files when a file gets bigger than the MaximumFileSize and with the DailyRollingFileAppender it creates, depending on the configuration, a new log file every minute/hour/.. I hope anyone can help me. Regards Alex Baur
log4cxx build - necessary packages
Hi, I'm building log4cxx using autogen, confgure, and make. It requires apr and apr-util and cpp-unit amongst others. For that, I first build apr and apr-util. I don't build cpp-unit because that is optional. Then I provide path to these packages when installing log4cxx. I wish to know what all packages are necessary to build log4cxx because it shows a dependency on sqlite3 and iconv. Has it got something to do with the way apr or apr-util is built? Thanks, Anand.
