That sounds pretty useful to me. Using the existing compression actions could make it so you can more easily support other compression formats.
On Wed, May 4, 2022 at 4:44 PM Alexander Lambert (HE/HIM) <[email protected]> wrote: > > Hi all, > > We have a local modification to logging-log4j2/log4j-core that we are hoping > to contribute back to open source. We modify the RollingFileAppender, adding > a config option to compress the file as it is originally written instead of > on rollover. The value of this is in reducing the volume of data required to > be written to disk, improving performance. > > The summary of this change is as follows: > > * A new Boolean config option "compressOnWrite" for the > RollingFileAppender. > * If true, the log is written to e.g. a GZIPOutputStream instead of a > FileOutputStream. > * Any rollover compression action implied by the filePattern extension > is skipped as the file is already compressed, and so only a rename is done. > > Right now our change only applies to the ".gz" compression type, but it would > be possible to extend this functionality to the other compression methods - > the file extension from the fileName could be used to detect this. The GZIP > format is however especially appropriate for this feature: > > * No need to enforce an OnStartupTriggeringPolicy for the rollover, as it > is valid to append new GZIP data to a closed GZIP file. > > Is there any reason that this enhancement would not be accepted into log4j? > > Many thanks, > Alex
