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 GzipOutputStream was not likely, so the failure scenario was not as graceful as it could be.
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 Windoze you can use the dll version of zlib and if the dll isn't there don't do the compression.
I looked at the zlib license and that does not appear to be a stumbling block. If it had been GPL'd or LGPL'd, then spawning would likely be the only option. For the behavior that you described for Windows, that would involve LoadLibrary, GetProcAddress and the like (done by the equivalent APR methods) and zlib.dll would have to be on the path. The seems a lot of work for a likely failure. Using the zip methods in SHELL32.DLL would be much more likely to succeed. Wouldn't give you gz support which could still be done with spawning gzip.
If someone wants to work on this, file a bug report and go for it. However, I don't see it coming to the top of my stack anytime soon.
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.
