[
https://issues.apache.org/jira/browse/LOG4J2-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Birch updated LOG4J2-1369:
-------------------------------
Description:
_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"
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](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`:
```
<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](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") {
@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);
}
}
}
```
was:
_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"
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](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`:
```
<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](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") {
@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);
}
}
}
```
> "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"
> 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](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`:
> ```
> <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](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") {
> @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);
> }
> }
> }
> ```
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
