You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Alex Birch (JIRA)" <ji...@apache.org> on 2016/04/18 18:40:25 UTC
[jira] [Comment Edited] (LOG4J2-1369) "xz" compression results in
plaintext, uncompressed files.
[ https://issues.apache.org/jira/browse/LOG4J2-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245969#comment-15245969 ]
Alex Birch edited comment on LOG4J2-1369 at 4/18/16 4:39 PM:
-------------------------------------------------------------
bq. Can you provide a patch?
For now our business is not blocked on this: we have compromised on bzip2 compression, which meets our immediate needs.
As a result I am unable to get time authorized to work on this.
I agree that it seems like the fix is potentially trivial. But working out how to develop, validate, integrate against and submit patches to this project would take more time than I can justify to my employer.
was (Author: billforward.alex):
> Can you provide a patch?
For now our business is not blocked on this: we have compromised on bzip2 compression, which meets our immediate needs.
As a result I am unable to get time authorized to work on this.
I agree that it seems like the fix is potentially trivial. But working out how to develop, validate, integrate against and submit patches to this project would take more time than I can justify.
> "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]_
> h2. Current state of world
> Currently our `RollingFileAppender` in `log4j2.xml` uses Gzip compression:
> {code:xml}
> <RollingFile name="RollingFile"
> fileName="logs/engine.log"
> filePattern="logs/engine.log.%i.gz">
> {code}
> h2. Goal
> I would like to switch to LZMA(2) (i.e. `.xz`) compression, to enjoy an improved compression ratio.
> h2. 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]:
> bq. 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}}:
> {code: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>
> {code}
> h2. Result
> When the RollingFileAppender is triggered: the archive created is indeed _named_ {{engines.log.1.xz}} — as required.
> *However*, its contents are incorrect:
> h3. Expectation
> {{engines.log.1.xz}} should contain LZMA(2) compressed text
> h3. Actual
> {{engines.log.1.xz}} instead contains plain, uncompressed text.
> h2. Sanity checks
> I confirm that the {{org.tukaani:xz}} and {{org.apache.commons:commons-compress}} successfully made it into the classpath of my jar:
> {code:none}
> 🍔 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/
> ...
> {code}
> This Java program is not deployed to a J2EE webserver. I believe its class loading is straightforward.
> h2. 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
> h2. Leads so far
> I was able to find [some evidence|https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/DefaultRolloverStrategy.java;h=e3b8ffe3c9a0cf83f4392c17786e8dc47f5046b5;hb=HEAD#l125] 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}}:
> {code:title=DefaultRolloverStrategy.java|borderStyle=solid}
> 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);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org