logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Birch (JIRA)" <j...@apache.org>
Subject [jira] [Created] (LOG4J2-1369) "xz" compression results in plaintext, uncompressed files.
Date Mon, 18 Apr 2016 16:05:25 GMT
Alex Birch created LOG4J2-1369:

             Summary: "xz" compression results in plaintext, uncompressed files.
                 Key: LOG4J2-1369
                 URL: https://issues.apache.org/jira/browse/LOG4J2-1369
             Project: Log4j 2
          Issue Type: Bug
          Components: Appenders, Core, Documentation
    Affects Versions: 2.5
         Environment: Java SE 1.7
            Reporter: Alex Birch

_Note: see [associated StackOverflow problem](https://stackoverflow.com/questions/36695617/enabling-lzma2-i-e-xz-compression-in-log4j2)

## Current state of world

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

<RollingFile name="RollingFile"

## Goal

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

## Attempt

I have tried changing `engine.log.%i.gz` to `engine.log.%i.xz` — as per [the documentation](https://logging.apache.org/log4j/2.x/manual/appenders.html#DefaultRolloverStrategy):

> 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](http://tukaani.org/xz/java.html).

Additionally I have ensured that I have a runtime dependency on [XZ for Java](http://tukaani.org/xz/java.html)
— via `pom.xml`:

    <!-- Support Log4j2 Log compression schemes: ".gz", ".zip", ".bz2", ".deflate", ".pack200",
[".xz" (part 1 of 2)] -->
    <!-- Support Log4j2 Log compression scheme [".xz" (part 2 of 2)] -->

## 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

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

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](http://tukaani.org/xz/java.html) 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`:
static enum FileExtensions {
    XY(".xy") {
        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),

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message