Re: File system full causes log4cxx to crash
Jacob L. Anawalt [EMAIL PROTECTED] writes: I am glad it worked out for you. At the same time I am concerned that you had to do this and I didn't. I would like to reproduce the problem so that I can handle it, preferably without putting try/catch around every logging statement... Some time back, I sent a message to the list asking what the behavior of an appender that throws an exception should be. As it is, a stray exception can unwind all the way through the library into the calling code. To my mind, wrapping log invocations with try/catch blocks isn't a completely satisfactory solution, as if you have multiple appenders associated with a logger, the exception will prevent subsequent appenders from being invoked. Personally, I think log4cxx should provide a guarantee that a log invocation will not throw an exception under any circumstances. One of the common use cases for emitting a log event is when you're in a error handling path, the last thing you want to worry about is the logging framework making hash of things. Two alternatives that come to mind are that every appender's append() method needs to have a try/catch block to squelch any exceptions, or that the appendLoopOnAppenders should have a try/catch block around each call to doAppend() invocation. Or since all it takes is one bad appender (and even if all appenders that are distributed with log4cxx are fixed, there's no guarantee that user's appenders will also be), a hybrid of the two approaches where the try/catch block around doAppend() logs an internal message about the unhandled exception. Basically, a framework shouldn't allow a callback to subvert or compromise the function of the framework itself. --jtc -- J.T. Conklin
Re: Rolling File appender with compression doesn't seem to work
Curt Arnold [EMAIL PROTECTED] writes: BTW, a documentation bug. The API documentation for TimeBasedRollingPolicy is missing the % sign before the d for specifying the FileNamePattern. It gives an example with: /wombat/folder/foo.d which should really be: /wombat/folder/foo.%d The source code comments have foo.%d. Apparently, the % gets dropped when Doxygen builds the site. Doxygen uses % as a keyword to disable automatic link generation. The % must be quoted (\%) for it to appear in the output. --jtc -- J.T. Conklin
Re: [VOTE] log4cxx 0.10.0 release candidate
Andreas Fester [EMAIL PROTECTED] writes: I dont currently have much time to work on log4cxx, but a quick review of the .tar.gz file at least showed that the UNIX configure script is missing. This results in a dependency on the GNU autotools to generate the configure script and the Makefile.in's before building, instead of the straightforward ./configure; ./make; ./make install. I think this is a reasonably big deal. I tried a quick autoreconf -ivf which failed because the APR_FIND_APR macro was not distributed with lib4cxx and find_apr.m4 isn't installed in /usr/pkg/share/aclocal as part of NetBSD's apr package. Using the ant build system would add a build dependency on Java, which looks a littlebit heavy for me. Using ant isn't even an option for systems where Java is not available. I'll see what I can do to jump this hurdle so I can report whether there are any other problems beyond configure. --jtc -- J.T. Conklin
cacheddateformat.cpp compile problem on NetBSD/amd64.
When compiling log4cxx from CVS HEAD on NetBSD/amd64, I ran into a small
discrepancy between the declaration and definition of CachedDataFormat::
findMillisecondStart. The time argument was log4cxx_time_t in the decl,
apr_time_t in the defn. I've enclosed a patch which changes the latter
to log4cxx_time_t.
FWIW, I followed the Report a log4cxx bug here link on
http://logging.apache.org/site/bugreport.html. While It brought up a
bug tracking system, I couldn't find any way to actually submit a bug
report, which is why subscribed and am sending it to the list.
--jtc
Index: src/cacheddateformat.cpp
===
RCS file: /home/cvspublic/logging-log4cxx/src/cacheddateformat.cpp,v
retrieving revision 1.16
diff -c -r1.16 cacheddateformat.cpp
*** src/cacheddateformat.cpp11 Mar 2005 06:34:49 - 1.16
--- src/cacheddateformat.cpp3 Apr 2005 22:00:42 -
***
*** 91,97
*field (likely RelativeTimeDateFormat)
*/
int CachedDateFormat::findMillisecondStart(
! apr_time_t time, const LogString formatted,
const DateFormatPtr formatter,
Pool pool) {
--- 91,97
*field (likely RelativeTimeDateFormat)
*/
int CachedDateFormat::findMillisecondStart(
! log4cxx_time_t time, const LogString formatted,
const DateFormatPtr formatter,
Pool pool) {
--
J.T. Conklin
