Thanks Thorsten for the prompt reply. OK, we would love to use the existing Log4cxx buffering mechanism, but we found the time-stamp appended by Log4Cxx is the dequeue time rather than the enqueue time, so the question becomes is there any control over using the original log generating time instead of the delivery time?
Thanks, - Sherman On Mon, May 12, 2014 at 1:47 PM, Thorsten Schöning <tschoen...@am-soft.de>wrote: > Guten Tag Alder Netw, > am Montag, 12. Mai 2014 um 20:37 schrieben Sie: > > > A question regarding the time-stamp control over the > > log message, can the app provide its own time-stamp? > > No, you would need to re-implement the macros LOG4CXX_* you use in > your app, subclass Logger to override forcedLog, because that is > called by the macros, and override LoggingEvent with an additional > ctor which initializes timestamp different than it dies now with > apr_time_now. > > > This is useful when app buffers a large amount of logs > > and wish to preserve the original event generating timestamp. > > Does this mean you create log messages on your own, buffer those and > call log4cxx with those somewhat later? What's the benefit of doing > this, what's your use case? Log4cxx tries to take care of such things > using some appenders which allow buffering e.g. to save I/Os. From the > first glance I would create a special appender implementing much of > your use case by sticking to the default Log4cxx API. > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...........05151- 9468- 55 > Fax...............05151- 9468- 88 > Mobil..............0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > >
