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/
On Apr 29, 2008, at 2:41 PM, Dale King wrote:
Yes, that was the issue.
If it can't do the compression it should default to behaving as though
the compression suffix is not there.
I'm thinking the current behavior is likely due to copying the log4j
implementation where failure of GzipOutput
On Apr 29, 2008, at 2:10 PM, Unnikrishnan Udinoor wrote:
Hi,
Need your valuable inputs/findings on this issue.
Let me know if I am missing something here in the procedure.
This is stopping us from upgrading of the log4cxx libraries to the
latest version in our application.
Problem Highligh
Yes, that was the issue.
If it can't do the compression it should default to behaving as though
the compression suffix is not there.
It would also be a better idea to use the zlib library instead of
spawning out to command line apps. Linux users will most likely
already have zlib installed. For W
Hi,
Need your valuable inputs/findings on this issue.
Let me know if I am missing something here in the procedure.
This is stopping us from upgrading of the log4cxx libraries to the
latest version in our application.
Problem Highlight:
1.The sample program for log4cxx 0.10.0 core dump if
On Apr 29, 2008, at 11:38 AM, Dale King wrote:
I was testing out rolling file appenders (in Windows) which I set to
rollover every minute so I can see what happens. Here is the appender:
class="org.apache.log4j.rolling.RollingFileAppender">
class="org.apache.log4j.rolling.TimeBas
I was testing out rolling file appenders (in Windows) which I set to
rollover every minute so I can see what happens. Here is the appender:
It works fine if the .zip is not on there. With the .zip on there at the top
of the minute the file gets
