We use a RollingFileAppender defined as follows:

   <appender name="FILE" class="org.apache.log4j.RollingFileAppender">

       <param name="maxFileSize" value="200MB" />

       <param name="maxBackupIndex" value="20" />

       <param name="File" value="${LOGNAME}" />

       <param name="Append" value="false"/>

       <layout class="org.apache.log4j.PatternLayout">

           <param name="ConversionPattern"

               value="%d{MM-dd HH:mm:ss.SSS} %5p %c{1} - %m%n" />

       </layout>

   </appender>

It works fine, except that the maxBackupIndex appears to top out at 13, even though we have 20 specified. Are we doing something wrong or is 13 a hard coded maximum for this field?

Hello *,

I ma trying to build log4cxx as static library using MS Visual Studio 2003, but it doesn’t work. I have opened the project log4cxx.dsw of the log4cxx package, converted it to a MS Visual Studio 2003 project, set the project “log4cxx” as start-up project and changed two properties:

- build “static library” not “dynamic library”

-  and the pre-processor definition “LOG4CXX” to “LOG4CXX_STATIC”

When linking during the build process I get 544 warnings like the followings:

apr-1.lib(dir.obj) : warning LNK4006: _apr_os_dir_put <at> 12 already defined in aprutil-1.lib(dir.obj); second definition ignored

apr-1.lib(fileacc.obj) : warning LNK4006: _apr_file_name_get <at> 8 already defined in aprutil-1.lib(fileacc.obj); second definition ignored

Linking my own test project with the build static library results in the following errors:

log4cxx.lib(start.obj) : error LNK2019: unresolved external symbol __imp__WSACleanup <at> 0 referenced in function _apr_initialize <at> 0

log4cxx.lib(start.obj) : error LNK2019: unresolved external symbol __imp__WSAStartup <at> 8 referenced in function _apr_initialize <at> 0

log4cxx.lib(apr_snprintf.obj) : error LNK2019: unresolved external symbol __imp__ntohl <at> 4 referenced in function _conv_in_addr

log4cxx.lib(sockaddr.obj) : error LNK2001: unresolved external symbol __imp__ntohl <at> 4

log4cxx.lib(sockaddr.obj) : error LNK2019: unresolved external symbol __imp__htons <at> 4 referenced in function _apr_sockaddr_vars_set

…

What have I to do to get the static library running? Please help.

Thanks

Markus

merc,

Thank you for the examples.  I originally used the properties format because all the examples I saw were in that format.  This will make it much easier to switch to the xml format.

Why don’t you add this to the log4cxx wiki?

http://wiki.apache.org/logging-log4cxx/

-David

Hi Guys, when I first started using log4cxx about a year ago I was stun by its unavailable and limited sample usage, had to filter through the log4j documentations and test and trial to find out the proper behavior. (I'm a copy&paste-first-ask-question-later person ;) .

I've put up a sample usage with a sample XML configuration file that demonstrate the following appender at:

http://www.dreamcubes.com/blog/?itemid=59

   1. org.apache.log4j.ConsoleAppender

   2. org.apache.log4j.FileAppender

   3. org.apache.log4j.rolling.RollingFileAppender

   4. org.apache.log4j.RollingFileAppender

   5. org.apache.log4j.net.SMTPAppender

   6. org.apache.log4j.jdbc.JDBCAppender

   7. org.apache.log4j.net.XMLSocketAppender

Some people may prefer BasicConfigurator format, but I just think the DOMConfigurator format makes more sense to me : )

And of course, the credit are still to those who actually contribute to the log4cxx project, (I'm a copy&paste-first-ask-question-later kind of person remembered? ;) .

Best,

merc

Hi,

I am not very familiar with APR and APR-utils. I ran configure, make, and make install on apr fine, but when I try to make/make install apr-utils, it can’t find the file build/rules.mk

Specified in the generated Makefile. Can anyone tell me what I’m doing wrong or give a good pointer for a newbie? Thanks!

--

David Tran

Yahoo! Technical Intern

Does the ConversionPattern parameter support microsecond timestamps?

Possibly related to "Segmentation fault log4cxx 0.10.0 on app exit ( RH Linux)"

I'm seeing a SIGABRT on application exit when closing my application.

Here is a backtrace showing the issue, shortly after I have closed the

program:

Breakpoint 2, 0x00125364 in apr_terminate () from /usr/lib/libapr-1.so.0

(gdb) bt

#0  0x00125364 in apr_terminate () from /usr/lib/libapr-1.so.0

#1  0x00272927 in ~APRInitializer (this=3D0x388f10) at

aprinitializer.cpp:45

#2  0x00272960 in __tcf_0 () at aprinitializer.cpp:50

#3  0x00544859 in exit () from /lib/libc.so.6

#4  0x0052edf4 in __libc_start_main () from /lib/libc.so.6

#5  0x08086031 in _start ()

(gdb) c

Continuing.

Program received signal SIGABRT, Aborted.

0x00a58410 in __kernel_vsyscall ()

(gdb) bt

#0  0x00a58410 in __kernel_vsyscall ()

#1  0x00541ba0 in raise () from /lib/libc.so.6

#2  0x005434b1 in abort () from /lib/libc.so.6

#3  0x0011e20f in apr_atomic_dec32 () from /usr/lib/libapr-1.so.0 <-- trying to call apr routine after apr_terminate

#4  0x002db4d5 in log4cxx::helpers::ObjectImpl::releaseRef

(this=3D0x970e6f8) at objectimpl.cpp:44

#5  0x002c5432 in log4cxx::Logger::releaseRef (this=3D0x970e6c0) at

logger.cpp:62

#6  0x080a0231 in ~ObjectPtrT (this=3D0x971fe28) at /usr/local/include/log4cxx/helpers/objectptr.h:100

#7  0x080b286d in ~MyConfig (this=3D0x971fd60) at ../src/xxxxxxxx.cpp:99

#8  0x08095132 in boost::checked_delete<MyConfig> (x=3D0x971fd60) at

/usr/include/boost/checked_delete.hpp:34

#9  0x08095147 in ~scoped_ptr (this=3D0x970ea08) at

/usr/include/boost/scoped_ptr.hpp:77

#10 0x08091794 in ~Main (this=3D0x970e754) at ../src/Main.cpp:155

#11 0x080af84f in ~ACE_Singleton (this=3D0x970e750) at /usr/include/ace/Singleton.h:80

#12 0x08099478 in ACE_Singleton<Arbiter, ACE_Mutex>::cleanup

(this=3D0x970e750) at /usr/include/ace/Singleton.cpp:111

#13 0x00d9fbc8 in ace_cleanup_destroyer () from /usr/lib/libACE.so.5.6.3

#14 0x00d9fdfd in ACE_OS_Exit_Info::call_hooks () from

/usr/lib/libACE.so.5.6.3

#15 0x00dd1ce9 in ACE_Object_Manager::fini () from

/usr/lib/libACE.so.5.6.3

#16 0x00dd1f44 in ACE_Object_Manager::~ACE_Object_Manager$delete () from

/usr/lib/libACE.so.5.6.3

#17 0x00dd2197 in

ACE_Object_Manager_Manager::~ACE_Object_Manager_Manager () from

/usr/lib/libACE.so.5.6.3

#18 0x00dd21d0 in

ACE_Object_Manager_Manager::~ACE_Object_Manager_Manager () from

/usr/lib/libACE.so.5.6.3

#19 0x00544b09 in __cxa_finalize () from /lib/libc.so.6 #20 0x00d5f7e4 in ?? () from /usr/lib/libACE.so.5.6.3

#21 0x00e5817c in ACE_Codeset_Registry::registry_db_ () from

/usr/lib/libACE.so.5.6.3

#22 0x0000002f in ?? ()

#23 0x009a17b4 in ?? ()

#24 0x00d5f7ba in ?? () from /usr/lib/libACE.so.5.6.3

#25 0x00e6061c in ?? () from /usr/lib/libACE.so.5.6.3

#26 0x009a1240 in _rtld_local () from /lib/ld-linux.so.2

#27 0xbff4c898 in ?? ()

#28 0x00e1659c in _fini () from /usr/lib/libACE.so.5.6.3

#29 0x00e1659c in _fini () from /usr/lib/libACE.so.5.6.3 #30 0x009956de in _dl_fini () from /lib/ld-linux.so.2

#31 0x00544859 in exit () from /lib/libc.so.6

#32 0x0052edf4 in __libc_start_main () from /lib/libc.so.6

#33 0x08086031 in _start ()

Note that my compiler does not exhibit the bugs described in

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D24472