[GitHub] [commons-compress] PeterAlfreadLee commented on issue #87: COMPRESS-124 : Add support for extracting sparse entries from tar archives
PeterAlfreadLee commented on issue #87: COMPRESS-124 : Add support for extracting sparse entries from tar archives URL: https://github.com/apache/commons-compress/pull/87#issuecomment-562472392 Code pushed. The `TarArchiveInputStream` can deal with the sparse entries now. There's no spearate class that deals with the sparse entries. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (COMPRESS-124) Unable to extract a sparse entries from tar archives
[ https://issues.apache.org/jira/browse/COMPRESS-124?focusedWorklogId=355006&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-355006 ] ASF GitHub Bot logged work on COMPRESS-124: --- Author: ASF GitHub Bot Created on: 06/Dec/19 07:58 Start Date: 06/Dec/19 07:58 Worklog Time Spent: 10m Work Description: PeterAlfreadLee commented on issue #87: COMPRESS-124 : Add support for extracting sparse entries from tar archives URL: https://github.com/apache/commons-compress/pull/87#issuecomment-562472392 Code pushed. The `TarArchiveInputStream` can deal with the sparse entries now. There's no spearate class that deals with the sparse entries. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 355006) Time Spent: 3.5h (was: 3h 20m) > Unable to extract a sparse entries from tar archives > > > Key: COMPRESS-124 > URL: https://issues.apache.org/jira/browse/COMPRESS-124 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Affects Versions: 1.1, 1.2 > Environment: Platform independent. However, I'm currently using > Window 7 Enterprise. >Reporter: Patrick Dreyer >Priority: Major > Labels: tar > Fix For: 1.20 > > Attachments: gnuSparseFile.patch > > Time Spent: 3.5h > Remaining Estimate: 0h > > Good news first: I already have the patch ready for that. > I got several TAR files which I could not extract with any of the existing > Java implementations, but I could extract all those TAR files successfully > with GNU tar. > It turned out that all the failing TAR files contained so called sparse > files. Investigating the source code of all existing Java TAR implementations > showed me that none of them even recognizes the existence of GNU sparse > entries. > Actually, I don't need to process one of the contained sparse files and I'm > happy if I'm at least able to correctly untar all the non-sparsed files. > Thus, it would be sufficient recognizing sparse files without the need to > correctly un-sparse them while extracting. As long as all non-sparsed files > get extracted correctly, I'm fine. > The TAR files in question have all been VMware Diagnostic File bundles. > See > http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=653 > to know how to get them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (COMPRESS-124) Unable to extract a sparse entries from tar archives
[ https://issues.apache.org/jira/browse/COMPRESS-124?focusedWorklogId=355003&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-355003 ] ASF GitHub Bot logged work on COMPRESS-124: --- Author: ASF GitHub Bot Created on: 06/Dec/19 07:56 Start Date: 06/Dec/19 07:56 Worklog Time Spent: 10m Work Description: coveralls commented on issue #87: COMPRESS-124 : Add support for extracting sparse entries from tar archives URL: https://github.com/apache/commons-compress/pull/87#issuecomment-557956506 [![Coverage Status](https://coveralls.io/builds/27453876/badge)](https://coveralls.io/builds/27453876) Coverage increased (+0.2%) to 86.926% when pulling **50569e5bfb1526c54acf0abe5a6e4d5463c5a4bd on PeterAlfreadLee:COMPRESS-124** into **28049d2f89a76c5a4845c12151a483ca7773fb6f on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 355003) Time Spent: 3h 20m (was: 3h 10m) > Unable to extract a sparse entries from tar archives > > > Key: COMPRESS-124 > URL: https://issues.apache.org/jira/browse/COMPRESS-124 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Affects Versions: 1.1, 1.2 > Environment: Platform independent. However, I'm currently using > Window 7 Enterprise. >Reporter: Patrick Dreyer >Priority: Major > Labels: tar > Fix For: 1.20 > > Attachments: gnuSparseFile.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Good news first: I already have the patch ready for that. > I got several TAR files which I could not extract with any of the existing > Java implementations, but I could extract all those TAR files successfully > with GNU tar. > It turned out that all the failing TAR files contained so called sparse > files. Investigating the source code of all existing Java TAR implementations > showed me that none of them even recognizes the existence of GNU sparse > entries. > Actually, I don't need to process one of the contained sparse files and I'm > happy if I'm at least able to correctly untar all the non-sparsed files. > Thus, it would be sufficient recognizing sparse files without the need to > correctly un-sparse them while extracting. As long as all non-sparsed files > get extracted correctly, I'm fine. > The TAR files in question have all been VMware Diagnostic File bundles. > See > http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=653 > to know how to get them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-compress] coveralls edited a comment on issue #87: COMPRESS-124 : Add support for extracting sparse entries from tar archives
coveralls edited a comment on issue #87: COMPRESS-124 : Add support for extracting sparse entries from tar archives URL: https://github.com/apache/commons-compress/pull/87#issuecomment-557956506 [![Coverage Status](https://coveralls.io/builds/27453876/badge)](https://coveralls.io/builds/27453876) Coverage increased (+0.2%) to 86.926% when pulling **50569e5bfb1526c54acf0abe5a6e4d5463c5a4bd on PeterAlfreadLee:COMPRESS-124** into **28049d2f89a76c5a4845c12151a483ca7773fb6f on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (COMPRESS-124) Unable to extract a sparse entries from tar archives
[ https://issues.apache.org/jira/browse/COMPRESS-124?focusedWorklogId=354968&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-354968 ] ASF GitHub Bot logged work on COMPRESS-124: --- Author: ASF GitHub Bot Created on: 06/Dec/19 06:55 Start Date: 06/Dec/19 06:55 Worklog Time Spent: 10m Work Description: coveralls commented on issue #87: COMPRESS-124 : Add support for extracting sparse entries from tar archives URL: https://github.com/apache/commons-compress/pull/87#issuecomment-557956506 [![Coverage Status](https://coveralls.io/builds/27453106/badge)](https://coveralls.io/builds/27453106) Coverage increased (+0.2%) to 86.918% when pulling **6dd4d75bfb363cc3ed91fb190b5d80d4156e6f79 on PeterAlfreadLee:COMPRESS-124** into **28049d2f89a76c5a4845c12151a483ca7773fb6f on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 354968) Time Spent: 3h 10m (was: 3h) > Unable to extract a sparse entries from tar archives > > > Key: COMPRESS-124 > URL: https://issues.apache.org/jira/browse/COMPRESS-124 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Affects Versions: 1.1, 1.2 > Environment: Platform independent. However, I'm currently using > Window 7 Enterprise. >Reporter: Patrick Dreyer >Priority: Major > Labels: tar > Fix For: 1.20 > > Attachments: gnuSparseFile.patch > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Good news first: I already have the patch ready for that. > I got several TAR files which I could not extract with any of the existing > Java implementations, but I could extract all those TAR files successfully > with GNU tar. > It turned out that all the failing TAR files contained so called sparse > files. Investigating the source code of all existing Java TAR implementations > showed me that none of them even recognizes the existence of GNU sparse > entries. > Actually, I don't need to process one of the contained sparse files and I'm > happy if I'm at least able to correctly untar all the non-sparsed files. > Thus, it would be sufficient recognizing sparse files without the need to > correctly un-sparse them while extracting. As long as all non-sparsed files > get extracted correctly, I'm fine. > The TAR files in question have all been VMware Diagnostic File bundles. > See > http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=653 > to know how to get them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-compress] coveralls edited a comment on issue #87: COMPRESS-124 : Add support for extracting sparse entries from tar archives
coveralls edited a comment on issue #87: COMPRESS-124 : Add support for extracting sparse entries from tar archives URL: https://github.com/apache/commons-compress/pull/87#issuecomment-557956506 [![Coverage Status](https://coveralls.io/builds/27453106/badge)](https://coveralls.io/builds/27453106) Coverage increased (+0.2%) to 86.918% when pulling **6dd4d75bfb363cc3ed91fb190b5d80d4156e6f79 on PeterAlfreadLee:COMPRESS-124** into **28049d2f89a76c5a4845c12151a483ca7773fb6f on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (GEOMETRY-69) BSPTreeVisitor stop visit
[ https://issues.apache.org/jira/browse/GEOMETRY-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989332#comment-16989332 ] Matt Juntunen commented on GEOMETRY-69: --- PR is ready: https://github.com/apache/commons-geometry/pull/42 > BSPTreeVisitor stop visit > - > > Key: GEOMETRY-69 > URL: https://issues.apache.org/jira/browse/GEOMETRY-69 > Project: Apache Commons Geometry > Issue Type: Improvement >Reporter: Matt Juntunen >Priority: Major > Labels: pull-request-available > Fix For: 1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Update the BSPTreeVisitor interface to allow implementations to stop the node > visit process when desired. The current implementation always visits all > nodes in the tree. The JDK {{FileVisitor}} interface might be a good > reference. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEOMETRY-69) BSPTreeVisitor stop visit
[ https://issues.apache.org/jira/browse/GEOMETRY-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEOMETRY-69: --- Labels: pull-request-available (was: ) > BSPTreeVisitor stop visit > - > > Key: GEOMETRY-69 > URL: https://issues.apache.org/jira/browse/GEOMETRY-69 > Project: Apache Commons Geometry > Issue Type: Improvement >Reporter: Matt Juntunen >Priority: Major > Labels: pull-request-available > Fix For: 1.0 > > > Update the BSPTreeVisitor interface to allow implementations to stop the node > visit process when desired. The current implementation always visits all > nodes in the tree. The JDK {{FileVisitor}} interface might be a good > reference. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-geometry] darkma773r opened a new pull request #42: GEOMETRY-69: BSPTreeVisitor early termination
darkma773r opened a new pull request #42: GEOMETRY-69: BSPTreeVisitor early termination URL: https://github.com/apache/commons-geometry/pull/42 Adding return value to BSPTreeVisitor.visit(BSPTree.Node) so that visit operations can terminate early, without visiting all nodes in the tree. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-collections] dota17 commented on issue #114: Modified the error in the comments of BulkTest.java
dota17 commented on issue #114: Modified the error in the comments of BulkTest.java URL: https://github.com/apache/commons-collections/pull/114#issuecomment-562404342 @garydgregory The code in the comments of BulkTest.java shows the reader how to define both simple and bulk test method. The method bulkTestKeySet() in class HashMapTest wants to define a bulk test method, so it should invoke the SetTest() method which is a constructer of SetTest class rather than the TestSet() method which is not defined. This spelling mistake confused me a lot at first. Chen This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-pool] garydgregory commented on a change in pull request #27: NO-JIRA [Javadoc] Add missing @throws comment in PoolUtils.
garydgregory commented on a change in pull request #27: NO-JIRA [Javadoc] Add missing @throws comment in PoolUtils. URL: https://github.com/apache/commons-pool/pull/27#discussion_r354628146 ## File path: src/main/java/org/apache/commons/pool2/PoolUtils.java ## @@ -307,6 +307,8 @@ public static void checkRethrow(final Throwable t) { * @param pool *the ObjectPool to be "wrapped" in a synchronized ObjectPool. * @param the type of objects in the pool + * @throws IllegalArgumentException + * when pool is null. Review comment: That would be great :-) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-bcel] garydgregory commented on a change in pull request #37: Improve documentation of Pass3bVerifier
garydgregory commented on a change in pull request #37: Improve documentation of Pass3bVerifier URL: https://github.com/apache/commons-bcel/pull/37#discussion_r354627927 ## File path: src/main/java/org/apache/bcel/verifier/structurals/Pass3bVerifier.java ## @@ -74,26 +74,68 @@ * time, an InstructionContext object will get the current information * we have about its symbolic execution predecessors. */ -private static final class InstructionContextQueue{ +private static final class InstructionContextQueue { +// The following two fields together represent the queue. +/** The first elements from pairs in the queue. */ private final List ics = new Vector<>(); +/** The second elements from pairs in the queue. */ private final List> ecs = new Vector<>(); + +/** + * Add an (InstructionContext, ExecutionChain) pair to their respective queues. + * + * @param ic the InstructionContext + * @param executionChain the ExecutionChain + */ public void add(final InstructionContext ic, final ArrayList executionChain) { ics.add(ic); ecs.add(executionChain); } + +/** + * Test if InstructionContext queue is empty. + * + * @return true if the InstructionContext queue is empty. + */ public boolean isEmpty() { return ics.isEmpty(); } + +/** + * Remove a specific (InstructionContext, ExecutionChain) pair from their respective queues. + * + * @param i the index of the items to be removed + */ public void remove(final int i) { ics.remove(i); ecs.remove(i); } + +/** + * Fetch a specific InstructionContext from the queue. Review comment: The method is a "getter", therefore should start its Javadoc with "Gets ...". This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-bcel] garydgregory commented on a change in pull request #37: Improve documentation of Pass3bVerifier
garydgregory commented on a change in pull request #37: Improve documentation of Pass3bVerifier URL: https://github.com/apache/commons-bcel/pull/37#discussion_r35462 ## File path: src/main/java/org/apache/bcel/verifier/structurals/Pass3bVerifier.java ## @@ -74,26 +74,68 @@ * time, an InstructionContext object will get the current information * we have about its symbolic execution predecessors. */ -private static final class InstructionContextQueue{ +private static final class InstructionContextQueue { +// The following two fields together represent the queue. +/** The first elements from pairs in the queue. */ private final List ics = new Vector<>(); +/** The second elements from pairs in the queue. */ private final List> ecs = new Vector<>(); + +/** + * Add an (InstructionContext, ExecutionChain) pair to their respective queues. Review comment: Hi @mernst Thank you chipping in. I am trying to get Commons to be consistent in Javadocs to be in the form "Adds ..."., "Removes ...", "Gets ...", "Sets ...", and so on. TY! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-bcel] mernst opened a new pull request #37: Improve documentation of Pass3bVerifier
mernst opened a new pull request #37: Improve documentation of Pass3bVerifier URL: https://github.com/apache/commons-bcel/pull/37 This pull request adds some missing documentation to Pass3bVerifier. It also corrects some indentation. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (COLLECTIONS-740) Missing @throws comment in SwitchTransformer.switchTransformer
[ https://issues.apache.org/jira/browse/COLLECTIONS-740?focusedWorklogId=354767&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-354767 ] ASF GitHub Bot logged work on COLLECTIONS-740: -- Author: ASF GitHub Bot Created on: 05/Dec/19 23:13 Start Date: 05/Dec/19 23:13 Worklog Time Spent: 10m Work Description: Prodigysov commented on pull request #124: [COLLECTIONS-740] Add missing @throws comment for SwitchTransformer.switchTransformer. URL: https://github.com/apache/commons-collections/pull/124#discussion_r354595700 ## File path: src/main/java/org/apache/commons/collections4/functors/SwitchTransformer.java ## @@ -51,6 +51,7 @@ * @return the chained transformer * @throws NullPointerException if array is null * @throws NullPointerException if any element in the array is null + * @throws IllegalArgumentException if predicate and transformer arrays do not have the same size Review comment: Agreed. I fixed this and also fixed some other inconsistencies of the @throw Javadoc on both sides. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 354767) Time Spent: 20m (was: 10m) > Missing @throws comment in SwitchTransformer.switchTransformer > -- > > Key: COLLECTIONS-740 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-740 > Project: Commons Collections > Issue Type: Improvement > Components: Functor >Reporter: Pengyu Nie >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > SwitchTransformer.switchTransformer could throw IllegalArgumentException if > predicate and transformer arrays have different lengths, but that's not > described in Javadoc. See the method below, the exception may happen in the > first if statement: > {code:java} > /** > * Factory method that performs validation and copies the parameter arrays. > * > * @param the input type > * @param the output type > * @param predicates array of predicates, cloned, no nulls > * @param transformers matching array of transformers, cloned, no nulls > * @param defaultTransformer the transformer to use if no match, null means > return null > * @return the chained transformer > * @throws NullPointerException if array is null > * @throws NullPointerException if any element in the array is null > * @throws IllegalAccessException if predicate and transformer arrays do not > have the same size > */ > @SuppressWarnings("unchecked") > public static Transformer switchTransformer(final Predicate super I>[] predicates, > final Transformer[] transformers, > final Transformer defaultTransformer) { > FunctorUtils.validate(predicates); > FunctorUtils.validate(transformers); > if (predicates.length != transformers.length) { > throw new IllegalArgumentException("The predicate and transformer > arrays must be the same size"); > } > if (predicates.length == 0) { > return (Transformer) (defaultTransformer == null ? > ConstantTransformer.nullTransformer() : > > defaultTransformer); > } > return new SwitchTransformer<>(predicates, transformers, > defaultTransformer); > } > {code} > I'll submit a PR to add the missing @throws documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-collections] Prodigysov commented on a change in pull request #124: [COLLECTIONS-740] Add missing @throws comment for SwitchTransformer.switchTransformer.
Prodigysov commented on a change in pull request #124: [COLLECTIONS-740] Add missing @throws comment for SwitchTransformer.switchTransformer. URL: https://github.com/apache/commons-collections/pull/124#discussion_r354595700 ## File path: src/main/java/org/apache/commons/collections4/functors/SwitchTransformer.java ## @@ -51,6 +51,7 @@ * @return the chained transformer * @throws NullPointerException if array is null * @throws NullPointerException if any element in the array is null + * @throws IllegalArgumentException if predicate and transformer arrays do not have the same size Review comment: Agreed. I fixed this and also fixed some other inconsistencies of the @throw Javadoc on both sides. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (COLLECTIONS-739) Wrong @throws comments in DefaultedMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-739?focusedWorklogId=354760&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-354760 ] ASF GitHub Bot logged work on COLLECTIONS-739: -- Author: ASF GitHub Bot Created on: 05/Dec/19 23:05 Start Date: 05/Dec/19 23:05 Worklog Time Spent: 10m Work Description: Prodigysov commented on pull request #123: [COLLECTIONS-739] Fix inconsistent @throws comments in DefaultedMap URL: https://github.com/apache/commons-collections/pull/123#discussion_r354593137 ## File path: src/main/java/org/apache/commons/collections4/map/DefaultedMap.java ## @@ -105,7 +105,8 @@ * @param map the map to decorate, must not be null * @param factory the factory to use to create entries, must not be null * @return a new defaulting map - * @throws NullPointerException if map or factory is null + * @throws NullPointerException if map is null + * @throws IllegalArgumentException if factory is null Review comment: Agreed. I changed to NullPointerException and added test cases for it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 354760) Time Spent: 0.5h (was: 20m) > Wrong @throws comments in DefaultedMap > -- > > Key: COLLECTIONS-739 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-739 > Project: Commons Collections > Issue Type: Improvement > Components: Map >Reporter: Pengyu Nie >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > I found some @throws comments in DefaultedMap are inconsistent with the code > or missing. For examples: > 1. The comment for defaultedMap(Map, Factory) has wrong > exception type: > Line 108: > {code:java} > /** ... @throws NullPointerException if map or factory is null ... */ > {code} > Line 112-114: > {code:java} > if (factory == null) { > throw new IllegalArgumentException("Factory must not be null"); > } > {code} > 2. For defaultMap(Map, Transformer, this null > checking does not have corresponding @throws comment: > Line 135-137: > {code:java} > if (transformer == null) { > throw new IllegalArgumentException("Transformer must not be null"); > } > {code} > I suggest adding: > {code:java} > @throws IllegalArgumentException if transformer is null. > {code} > I'll submit a PR for these suggested changes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-collections] Prodigysov commented on a change in pull request #123: [COLLECTIONS-739] Fix inconsistent @throws comments in DefaultedMap
Prodigysov commented on a change in pull request #123: [COLLECTIONS-739] Fix inconsistent @throws comments in DefaultedMap URL: https://github.com/apache/commons-collections/pull/123#discussion_r354593137 ## File path: src/main/java/org/apache/commons/collections4/map/DefaultedMap.java ## @@ -105,7 +105,8 @@ * @param map the map to decorate, must not be null * @param factory the factory to use to create entries, must not be null * @return a new defaulting map - * @throws NullPointerException if map or factory is null + * @throws NullPointerException if map is null + * @throws IllegalArgumentException if factory is null Review comment: Agreed. I changed to NullPointerException and added test cases for it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (COLLECTIONS-739) Wrong @throws comments in DefaultedMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989237#comment-16989237 ] Pengyu Nie commented on COLLECTIONS-739: Hi Chen, Thanks for reviewing. I've updated the pull request to 1. update IllegalArgumentException to NullPointerException, and 2. add test cases for it. > Wrong @throws comments in DefaultedMap > -- > > Key: COLLECTIONS-739 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-739 > Project: Commons Collections > Issue Type: Improvement > Components: Map >Reporter: Pengyu Nie >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > I found some @throws comments in DefaultedMap are inconsistent with the code > or missing. For examples: > 1. The comment for defaultedMap(Map, Factory) has wrong > exception type: > Line 108: > {code:java} > /** ... @throws NullPointerException if map or factory is null ... */ > {code} > Line 112-114: > {code:java} > if (factory == null) { > throw new IllegalArgumentException("Factory must not be null"); > } > {code} > 2. For defaultMap(Map, Transformer, this null > checking does not have corresponding @throws comment: > Line 135-137: > {code:java} > if (transformer == null) { > throw new IllegalArgumentException("Transformer must not be null"); > } > {code} > I suggest adding: > {code:java} > @throws IllegalArgumentException if transformer is null. > {code} > I'll submit a PR for these suggested changes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CODEC-261) Unable to encode read-only ByteBuffer
[ https://issues.apache.org/jira/browse/CODEC-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Herbert resolved CODEC-261. Fix Version/s: 1.14 Resolution: Fixed The modifications to fix CODEC-259 have fixed this issue. Added a test to master to demonstrate encoding of a read-only ByteBuffer. > Unable to encode read-only ByteBuffer > - > > Key: CODEC-261 > URL: https://issues.apache.org/jira/browse/CODEC-261 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.13 >Reporter: James Howe >Priority: Major > Fix For: 1.14 > > > A read-only array-backed {{ByteBuffer}} fails to encode, because the backing > array is not accessible. > {code:java} > Hex.encodeHex(ByteBuffer.wrap(new byte[]{1}).asReadOnlyBuffer()) > {code} > {noformat} > java.nio.ReadOnlyBufferException > at java.nio.ByteBuffer.array(ByteBuffer.java:996) > at org.apache.commons.codec.binary.Hex.encodeHex(Hex.java:213) > at org.apache.commons.codec.binary.Hex.encodeHex(Hex.java:172) > at org.apache.commons.codec.binary.Hex.encodeHex(Hex.java:140) > {noformat} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CODEC-265) java.lang.NegativeArraySizeException
[ https://issues.apache.org/jira/browse/CODEC-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Herbert resolved CODEC-265. Fix Version/s: 1.14 Resolution: Fixed Memory allocation has been added to allow encoding up to the array allocation limit. > java.lang.NegativeArraySizeException > -- > > Key: CODEC-265 > URL: https://issues.apache.org/jira/browse/CODEC-265 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.13 > Environment: Linux = Ubuntu 18.04.3 LTS > JDK = 1.8 > >Reporter: Ingimar >Assignee: Alex Herbert >Priority: Critical > Fix For: 1.14 > > Attachments: NewClientEncodePost.java, Util.java, pom.xml > > Time Spent: 20m > Remaining Estimate: 0h > > Hi, > trying to encode a file that is 1GB of size. > ( linux : > {code:java} > fallocate -l 1GB 1gb.zip{code} > ) > I want to post that file to a RESTful-service, package in JSON. > *here is the code* > > > {code:java} > String filePath = "/tmp/1gb.zip"; > System.out.println("\t Post to : ".concat(URL)); > System.out.println("\t file : ".concat(filePath)); > Path path = Paths.get(filePath); > byte[] bArray = Files.readAllBytes(path); > // testing commons codec 1.16 (2019-11-05) > byte[] encodeBase64 = Base64.encodeBase64(bArray); > final String contentToBeSaved = new String(encodeBase64); > HttpClient client = HttpClientBuilder.create().build(); > HttpResponse response = null; > JSONObject metadata = new JSONObject(); > metadata.put("owner", "Ingo"); > metadata.put("access", "public"); > metadata.put("licenseType", "CC BY"); > metadata.put("fileName", "fileName"); > metadata.put("fileDataBase64", contentToBeSaved); > String metadataFormatted = > StringEscapeUtils.unescapeJavaScript(metadata.toString()); > StringEntity entity = new StringEntity(metadataFormatted, > ContentType.APPLICATION_JSON); > HttpPost post = new HttpPost(URL); > post.setEntity(entity); > response = client.execute(post); > HttpEntity responseEntity = response.getEntity(); > String responseFromMediaserver = EntityUtils.toString(responseEntity, > "UTF-8"); > System.out.println("\n"); > System.out.println("Response is : " + responseFromMediaserver); > JSONObject json = new JSONObject(responseFromMediaserver); > String uuid = json.getString("uuid"); > System.out.println("UUID is " + uuid); > {code} > > > # mvn clean package > # java -Xms512m -Xmx20480m -jar target/mediaClient.jar > The crasch is in > > {code:java} > byte[] encodeBase64 = Base64.encodeBase64(bArray);{code} > > the stacktrace is : > {code:java} > > Starting NewClientEncodePost > Post to : http://127.0.0.1:8080/MediaServerResteasy/media > file : /tmp/1gb.zip > Exception in thread "main" java.lang.NegativeArraySizeException > at > org.apache.commons.codec.binary.BaseNCodec.resizeBuffer(BaseNCodec.java:253) > at > org.apache.commons.codec.binary.BaseNCodec.ensureBufferSize(BaseNCodec.java:269) > at org.apache.commons.codec.binary.Base64.encode(Base64.java:380) > at org.apache.commons.codec.binary.BaseNCodec.encode(BaseNCodec.java:451) > at org.apache.commons.codec.binary.BaseNCodec.encode(BaseNCodec.java:430) > at org.apache.commons.codec.binary.Base64.encodeBase64(Base64.java:679) > at org.apache.commons.codec.binary.Base64.encodeBase64(Base64.java:642) > at org.apache.commons.codec.binary.Base64.encodeBase64(Base64.java:623) > at org.apache.commons.codec.binary.Base64.encodeBase64(Base64.java:556) > at > se.nrm.bio.mediaserver.testing.base64.NewClientEncodePost.posting(NewClientEncodePost.java:55) > at > se.nrm.bio.mediaserver.testing.base64.NewClientEncodePost.main(NewClientEncodePost.java:38) > > {code} > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CODEC-259) Broken direct java.nio.ByteBuffer support in org.apache.commons.codec.binary.Hex
[ https://issues.apache.org/jira/browse/CODEC-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Herbert resolved CODEC-259. Resolution: Fixed Fixed in git master. The ByteBuffer backing array is only used if the array size matches the count of bytes remaining in the buffer. > Broken direct java.nio.ByteBuffer support in > org.apache.commons.codec.binary.Hex > > > Key: CODEC-259 > URL: https://issues.apache.org/jira/browse/CODEC-259 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.11, 1.12 >Reporter: Tomas Shestakov >Priority: Major > Fix For: 1.14 > > Time Spent: 20m > Remaining Estimate: 0h > > java.nio.ByteBuffer support in org.apache.commons.codec.binary.Hex does not > work properly for direct ByteBuffer created by ByteBuffer.allocateDirect > method and for heap ByteBuffers which arrayOffset() or byteBuffer.position() > greater than zero or byteBuffer.remaining() is not equal > byteBuffer.array().{color:#660e7a}length{color}: > This test will produce java.lang.UnsupportedOperationException > {code:java} > @Test > public void testEncodeHexByteBufferEmpty() { > assertTrue(Arrays.equals(new char[0], > Hex.encodeHex(ByteBuffer.allocateDirect(0; > } > {code} > This one will fail > {code:java} > @Test > public void testEncodeHexByteBufferHelloWorldLowerCaseHex() { > final ByteBuffer b = ByteBuffer.wrap(StringUtils.getBytesUtf8("[Hello > World]"), 1, 11); > final String expected = "48656c6c6f20576f726c64"; > char[] actual; > actual = Hex.encodeHex(b); > assertEquals(expected, new String(actual)); > actual = Hex.encodeHex(b, true); > assertEquals(expected, new String(actual)); > actual = Hex.encodeHex(b, false); > assertFalse(expected.equals(new String(actual))); > } > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-codec] asfgit merged pull request #32: [codec-259] Hex: consume all ByteBuffer.remaining() bytes
asfgit merged pull request #32: [codec-259] Hex: consume all ByteBuffer.remaining() bytes URL: https://github.com/apache/commons-codec/pull/32 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-codec] coveralls edited a comment on issue #32: [codec-259] Hex: consume all ByteBuffer.remaining() bytes
coveralls edited a comment on issue #32: [codec-259] Hex: consume all ByteBuffer.remaining() bytes URL: https://github.com/apache/commons-codec/pull/32#issuecomment-560711185 [![Coverage Status](https://coveralls.io/builds/27446135/badge)](https://coveralls.io/builds/27446135) Coverage increased (+0.03%) to 93.367% when pulling **6cf348211a23835128465a22c9148138fb99c060 on aherbert:fix-CODEC-259** into **a3a4eddd3e6180385ca38efd9ff4965c07995e64 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-pool] Prodigysov commented on a change in pull request #27: NO-JIRA [Javadoc] Add missing @throws comment in PoolUtils.
Prodigysov commented on a change in pull request #27: NO-JIRA [Javadoc] Add missing @throws comment in PoolUtils. URL: https://github.com/apache/commons-pool/pull/27#discussion_r354564862 ## File path: src/main/java/org/apache/commons/pool2/PoolUtils.java ## @@ -307,6 +307,8 @@ public static void checkRethrow(final Throwable t) { * @param pool *the ObjectPool to be "wrapped" in a synchronized ObjectPool. * @param the type of objects in the pool + * @throws IllegalArgumentException + * when pool is null. Review comment: I used html tags because I saw the other Javadoc in this class are using it. Do you want me to change them as well? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-pool] garydgregory commented on a change in pull request #27: NO-JIRA [Javadoc] Add missing @throws comment in PoolUtils.
garydgregory commented on a change in pull request #27: NO-JIRA [Javadoc] Add missing @throws comment in PoolUtils. URL: https://github.com/apache/commons-pool/pull/27#discussion_r354540090 ## File path: src/main/java/org/apache/commons/pool2/PoolUtils.java ## @@ -307,6 +307,8 @@ public static void checkRethrow(final Throwable t) { * @param pool *the ObjectPool to be "wrapped" in a synchronized ObjectPool. * @param the type of objects in the pool + * @throws IllegalArgumentException + * when pool is null. Review comment: Please use `{@code ...}` instead of HTML tags, it is more succinct and less error prone. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-pool] garydgregory merged pull request #28: NO-JIRA (Javadoc): Add missing @throws comment in SoftReferenceObjectPool.
garydgregory merged pull request #28: NO-JIRA (Javadoc): Add missing @throws comment in SoftReferenceObjectPool. URL: https://github.com/apache/commons-pool/pull/28 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-pool] coveralls commented on issue #28: NO-JIRA (doc): Add missing @throws comment in SoftReferenceObjectPool.
coveralls commented on issue #28: NO-JIRA (doc): Add missing @throws comment in SoftReferenceObjectPool. URL: https://github.com/apache/commons-pool/pull/28#issuecomment-562294414 [![Coverage Status](https://coveralls.io/builds/27443946/badge)](https://coveralls.io/builds/27443946) Coverage increased (+0.07%) to 84.288% when pulling **330490440e74efc2ff6968ca87881f57205cd416 on Prodigysov:NO-JIRA-SoftReferenceObjectPool** into **2d2049233940b10c7dd35df70a353d383f601053 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-pool] coveralls commented on issue #27: NO-JIRA (doc): Add missing @throws comment in PoolUtils.
coveralls commented on issue #27: NO-JIRA (doc): Add missing @throws comment in PoolUtils. URL: https://github.com/apache/commons-pool/pull/27#issuecomment-562292214 [![Coverage Status](https://coveralls.io/builds/27443697/badge)](https://coveralls.io/builds/27443697) Coverage decreased (-0.1%) to 84.121% when pulling **4346a109ed0ac652d231296c6c0b1cb5ab075deb on Prodigysov:NO-JIRA-PoolUtils** into **2d2049233940b10c7dd35df70a353d383f601053 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-pool] Prodigysov opened a new pull request #28: NO-JIRA (doc): Add missing @throws comment in SoftReferenceObjectPool.
Prodigysov opened a new pull request #28: NO-JIRA (doc): Add missing @throws comment in SoftReferenceObjectPool. URL: https://github.com/apache/commons-pool/pull/28 A `@throws` documentation is missing in Javadoc of SoftReferenceObjectPool.returnObject, so I added it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-pool] Prodigysov opened a new pull request #27: NO-JIRA (doc): Add missing @throws comment in PoolUtils.
Prodigysov opened a new pull request #27: NO-JIRA (doc): Add missing @throws comment in PoolUtils. URL: https://github.com/apache/commons-pool/pull/27 Some @throws documentations are missing in Javadoc of PoolUtils, so I added them according to what is checked in the code. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (COLLECTIONS-734) Encountered an IllegalStateException while traversing with Flat3Map.entrySet()
[ https://issues.apache.org/jira/browse/COLLECTIONS-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved COLLECTIONS-734. - Fix Version/s: 4.5 Resolution: Fixed A slightly different patch for the test is now in git master. Please verify and close. > Encountered an IllegalStateException while traversing with > Flat3Map.entrySet() > --- > > Key: COLLECTIONS-734 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-734 > Project: Commons Collections > Issue Type: Bug > Components: Map >Affects Versions: 3.0 >Reporter: Chen >Priority: Major > Fix For: 4.5 > > Time Spent: 20m > Remaining Estimate: 0h > > Encountered an IllegalStateException while traversing with > Flat3Map.entrySet() > {code:java} > //代码示例 > public void testEntrySet() { > final Flat3Map map = new Flat3Map<>(); > map.put(1, "A"); > map.put(2, "B"); > map.put(3, "C"); > Iterator> it = map.entrySet().iterator(); > Map.Entry mapEntry1 = it.next(); > Map.Entry mapEntry2 = it.next(); > Map.Entry mapEntry3 = it.next(); > it.remove();assertEquals(2, map.size()); > } > {code} > Using the above code will generate an IllegalStateException. > The reason for this problem is that there is a problem with the > EntryIterator.remove() method in the Flat3Map java class. > I submitted a > [PR|https://github.com/apache/commons-collections/pull/115](https://github.com/apache/commons-collections/pull/115) > to fix this bug. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (COLLECTIONS-734) Encountered an IllegalStateException while traversing with Flat3Map.entrySet()
[ https://issues.apache.org/jira/browse/COLLECTIONS-734?focusedWorklogId=354419&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-354419 ] ASF GitHub Bot logged work on COLLECTIONS-734: -- Author: ASF GitHub Bot Created on: 05/Dec/19 16:12 Start Date: 05/Dec/19 16:12 Worklog Time Spent: 10m Work Description: asfgit commented on pull request #115: [COLLECTIONS-734] Update EntryIterator.remove() to fix bug URL: https://github.com/apache/commons-collections/pull/115 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 354419) Time Spent: 20m (was: 10m) > Encountered an IllegalStateException while traversing with > Flat3Map.entrySet() > --- > > Key: COLLECTIONS-734 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-734 > Project: Commons Collections > Issue Type: Bug > Components: Map >Affects Versions: 3.0 >Reporter: Chen >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Encountered an IllegalStateException while traversing with > Flat3Map.entrySet() > {code:java} > //代码示例 > public void testEntrySet() { > final Flat3Map map = new Flat3Map<>(); > map.put(1, "A"); > map.put(2, "B"); > map.put(3, "C"); > Iterator> it = map.entrySet().iterator(); > Map.Entry mapEntry1 = it.next(); > Map.Entry mapEntry2 = it.next(); > Map.Entry mapEntry3 = it.next(); > it.remove();assertEquals(2, map.size()); > } > {code} > Using the above code will generate an IllegalStateException. > The reason for this problem is that there is a problem with the > EntryIterator.remove() method in the Flat3Map java class. > I submitted a > [PR|https://github.com/apache/commons-collections/pull/115](https://github.com/apache/commons-collections/pull/115) > to fix this bug. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-collections] asfgit closed pull request #115: [COLLECTIONS-734] Update EntryIterator.remove() to fix bug
asfgit closed pull request #115: [COLLECTIONS-734] Update EntryIterator.remove() to fix bug URL: https://github.com/apache/commons-collections/pull/115 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-collections] garydgregory commented on issue #114: Modified the error in javadoc of BulkTest
garydgregory commented on issue #114: Modified the error in javadoc of BulkTest URL: https://github.com/apache/commons-collections/pull/114#issuecomment-562172575 @dota17 The title of this PR is "Modified the error in javadoc of BulkTest" but this is a code change, not a Javadoc change. Do you mean to change the Javadoc or the code? Why is the code wrong? Thank you! Gary This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (COMPRESS-477) Support for splitted zip files
[ https://issues.apache.org/jira/browse/COMPRESS-477?focusedWorklogId=354302&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-354302 ] ASF GitHub Bot logged work on COMPRESS-477: --- Author: ASF GitHub Bot Created on: 05/Dec/19 13:56 Start Date: 05/Dec/19 13:56 Worklog Time Spent: 10m Work Description: coveralls commented on issue #84: COMPRESS-477 Add support for extracting splitted zip files URL: https://github.com/apache/commons-compress/pull/84#issuecomment-545874938 [![Coverage Status](https://coveralls.io/builds/27435814/badge)](https://coveralls.io/builds/27435814) Coverage increased (+0.2%) to 86.897% when pulling **0df4d084182c2c2662b777ee2c3b04a1c42bbc66 on PeterAlfreadLee:COMPRESS_477** into **28049d2f89a76c5a4845c12151a483ca7773fb6f on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 354302) Time Spent: 10h 20m (was: 10h 10m) > Support for splitted zip files > -- > > Key: COMPRESS-477 > URL: https://issues.apache.org/jira/browse/COMPRESS-477 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Affects Versions: 1.18 >Reporter: Luís Filipe Nassif >Priority: Major > Labels: zip > Fix For: 1.20 > > Time Spent: 10h 20m > Remaining Estimate: 0h > > It would be very useful to support splitted zip files. I've read > [https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT] and understood > that simply concatenating the segments and removing the split signature > 0x08074b50 from first segment would be sufficient, but it is not that simple > because compress fails with exception below: > {code} > Caused by: java.util.zip.ZipException: archive's ZIP64 end of central > directory locator is corrupt. > at > org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory64(ZipFile.java:924) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:901) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:621) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:295) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:280) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:236) > ~[commons-compress-1.18.jar:1.18] > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-compress] coveralls edited a comment on issue #84: COMPRESS-477 Add support for extracting splitted zip files
coveralls edited a comment on issue #84: COMPRESS-477 Add support for extracting splitted zip files URL: https://github.com/apache/commons-compress/pull/84#issuecomment-545874938 [![Coverage Status](https://coveralls.io/builds/27435814/badge)](https://coveralls.io/builds/27435814) Coverage increased (+0.2%) to 86.897% when pulling **0df4d084182c2c2662b777ee2c3b04a1c42bbc66 on PeterAlfreadLee:COMPRESS_477** into **28049d2f89a76c5a4845c12151a483ca7773fb6f on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (COMPRESS-477) Support for splitted zip files
[ https://issues.apache.org/jira/browse/COMPRESS-477?focusedWorklogId=354297&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-354297 ] ASF GitHub Bot logged work on COMPRESS-477: --- Author: ASF GitHub Bot Created on: 05/Dec/19 13:35 Start Date: 05/Dec/19 13:35 Worklog Time Spent: 10m Work Description: PeterAlfreadLee commented on issue #84: COMPRESS-477 Add support for extracting splitted zip files URL: https://github.com/apache/commons-compress/pull/84#issuecomment-562130678 Code just pushed. I have added a new parameter `skipSplitSig` in constructor of `ZipArchiveInputStream`. By default it's set to be false. I'm not sure if the naming and the default value are good or not. What do you think? @bodewig This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 354297) Time Spent: 10h 10m (was: 10h) > Support for splitted zip files > -- > > Key: COMPRESS-477 > URL: https://issues.apache.org/jira/browse/COMPRESS-477 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Affects Versions: 1.18 >Reporter: Luís Filipe Nassif >Priority: Major > Labels: zip > Fix For: 1.20 > > Time Spent: 10h 10m > Remaining Estimate: 0h > > It would be very useful to support splitted zip files. I've read > [https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT] and understood > that simply concatenating the segments and removing the split signature > 0x08074b50 from first segment would be sufficient, but it is not that simple > because compress fails with exception below: > {code} > Caused by: java.util.zip.ZipException: archive's ZIP64 end of central > directory locator is corrupt. > at > org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory64(ZipFile.java:924) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:901) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:621) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:295) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:280) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:236) > ~[commons-compress-1.18.jar:1.18] > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-compress] PeterAlfreadLee commented on issue #84: COMPRESS-477 Add support for extracting splitted zip files
PeterAlfreadLee commented on issue #84: COMPRESS-477 Add support for extracting splitted zip files URL: https://github.com/apache/commons-compress/pull/84#issuecomment-562130678 Code just pushed. I have added a new parameter `skipSplitSig` in constructor of `ZipArchiveInputStream`. By default it's set to be false. I'm not sure if the naming and the default value are good or not. What do you think? @bodewig This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (COMPRESS-477) Support for splitted zip files
[ https://issues.apache.org/jira/browse/COMPRESS-477?focusedWorklogId=354279&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-354279 ] ASF GitHub Bot logged work on COMPRESS-477: --- Author: ASF GitHub Bot Created on: 05/Dec/19 13:05 Start Date: 05/Dec/19 13:05 Worklog Time Spent: 10m Work Description: coveralls commented on issue #86: COMPRESS-477 building a split zip URL: https://github.com/apache/commons-compress/pull/86#issuecomment-552765671 [![Coverage Status](https://coveralls.io/builds/27434842/badge)](https://coveralls.io/builds/27434842) Coverage increased (+0.08%) to 86.799% when pulling **e61d22ee3549e9ac7379114d9e0a40d68b5dc600 on PeterAlfreadLee:COMPRESS-477-constructing** into **28049d2f89a76c5a4845c12151a483ca7773fb6f on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 354279) Time Spent: 10h (was: 9h 50m) > Support for splitted zip files > -- > > Key: COMPRESS-477 > URL: https://issues.apache.org/jira/browse/COMPRESS-477 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Affects Versions: 1.18 >Reporter: Luís Filipe Nassif >Priority: Major > Labels: zip > Fix For: 1.20 > > Time Spent: 10h > Remaining Estimate: 0h > > It would be very useful to support splitted zip files. I've read > [https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT] and understood > that simply concatenating the segments and removing the split signature > 0x08074b50 from first segment would be sufficient, but it is not that simple > because compress fails with exception below: > {code} > Caused by: java.util.zip.ZipException: archive's ZIP64 end of central > directory locator is corrupt. > at > org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory64(ZipFile.java:924) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:901) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:621) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:295) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:280) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:236) > ~[commons-compress-1.18.jar:1.18] > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-compress] coveralls edited a comment on issue #86: COMPRESS-477 building a split zip
coveralls edited a comment on issue #86: COMPRESS-477 building a split zip URL: https://github.com/apache/commons-compress/pull/86#issuecomment-552765671 [![Coverage Status](https://coveralls.io/builds/27434842/badge)](https://coveralls.io/builds/27434842) Coverage increased (+0.08%) to 86.799% when pulling **e61d22ee3549e9ac7379114d9e0a40d68b5dc600 on PeterAlfreadLee:COMPRESS-477-constructing** into **28049d2f89a76c5a4845c12151a483ca7773fb6f on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (COMPRESS-477) Support for splitted zip files
[ https://issues.apache.org/jira/browse/COMPRESS-477?focusedWorklogId=354278&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-354278 ] ASF GitHub Bot logged work on COMPRESS-477: --- Author: ASF GitHub Bot Created on: 05/Dec/19 13:02 Start Date: 05/Dec/19 13:02 Worklog Time Spent: 10m Work Description: PeterAlfreadLee commented on issue #86: COMPRESS-477 building a split zip URL: https://github.com/apache/commons-compress/pull/86#issuecomment-562119952 Code just pushed with all these reviews fixed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 354278) Time Spent: 9h 50m (was: 9h 40m) > Support for splitted zip files > -- > > Key: COMPRESS-477 > URL: https://issues.apache.org/jira/browse/COMPRESS-477 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Affects Versions: 1.18 >Reporter: Luís Filipe Nassif >Priority: Major > Labels: zip > Fix For: 1.20 > > Time Spent: 9h 50m > Remaining Estimate: 0h > > It would be very useful to support splitted zip files. I've read > [https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT] and understood > that simply concatenating the segments and removing the split signature > 0x08074b50 from first segment would be sufficient, but it is not that simple > because compress fails with exception below: > {code} > Caused by: java.util.zip.ZipException: archive's ZIP64 end of central > directory locator is corrupt. > at > org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory64(ZipFile.java:924) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:901) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:621) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:295) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:280) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:236) > ~[commons-compress-1.18.jar:1.18] > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-compress] PeterAlfreadLee commented on issue #86: COMPRESS-477 building a split zip
PeterAlfreadLee commented on issue #86: COMPRESS-477 building a split zip URL: https://github.com/apache/commons-compress/pull/86#issuecomment-562119952 Code just pushed with all these reviews fixed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (VALIDATOR-458) commons-beanutils version 1.9.2 is having vulnerabilities upgrade it to the latest one
[ https://issues.apache.org/jira/browse/VALIDATOR-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16988765#comment-16988765 ] Shunmuga Sundaram R commented on VALIDATOR-458: --- We are using commons-validator jar in our project and expecting a patch for this security fix from Apache team. It will be great if you can share the tentative release date for commons-validator with this security fix. > commons-beanutils version 1.9.2 is having vulnerabilities upgrade it to the > latest one > -- > > Key: VALIDATOR-458 > URL: https://issues.apache.org/jira/browse/VALIDATOR-458 > Project: Commons Validator > Issue Type: Bug >Reporter: Shubhankar Singh >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (COMPRESS-477) Support for splitted zip files
[ https://issues.apache.org/jira/browse/COMPRESS-477?focusedWorklogId=354152&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-354152 ] ASF GitHub Bot logged work on COMPRESS-477: --- Author: ASF GitHub Bot Created on: 05/Dec/19 09:18 Start Date: 05/Dec/19 09:18 Worklog Time Spent: 10m Work Description: bodewig commented on pull request #86: COMPRESS-477 building a split zip URL: https://github.com/apache/commons-compress/pull/86#discussion_r354186221 ## File path: src/main/java/org/apache/commons/compress/archivers/zip/ZipSplitOutputStream.java ## @@ -0,0 +1,236 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + * + */ +package org.apache.commons.compress.archivers.zip; + +import org.apache.commons.compress.compressors.FileNameUtil; + +import java.io.*; +import java.nio.ByteBuffer; + +public class ZipSplitOutputStream extends OutputStream { +private OutputStream outputStream; +private File zipFile; +private long splitSize; +private int currentSplitSegmentIndex = 0; +private long currentSplitSegmentBytesWritten = 0; +private boolean finished = false; + +/** + * 8.5.1 Capacities for split archives are as follows: + * + * Maximum number of segments = 4,294,967,295 - 1 + * Maximum .ZIP segment size = 4,294,967,295 bytes (refer to section 8.5.6) + * Minimum segment size = 64K + * Maximum PKSFX segment size = 2,147,483,647 bytes + */ +private final long ZIP_SEGMENT_MIN_SIZE = 64 * 1024L; +private final long ZIP_SEGMENT_MAX_SIZE = 4294967295L; + +/** + * Create a split zip. If the zip file is smaller than the split size, + * then there will only be one split zip, and its suffix is .zip, + * otherwise the split segments should be like .z01, .z02, ... .z(N-1), .zip + * + * @param zipFile the zip file to write to + * @param splitSize the split size + */ +public ZipSplitOutputStream(final File zipFile, final long splitSize) throws IllegalArgumentException, IOException { +if (splitSize < ZIP_SEGMENT_MIN_SIZE || splitSize > ZIP_SEGMENT_MAX_SIZE) { +throw new IllegalArgumentException("zip split segment size should between 64K and 4,294,967,295"); +} + +this.zipFile = zipFile; +this.splitSize = splitSize; + +this.outputStream = new FileOutputStream(zipFile); +// write the zip split signature 0x08074B50 to the zip file +writeZipSplitSignature(); +} + +/** + * Some data can not be written to different split segments, for example: + * + * 4.4.1.5 The end of central directory record and the Zip64 end + * of central directory locator record MUST reside on the same + * disk when splitting or spanning an archive. + * + * @param unsplittableContentSize + * @throws IllegalArgumentException + * @throws IOException + */ +public void prepareToWriteUnsplittableContent(long unsplittableContentSize) throws IllegalArgumentException, IOException { +if (unsplittableContentSize > this.splitSize) { +throw new IllegalArgumentException("The unsplittable content size is bigger than the split segment size"); +} + +long bytesRemainingInThisSegment = this.splitSize - this.currentSplitSegmentBytesWritten; +if (bytesRemainingInThisSegment < unsplittableContentSize) { +openNewSplitSegment(); +} +} + +@Override +public void write(int i) throws IOException { +byte[] b = ByteBuffer.allocate(4).putInt(i).array(); Review comment: no worries, that's what a second pair of eyes is good for. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 354152) Time Spent: 9h 40m (was: 9.5h) > Supp
[GitHub] [commons-compress] bodewig commented on a change in pull request #86: COMPRESS-477 building a split zip
bodewig commented on a change in pull request #86: COMPRESS-477 building a split zip URL: https://github.com/apache/commons-compress/pull/86#discussion_r354186221 ## File path: src/main/java/org/apache/commons/compress/archivers/zip/ZipSplitOutputStream.java ## @@ -0,0 +1,236 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + * + */ +package org.apache.commons.compress.archivers.zip; + +import org.apache.commons.compress.compressors.FileNameUtil; + +import java.io.*; +import java.nio.ByteBuffer; + +public class ZipSplitOutputStream extends OutputStream { +private OutputStream outputStream; +private File zipFile; +private long splitSize; +private int currentSplitSegmentIndex = 0; +private long currentSplitSegmentBytesWritten = 0; +private boolean finished = false; + +/** + * 8.5.1 Capacities for split archives are as follows: + * + * Maximum number of segments = 4,294,967,295 - 1 + * Maximum .ZIP segment size = 4,294,967,295 bytes (refer to section 8.5.6) + * Minimum segment size = 64K + * Maximum PKSFX segment size = 2,147,483,647 bytes + */ +private final long ZIP_SEGMENT_MIN_SIZE = 64 * 1024L; +private final long ZIP_SEGMENT_MAX_SIZE = 4294967295L; + +/** + * Create a split zip. If the zip file is smaller than the split size, + * then there will only be one split zip, and its suffix is .zip, + * otherwise the split segments should be like .z01, .z02, ... .z(N-1), .zip + * + * @param zipFile the zip file to write to + * @param splitSize the split size + */ +public ZipSplitOutputStream(final File zipFile, final long splitSize) throws IllegalArgumentException, IOException { +if (splitSize < ZIP_SEGMENT_MIN_SIZE || splitSize > ZIP_SEGMENT_MAX_SIZE) { +throw new IllegalArgumentException("zip split segment size should between 64K and 4,294,967,295"); +} + +this.zipFile = zipFile; +this.splitSize = splitSize; + +this.outputStream = new FileOutputStream(zipFile); +// write the zip split signature 0x08074B50 to the zip file +writeZipSplitSignature(); +} + +/** + * Some data can not be written to different split segments, for example: + * + * 4.4.1.5 The end of central directory record and the Zip64 end + * of central directory locator record MUST reside on the same + * disk when splitting or spanning an archive. + * + * @param unsplittableContentSize + * @throws IllegalArgumentException + * @throws IOException + */ +public void prepareToWriteUnsplittableContent(long unsplittableContentSize) throws IllegalArgumentException, IOException { +if (unsplittableContentSize > this.splitSize) { +throw new IllegalArgumentException("The unsplittable content size is bigger than the split segment size"); +} + +long bytesRemainingInThisSegment = this.splitSize - this.currentSplitSegmentBytesWritten; +if (bytesRemainingInThisSegment < unsplittableContentSize) { +openNewSplitSegment(); +} +} + +@Override +public void write(int i) throws IOException { +byte[] b = ByteBuffer.allocate(4).putInt(i).array(); Review comment: no worries, that's what a second pair of eyes is good for. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (COMPRESS-477) Support for splitted zip files
[ https://issues.apache.org/jira/browse/COMPRESS-477?focusedWorklogId=354151&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-354151 ] ASF GitHub Bot logged work on COMPRESS-477: --- Author: ASF GitHub Bot Created on: 05/Dec/19 09:17 Start Date: 05/Dec/19 09:17 Worklog Time Spent: 10m Work Description: bodewig commented on pull request #84: COMPRESS-477 Add support for extracting splitted zip files URL: https://github.com/apache/commons-compress/pull/84#discussion_r354185631 ## File path: src/main/java/org/apache/commons/compress/archivers/zip/ZipArchiveInputStream.java ## @@ -367,13 +367,9 @@ public ZipArchiveEntry getNextZipEntry() throws IOException { private void readFirstLocalFileHeader(final byte[] lfh) throws IOException { readFully(lfh); final ZipLong sig = new ZipLong(lfh); -if (sig.equals(ZipLong.DD_SIG)) { Review comment: Yes, that's what I meant to say. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 354151) Time Spent: 9.5h (was: 9h 20m) > Support for splitted zip files > -- > > Key: COMPRESS-477 > URL: https://issues.apache.org/jira/browse/COMPRESS-477 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Affects Versions: 1.18 >Reporter: Luís Filipe Nassif >Priority: Major > Labels: zip > Fix For: 1.20 > > Time Spent: 9.5h > Remaining Estimate: 0h > > It would be very useful to support splitted zip files. I've read > [https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT] and understood > that simply concatenating the segments and removing the split signature > 0x08074b50 from first segment would be sufficient, but it is not that simple > because compress fails with exception below: > {code} > Caused by: java.util.zip.ZipException: archive's ZIP64 end of central > directory locator is corrupt. > at > org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory64(ZipFile.java:924) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:901) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:621) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:295) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:280) > ~[commons-compress-1.18.jar:1.18] > at > org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:236) > ~[commons-compress-1.18.jar:1.18] > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-compress] bodewig commented on a change in pull request #84: COMPRESS-477 Add support for extracting splitted zip files
bodewig commented on a change in pull request #84: COMPRESS-477 Add support for extracting splitted zip files URL: https://github.com/apache/commons-compress/pull/84#discussion_r354185631 ## File path: src/main/java/org/apache/commons/compress/archivers/zip/ZipArchiveInputStream.java ## @@ -367,13 +367,9 @@ public ZipArchiveEntry getNextZipEntry() throws IOException { private void readFirstLocalFileHeader(final byte[] lfh) throws IOException { readFully(lfh); final ZipLong sig = new ZipLong(lfh); -if (sig.equals(ZipLong.DD_SIG)) { Review comment: Yes, that's what I meant to say. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services