Uploaded image for project: 'Log4j 2'
  1. Log4j 2
  2. LOG4J2-1369

"xz" compression results in plaintext, uncompressed files.

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.5
    • Fix Version/s: 2.6
    • Component/s: Appenders, Core, Documentation
    • Labels:
    • Environment:

      Java SE 1.7

      Description

      Note: see associated StackOverflow problem

      Current state of world

      Currently our `RollingFileAppender` in `log4j2.xml` uses Gzip compression:

      <RollingFile name="RollingFile"
                   fileName="logs/engine.log"
                   filePattern="logs/engine.log.%i.gz">
      

      Goal

      I would like to switch to LZMA(2) (i.e. .xz) compression, to enjoy an improved compression ratio.

      Attempt

      I have tried changing engine.log.%i.gz to engine.log.%i.xz — as per the documentation:

      If the file pattern ends with .gz, .zip, .bz2, .deflate, .pack200, or .xz the resulting archive will be compressed using the compression scheme that matches the suffix. The formats bzip2, Deflate, Pack200 and XZ require Apache Commons Compress. In addition, XZ requires XZ for Java.

      Additionally I have ensured that I have a runtime dependency on XZ for Java — via pom.xml:

      <dependency>
          <!-- Support Log4j2 Log compression schemes: ".gz", ".zip", ".bz2", ".deflate", ".pack200", [".xz" (part 1 of 2)] -->
          <groupId>org.apache.commons</groupId>
          <artifactId>commons-compress</artifactId>
          <version>1.11</version>
      </dependency>
      <dependency>
          <!-- Support Log4j2 Log compression scheme [".xz" (part 2 of 2)] -->
          <groupId>org.tukaani</groupId>
          <artifactId>xz</artifactId>
          <version>1.5</version>
      </dependency>
      

      Result

      When the RollingFileAppender is triggered: the archive created is indeed named engines.log.1.xz — as required.

      However, its contents are incorrect:

      Expectation

      engines.log.1.xz should contain LZMA(2) compressed text

      Actual

      engines.log.1.xz instead contains plain, uncompressed text.

      Sanity checks

      I confirm that the org.tukaani:xz and org.apache.commons:commons-compress successfully made it into the classpath of my jar:

      🍔 jar tf mycooljar.jar | grep tukaani
      org/tukaani/
      org/tukaani/xz/
      ...
      
      🍔 jar tf mycooljar.jar | grep org/apache/commons/compress
      org/apache/commons/compress/
      org/apache/commons/compress/changes/
      ...
      

      This Java program is not deployed to a J2EE webserver. I believe its class loading is straightforward.

      Summary

      I have correctly followed the instructions necessary to create .gz archives.

      I believe the only additional step required to create .xz archives is: I must provide at runtime the XZ for Java artefact. I have done this.

      Am I missing something here? I am tempted to believe one of the following:

      • The functionality is broken
      • The docs are incomplete/incorrect
      • log4j2 fails to discover the class at runtime

      Leads so far

      I was able to find some evidence that perhaps I am expected to input .xy instead of .xz. If I use .xy: the log4j2 RollingAppender fails to produce archives. That is: it creates blank .xy files, and retains the unarchived plaintext as a .log file. It smells like a buggy implementation.

      Here is the code I present as evidence from org.apache.logging.log4j.core.appender.rolling.DefaultRolloverStrategy:

      DefaultRolloverStrategy.java
      static enum FileExtensions {
          XY(".xy") {
              @Override
              Action createCompressAction(final String renameTo, final String compressedName, final boolean deleteSource,
                       final int compressionLevel) {
                   // One of "gz", "bzip2", "xz", "pack200", or "deflate".
                   return new CommonsCompressAction("xy", source(renameTo), target(compressedName), deleteSource);
              }
          }
      }
      

        Attachments

          Activity

            People

            • Assignee:
              garydgregory Gary Gregory
              Reporter:
              billforward.alex Alex Birch
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: