[jira] [Work logged] (LANG-1177) Improve indexOf performance when called multiple times

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/LANG-1177?focusedWorklogId=330872=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-330872
 ]

ASF GitHub Bot logged work on LANG-1177:


Author: ASF GitHub Bot
Created on: 19/Oct/19 03:18
Start Date: 19/Oct/19 03:18
Worklog Time Spent: 10m 
  Work Description: Stzx commented on pull request #471: [LANG-1177] Added 
indexesOf methods and simplified removeAllOccurences
URL: https://github.com/apache/commons-lang/pull/471#discussion_r336720026
 
 

 ##
 File path: src/main/java/org/apache/commons/lang3/ArrayUtils.java
 ##
 @@ -3254,6 +3254,57 @@ public static int indexOf(final Object[] array, final 
Object objectToFind, int s
 return INDEX_NOT_FOUND;
 }
 
+/**
+ * Finds the indices of the given object in the array.
+ *
+ * This method returns an empty BitSet for a {@code null} input array.
+ *
+ * @param array  the array to search through for the object, may be {@code 
null}
+ * @param objectToFind  the object to find, may be {@code null}
+ * @return a BitSet of all the indices of the object within the array,
+ *  an empty BitSet if not found or {@code null} array input
 
 Review comment:
   `@since` tag should be provided for newly provided methods.
 

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: 330872)
Time Spent: 0.5h  (was: 20m)

> Improve indexOf performance when called multiple times
> --
>
> Key: LANG-1177
> URL: https://issues.apache.org/jira/browse/LANG-1177
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Sebb
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The indexOf methods search for a single entry in an array.
> This works fine when only the first matching entry is needed, however it is 
> not so efficient when all matches are needed (because of the setup/teardown 
> overheads).
> It might be useful to introduce an indexesOf method that returns a BitSet 
> containing all the matches.
> This can then be used in the removeAllOccurrences methods.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-lang] Stzx commented on a change in pull request #471: [LANG-1177] Added indexesOf methods and simplified removeAllOccurences

[GitBox]

Stzx commented on a change in pull request #471: [LANG-1177] Added indexesOf 
methods and simplified removeAllOccurences
URL: https://github.com/apache/commons-lang/pull/471#discussion_r336720026
 
 

 ##
 File path: src/main/java/org/apache/commons/lang3/ArrayUtils.java
 ##
 @@ -3254,6 +3254,57 @@ public static int indexOf(final Object[] array, final 
Object objectToFind, int s
 return INDEX_NOT_FOUND;
 }
 
+/**
+ * Finds the indices of the given object in the array.
+ *
+ * This method returns an empty BitSet for a {@code null} input array.
+ *
+ * @param array  the array to search through for the object, may be {@code 
null}
+ * @param objectToFind  the object to find, may be {@code null}
+ * @return a BitSet of all the indices of the object within the array,
+ *  an empty BitSet if not found or {@code null} array input
 
 Review comment:
   `@since` tag should be provided for newly provided methods.


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] [Updated] (COLLECTIONS-728) BloomFilter contribution

[Gilles Sadowski (Jira)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gilles Sadowski updated COLLECTIONS-728:

Attachment: BloomFilter.java

> BloomFilter contribution
> 
>
> Key: COLLECTIONS-728
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-728
> Project: Commons Collections
>  Issue Type: Task
>Reporter: Claude Warren
>Priority: Minor
> Attachments: BloomFilter.java
>
>
> Contribution of BloomFilter library comprising base implementation and gated 
> collections.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (LANG-1494) Add org.apache.commons.lang3.time.CalendarUtils

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LANG-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory resolved LANG-1494.
---
Fix Version/s: 3.10
   Resolution: Fixed

In git master.

> Add org.apache.commons.lang3.time.CalendarUtils
> ---
>
> Key: LANG-1494
> URL: https://issues.apache.org/jira/browse/LANG-1494
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 3.10
>
>
> Add {{org.apache.commons.lang3.time.CalendarUtils}} to provide util methods 
> and wrap a {{Calendar}} to provide shortcuts. Right now, there are only a 
> handful of methods.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (LANG-1494) Add org.apache.commons.lang3.time.CalendarUtils

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LANG-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LANG-1494:
--
Description: Add {{org.apache.commons.lang3.time.CalendarUtils}} to provide 
util methods and wrap a {{Calendar}} to provide shortcuts. Right now, there are 
only a handful of methods.  (was: Add org.apache.commons.lang3.time.Calendars 
to provide util methods and wrap a Calendar and provide shortcuts. Right now, 
there are only a handful of methods.)

> Add org.apache.commons.lang3.time.CalendarUtils
> ---
>
> Key: LANG-1494
> URL: https://issues.apache.org/jira/browse/LANG-1494
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
>
> Add {{org.apache.commons.lang3.time.CalendarUtils}} to provide util methods 
> and wrap a {{Calendar}} to provide shortcuts. Right now, there are only a 
> handful of methods.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (LANG-1494) Add org.apache.commons.lang3.time.CalendarUtils

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/LANG-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated LANG-1494:
--
Summary: Add org.apache.commons.lang3.time.CalendarUtils  (was: Add 
org.apache.commons.lang3.time.Calendars)

> Add org.apache.commons.lang3.time.CalendarUtils
> ---
>
> Key: LANG-1494
> URL: https://issues.apache.org/jira/browse/LANG-1494
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.time.*
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
>
> Add org.apache.commons.lang3.time.Calendars to provide util methods and wrap 
> a Calendar and provide shortcuts. Right now, there are only a handful of 
> methods.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (LANG-1494) Add org.apache.commons.lang3.time.Calendars

[Gary D. Gregory (Jira)]

Gary D. Gregory created LANG-1494:
-

 Summary: Add org.apache.commons.lang3.time.Calendars
 Key: LANG-1494
 URL: https://issues.apache.org/jira/browse/LANG-1494
 Project: Commons Lang
  Issue Type: New Feature
  Components: lang.time.*
Reporter: Gary D. Gregory
Assignee: Gary D. Gregory


Add org.apache.commons.lang3.time.Calendars to provide util methods and wrap a 
Calendar and provide shortcuts. Right now, there are only a handful of methods.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CLI-298) Define CLI options via configuration file

[Richard (Jira)]

[ 
https://issues.apache.org/jira/browse/CLI-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954507#comment-16954507
 ] 

Richard commented on CLI-298:
-

I forgot to metion - without having to do anything else, running -h produces:
{code:java}
usage: md5-check
Print the MD5 of the specified file, checking if it is equal to the
specified MD5 string.
 -d,--directoryDirectory to scan.
 -f,--fileCommand line configuration file to parse.
 -h,--help  Print this help then quit.
 -m,--md5  MD5 to test against the file.
 -p,--port Port number.
Copyright 2019 Apache Software Foundation.
 {code}

> Define CLI options via configuration file
> -
>
> Key: CLI-298
> URL: https://issues.apache.org/jira/browse/CLI-298
> Project: Commons CLI
>  Issue Type: Improvement
>  Components: Options definition
>Affects Versions: 1.5, Nightly Builds
>Reporter: Richard
>Priority: Minor
>  Labels: newbie, pull-request-available, ready-to-commit
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Create a configuration that enables users to define CLI options via a 
> configuration file. Such configuration would normally pre-defined and bundled 
> inside the executable jar running the application. This would reduce the 
> amount of code required to define command line options and introduce the 
> ability to do a lot of the checking a user does (such as converting values to 
> integers, files, checking if integers are above/below a certain amount, 
> checking that files or directories do/don't exist etc.) For security 
> purposes, at compile time calculate an MD5 for the application, if this 
> doesn't match at runtime warn of corrupted file exception. Also add I18N 
> since this will be driven via the user experience for exception messages.
> So far I've catered for basic options that utilise strings.
> Code already started with a pull request at 
> [https://github.com/zendawg/commons-cli] underneath the branch named 
> "cli-configuration".
> Apologies in advance, never contributed to Apache SWF before.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (CLI-298) Define CLI options via configuration file

[Richard (Jira)]

[ 
https://issues.apache.org/jira/browse/CLI-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954502#comment-16954502
 ] 

Richard edited comment on CLI-298 at 10/18/19 11:07 AM:


Dear Apaches,

I am continuing work on this project and it's bearing some sweet, sweet fruit 
for myself.

However, the overall impression is that you're not overly keen on accepting my 
changes for the reasons you've specified. In which case, I am beginning to 
think I should fork off (pun intended) and create my own project for this 
purpose. Please let me know if you think that I should do this.

Otherwise, here's the latest examples of the changes I've made.

Data types are now catered for - at the moment, integers, floats, string 
(matching), files. Some examples:
{code:java|title=Bad String Match|borderStyle=solid}
option.md5.opts=m/md5
option.md5.hasArg=true
option.md5.properties=match=[a-zA-Z0-9]+
option.md5.description=MD5 to test against the file.
{code}
Running this with -m produces:
{code:java}
my-command -m bad-md5_value
Error: option m: Data 'bad-md5_value' is an invalid format.
{code}
{code:java|title=Show File Errors|borderStyle=solid}
option.file.opts=f/file
option.file.hasArg=true
option.file.argName=file
option.file.type=file
option.file.properties=file
option.file.description=Command line configuration file to parse.
{code}
Running this with -f produces:
{code:java}
my-command -f /tmp
Error: option f: Specified file /tmp is a directory (expected file).
my-command -f foo.bar.baz
Error: option f: Specified file foo.bar.baz does not exist.
{code}
We can change the above properties to !exists:
{code:java|title=File Must Not Exist|borderStyle=solid}
option.file.properties=!exists
{code}
... to get:
{code:java}
my-command -f pom.xml
Error: option f: Specified file pom.xml already exists.
{code}
An integer example:
{code:java|title=Integer-based Errors|borderStyle=solid}
option.port.opts=p/port
option.port.hasArg=true
option.port.type=int
option.port.properties=min=80,max=8080
option.port.description=Port number.
{code}
Example:
{code:java}
my-command -p 40
Error: option p: 40 is less than specified minimum: 80
{code}
In all cases, the value updated to the listener is the type specified by the 
configuration - so a java.lang.Integer, String, java.io.File etc.

Some of our tools work like git in that they take the form "command sub-command 
[options]. I'll definitely be updating the configuration to take sub-commands 
that each have their own options. In fact there's many things I'd like to 
incorporate, but I guess that's for another time.

I appreciate the feedback you've given and thanks for your time. If I don't 
hear from you within a week, thanks for your time and I'll be on my merry way.

Hoka Hey!

(OK so I know that's Lakota, but it's the only plains Indian I know...)


was (Author: zendawg):
Dear Apaches,

I am continuing work on this project and it's bearing some sweet, sweet fruit 
for myself.

However, the overall impression is that you're not overly keen on accepting my 
changes for the reasons you've specified. In which case, I am beginning to 
think I should fork off (pun intended) and create my own project for this 
purpose. Please let me know if you think that I should do this.

Otherwise, here's the latest examples of the changes I've made.

Data types are now catered for - at the moment, integers, floats, string 
(matching), files. Some examples:
{code:java|title=Bad String Match|borderStyle=solid}
option.md5.opts=m/md5
option.md5.hasArg=true
option.md5.properties=match=[a-zA-Z0-9]+
option.md5.description=MD5 to test against the file.
{code}
Running this with -m produces:
{code:java}
my-command -m bad-md5_value
Error: option m: Data 'bad-md5_value' is an invalid format.
{code}
{code:java|title=Show File Errors|borderStyle=solid}
option.file.opts=f/file
option.file.hasArg=true
option.file.argName=file
option.file.type=file
option.file.properties=file
option.file.description=Command line configuration file to parse.
{code}
Running this with -f produces:
{code:java}
my-command -f /tmp
Error: option f: Specified file /tmp is a directory (expected file).
my-command -f foo.bar.baz
Error: option f: Specified file foo.bar.baz does not exist.
{code}
We can change the above properties to !exists:
{code:java|title=File Must Not Exist|borderStyle=solid}
option.file.properties=!exists
{code}
... to get:
{code:java}
my-command -f pom.xml
Error: option f: Specified file pom.xml already exists.
{code}
An integer example:
{code:java|title=Integer-based Errors|borderStyle=solid}
option.port.opts=p/port
option.port.hasArg=true
option.port.type=int
option.port.properties=min=80,max=8080
option.port.description=Port number.
{code}
Example:
{code:java}
my-command -f pom.xml
Error: option p: 40 is less than specified minimum: 80
{code}
In all cases, the value updated to the listener is the type specified by the 
configuration - so 

[jira] [Commented] (CLI-298) Define CLI options via configuration file

[Richard (Jira)]

[ 
https://issues.apache.org/jira/browse/CLI-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954502#comment-16954502
 ] 

Richard commented on CLI-298:
-

Dear Apaches,

I am continuing work on this project and it's bearing some sweet, sweet fruit 
for myself.

However, the overall impression is that you're not overly keen on accepting my 
changes for the reasons you've specified. In which case, I am beginning to 
think I should fork off (pun intended) and create my own project for this 
purpose. Please let me know if you think that I should do this.

Otherwise, here's the latest examples of the changes I've made.

Data types are now catered for - at the moment, integers, floats, string 
(matching), files. Some examples:
{code:java|title=Bad String Match|borderStyle=solid}
option.md5.opts=m/md5
option.md5.hasArg=true
option.md5.properties=match=[a-zA-Z0-9]+
option.md5.description=MD5 to test against the file.
{code}
Running this with -m produces:
{code:java}
my-command -m bad-md5_value
Error: option m: Data 'bad-md5_value' is an invalid format.
{code}
{code:java|title=Show File Errors|borderStyle=solid}
option.file.opts=f/file
option.file.hasArg=true
option.file.argName=file
option.file.type=file
option.file.properties=file
option.file.description=Command line configuration file to parse.
{code}
Running this with -f produces:
{code:java}
my-command -f /tmp
Error: option f: Specified file /tmp is a directory (expected file).
my-command -f foo.bar.baz
Error: option f: Specified file foo.bar.baz does not exist.
{code}
We can change the above properties to !exists:
{code:java|title=File Must Not Exist|borderStyle=solid}
option.file.properties=!exists
{code}
... to get:
{code:java}
my-command -f pom.xml
Error: option f: Specified file pom.xml already exists.
{code}
An integer example:
{code:java|title=Integer-based Errors|borderStyle=solid}
option.port.opts=p/port
option.port.hasArg=true
option.port.type=int
option.port.properties=min=80,max=8080
option.port.description=Port number.
{code}
Example:
{code:java}
my-command -f pom.xml
Error: option p: 40 is less than specified minimum: 80
{code}
In all cases, the value updated to the listener is the type specified by the 
configuration - so a java.lang.Integer, String, java.io.File etc.

Some of our tools work like git in that they take the form "command sub-command 
[options]. I'll definitely be updating the configuration to take sub-commands 
that each have their own options. In fact there's many things I'd like to 
incorporate, but I guess that's for another time.

I appreciate the feedback you've given and thanks for your time. If I don't 
hear from you within a week, thanks for your time and I'll be on my merry way.

Hoka Hey!

(OK so I know that's Lakota, but it's the only plains Indian I know...)

> Define CLI options via configuration file
> -
>
> Key: CLI-298
> URL: https://issues.apache.org/jira/browse/CLI-298
> Project: Commons CLI
>  Issue Type: Improvement
>  Components: Options definition
>Affects Versions: 1.5, Nightly Builds
>Reporter: Richard
>Priority: Minor
>  Labels: newbie, pull-request-available, ready-to-commit
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> Create a configuration that enables users to define CLI options via a 
> configuration file. Such configuration would normally pre-defined and bundled 
> inside the executable jar running the application. This would reduce the 
> amount of code required to define command line options and introduce the 
> ability to do a lot of the checking a user does (such as converting values to 
> integers, files, checking if integers are above/below a certain amount, 
> checking that files or directories do/don't exist etc.) For security 
> purposes, at compile time calculate an MD5 for the application, if this 
> doesn't match at runtime warn of corrupted file exception. Also add I18N 
> since this will be driven via the user experience for exception messages.
> So far I've catered for basic options that utilise strings.
> Code already started with a pull request at 
> [https://github.com/zendawg/commons-cli] underneath the branch named 
> "cli-configuration".
> Apologies in advance, never contributed to Apache SWF before.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (COMPRESS-496) SevenZFile.read got an exception when extracting empty file

[Stefan Bodewig (Jira)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954480#comment-16954480
 ] 

Stefan Bodewig commented on COMPRESS-496:
-

This probably doesn't happen for all empty files as we've added a test case for 
one version of it for COMPRESS-348

It likely depends on whether the archive says there is a stream at all (albeit 
empty) or not. Can you provide us with an example archive, where extracting 
fails?

I agree there is something wrong, but would expect a problem for the entry 
after the empty one and would prefer to fix the issue with the help of a real 
test case :)

> SevenZFile.read got an exception when extracting empty file
> ---
>
> Key: COMPRESS-496
> URL: https://issues.apache.org/jira/browse/COMPRESS-496
> Project: Commons Compress
>  Issue Type: Bug
>Reporter: yiang li
>Priority: Minor
>
> When extracting an empty file in SevenZFile, an exception will be thrown. 
> This is because the `deferredBlockStreams` in SevenZFile was clear here
> {code:java}
> if (folderIndex < 0) {
>  deferredBlockStreams.clear();
>  // TODO: previously it'd return an empty stream?
>  // new BoundedInputStream(new ByteArrayInputStream(new byte[0]), 0);
>  return;
> }{code}
> Maybe an empty stream should be added to deferredBlockStreams here as the 
> TODO said?
>  
> Code to reproduce the exception
> {code:java}
> byte[] buffer = new byte[4096];
>  String destination = "/output/dir/of/7z";
>  SevenZFile sevenZFile = new SevenZFile(new File("/file/to/extract.7z"));
>  SevenZArchiveEntry entry;
>  while ((entry = sevenZFile.getNextEntry()) != null){
>  if (entry.isDirectory())
> { continue; }
> File curfile = new File(destination, entry.getName());
>  File parent = curfile.getParentFile();
>  if (!parent.exists())
> { parent.mkdirs(); }
> FileOutputStream out = new FileOutputStream(curfile);
> while(sevenZFile.read(buffer, 0, buffer.length) > 0)
> { out.write(buffer); out.close(); }
> }
> {code}
> BTW it's OK with the sample code in user guide of commons-compress because 
> the sample code is using entry's size as the size of the buffer, which is 0. 
> But in most cases, we need to reuse the buffer instead of creating it each 
> time I need it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (VFS-686) Upgrade Jackrabbit dependency to the latest 2.x

[Woonsan Ko (Jira)]

[ 
https://issues.apache.org/jira/browse/VFS-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954459#comment-16954459
 ] 

Woonsan Ko commented on VFS-686:


It seems working fine after building/running from master branch.
I've followed [1] to test run webdav3 and webdav4 providers after running 
Jackrabbit Standalone server [2], which provides WebDAV server as well, locally.

Thank you very much!

Woonsan

[1] 
https://github.com/apache/commons-vfs/blob/master/commons-vfs2-examples/README.md#example-test-scenario-with-webdav3
[2] http://jackrabbit.apache.org/jcr/standalone-server.html

> Upgrade Jackrabbit dependency to the latest 2.x
> ---
>
> Key: VFS-686
> URL: https://issues.apache.org/jira/browse/VFS-686
> Project: Commons VFS
>  Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Woonsan Ko
>Priority: Major
>  Labels: pull-request-available
> Fix For: 2.5.0
>
> Attachments: feature-VFS-686-2.patch, feature-VFS-686-3.patch, 
> feature-VFS-686-4.patch, feature-VFS-686-5.patch, feature-VFS-686-6.patch, 
> feature-VFS-686.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The current dependency, Jackrabbit 1.6.5, still depends on HttpClient 3.x, 
> while Jackrabbit 2.x depends on HttpClient 4.x.
> So, WebDAV file system provider should use the latest stable version of 
> Jackrabbit 2.x.
> As of VFS-360, it is possible to let the WebDAV file system use 
> HttpComponents 4.x.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (VFS-686) Upgrade Jackrabbit dependency to the latest 2.x

[Woonsan Ko (Jira)]

 [ 
https://issues.apache.org/jira/browse/VFS-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Woonsan Ko closed VFS-686.
--

> Upgrade Jackrabbit dependency to the latest 2.x
> ---
>
> Key: VFS-686
> URL: https://issues.apache.org/jira/browse/VFS-686
> Project: Commons VFS
>  Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Woonsan Ko
>Priority: Major
>  Labels: pull-request-available
> Fix For: 2.5.0
>
> Attachments: feature-VFS-686-2.patch, feature-VFS-686-3.patch, 
> feature-VFS-686-4.patch, feature-VFS-686-5.patch, feature-VFS-686-6.patch, 
> feature-VFS-686.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The current dependency, Jackrabbit 1.6.5, still depends on HttpClient 3.x, 
> while Jackrabbit 2.x depends on HttpClient 4.x.
> So, WebDAV file system provider should use the latest stable version of 
> Jackrabbit 2.x.
> As of VFS-360, it is possible to let the WebDAV file system use 
> HttpComponents 4.x.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (COMPRESS-496) SevenZFile.read got an exception when extracting empty file

[yiang li (Jira)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yiang li updated COMPRESS-496:
--
Description: 
When extracting an empty file in SevenZFile, an exception will be thrown. This 
is because the `deferredBlockStreams` in SevenZFile was clear here
{code:java}
if (folderIndex < 0) {
 deferredBlockStreams.clear();
 // TODO: previously it'd return an empty stream?
 // new BoundedInputStream(new ByteArrayInputStream(new byte[0]), 0);
 return;
}{code}
Maybe an empty stream should be added to deferredBlockStreams here as the TODO 
said?

 

Code to reproduce the exception
{code:java}
byte[] buffer = new byte[4096];
 String destination = "/output/dir/of/7z";
 SevenZFile sevenZFile = new SevenZFile(new File("/file/to/extract.7z"));
 SevenZArchiveEntry entry;
 while ((entry = sevenZFile.getNextEntry()) != null){
 if (entry.isDirectory())
{ continue; }
File curfile = new File(destination, entry.getName());
 File parent = curfile.getParentFile();
 if (!parent.exists())
{ parent.mkdirs(); }
FileOutputStream out = new FileOutputStream(curfile);
while(sevenZFile.read(buffer, 0, buffer.length) > 0)
{ out.write(buffer); out.close(); }
}
{code}
BTW it's OK with the sample code in user guide of commons-compress because the 
sample code is using entry's size as the size of the buffer, which is 0. But in 
most cases, we need to reuse the buffer instead of creating it each time I need 
it.

  was:
When extracting an empty file in SevenZFile, an exception will be thrown. This 
is because the `deferredBlockStreams` in SevenZFile was clear here
{code:java}
if (folderIndex < 0) {
 deferredBlockStreams.clear();
 // TODO: previously it'd return an empty stream?
 // new BoundedInputStream(new ByteArrayInputStream(new byte[0]), 0);
 return;
}{code}
Maybe an empty stream should be added to deferredBlockStreams here as the TODO 
said?

 

Code to reproduce the exception
{code:java}
byte[] buffer = new byte[4096];
 String destination = "/output/dir/of/7z";
 SevenZFile sevenZFile = new SevenZFile(new File("/file/to/extract.7z"));
 SevenZArchiveEntry entry;
 while ((entry = sevenZFile.getNextEntry()) != null){
 if (entry.isDirectory())
{ continue; }
File curfile = new File(destination, entry.getName());
 File parent = curfile.getParentFile();
 if (!parent.exists())
{ parent.mkdirs(); }
FileOutputStream out = new FileOutputStream(curfile);
while(sevenZFile.read(buffer, 0, buffer.length) > 0)
{ out.write(buffer); out.close(); }
}
{code}


> SevenZFile.read got an exception when extracting empty file
> ---
>
> Key: COMPRESS-496
> URL: https://issues.apache.org/jira/browse/COMPRESS-496
> Project: Commons Compress
>  Issue Type: Bug
>Reporter: yiang li
>Priority: Minor
>
> When extracting an empty file in SevenZFile, an exception will be thrown. 
> This is because the `deferredBlockStreams` in SevenZFile was clear here
> {code:java}
> if (folderIndex < 0) {
>  deferredBlockStreams.clear();
>  // TODO: previously it'd return an empty stream?
>  // new BoundedInputStream(new ByteArrayInputStream(new byte[0]), 0);
>  return;
> }{code}
> Maybe an empty stream should be added to deferredBlockStreams here as the 
> TODO said?
>  
> Code to reproduce the exception
> {code:java}
> byte[] buffer = new byte[4096];
>  String destination = "/output/dir/of/7z";
>  SevenZFile sevenZFile = new SevenZFile(new File("/file/to/extract.7z"));
>  SevenZArchiveEntry entry;
>  while ((entry = sevenZFile.getNextEntry()) != null){
>  if (entry.isDirectory())
> { continue; }
> File curfile = new File(destination, entry.getName());
>  File parent = curfile.getParentFile();
>  if (!parent.exists())
> { parent.mkdirs(); }
> FileOutputStream out = new FileOutputStream(curfile);
> while(sevenZFile.read(buffer, 0, buffer.length) > 0)
> { out.write(buffer); out.close(); }
> }
> {code}
> BTW it's OK with the sample code in user guide of commons-compress because 
> the sample code is using entry's size as the size of the buffer, which is 0. 
> But in most cases, we need to reuse the buffer instead of creating it each 
> time I need it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (COMPRESS-496) SevenZFile.read got an exception when extracting empty file

[yiang li (Jira)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yiang li updated COMPRESS-496:
--
Description: 
When extracting an empty file in SevenZFile, an exception will be thrown. This 
is because the `deferredBlockStreams` in SevenZFile was clear here
{code:java}
if (folderIndex < 0) {
 deferredBlockStreams.clear();
 // TODO: previously it'd return an empty stream?
 // new BoundedInputStream(new ByteArrayInputStream(new byte[0]), 0);
 return;
}{code}
Maybe an empty stream should be added to deferredBlockStreams here as the TODO 
said?

 

Code to reproduce the exception
{code:java}
byte[] buffer = new byte[4096];
 String destination = "/output/dir/of/7z";
 SevenZFile sevenZFile = new SevenZFile(new File("/file/to/extract.7z"));
 SevenZArchiveEntry entry;
 while ((entry = sevenZFile.getNextEntry()) != null){
 if (entry.isDirectory())
{ continue; }
File curfile = new File(destination, entry.getName());
 File parent = curfile.getParentFile();
 if (!parent.exists())
{ parent.mkdirs(); }
FileOutputStream out = new FileOutputStream(curfile);
while(sevenZFile.read(buffer, 0, buffer.length) > 0)
{ out.write(buffer); out.close(); }
}
{code}

  was:
When extracting an empty file in SevenZFile, an exception will be thrown. This 
is because the `deferredBlockStreams` in SevenZFile was clear here

 
{code:java}
if (folderIndex < 0) {
 deferredBlockStreams.clear();
 // TODO: previously it'd return an empty stream?
 // new BoundedInputStream(new ByteArrayInputStream(new byte[0]), 0);
 return;
}{code}
Maybe an empty stream should be added to deferredBlockStreams here as the TODO 
said?

 

Code to reproduce the exception
{code:java}
byte[] buffer = new byte[4096];
 String destination = "/output/dir/of/7z";
 SevenZFile sevenZFile = new SevenZFile(new File("/file/to/extract.7z"));
 SevenZArchiveEntry entry;
 while ((entry = sevenZFile.getNextEntry()) != null){
 if (entry.isDirectory())
{ continue; }
File curfile = new File(destination, entry.getName());
 File parent = curfile.getParentFile();
 if (!parent.exists())
{ parent.mkdirs(); }
FileOutputStream out = new FileOutputStream(curfile);
while(sevenZFile.read(buffer, 0, buffer.length) > 0)
{ out.write(buffer); out.close(); }
}
{code}


> SevenZFile.read got an exception when extracting empty file
> ---
>
> Key: COMPRESS-496
> URL: https://issues.apache.org/jira/browse/COMPRESS-496
> Project: Commons Compress
>  Issue Type: Bug
>Reporter: yiang li
>Priority: Minor
>
> When extracting an empty file in SevenZFile, an exception will be thrown. 
> This is because the `deferredBlockStreams` in SevenZFile was clear here
> {code:java}
> if (folderIndex < 0) {
>  deferredBlockStreams.clear();
>  // TODO: previously it'd return an empty stream?
>  // new BoundedInputStream(new ByteArrayInputStream(new byte[0]), 0);
>  return;
> }{code}
> Maybe an empty stream should be added to deferredBlockStreams here as the 
> TODO said?
>  
> Code to reproduce the exception
> {code:java}
> byte[] buffer = new byte[4096];
>  String destination = "/output/dir/of/7z";
>  SevenZFile sevenZFile = new SevenZFile(new File("/file/to/extract.7z"));
>  SevenZArchiveEntry entry;
>  while ((entry = sevenZFile.getNextEntry()) != null){
>  if (entry.isDirectory())
> { continue; }
> File curfile = new File(destination, entry.getName());
>  File parent = curfile.getParentFile();
>  if (!parent.exists())
> { parent.mkdirs(); }
> FileOutputStream out = new FileOutputStream(curfile);
> while(sevenZFile.read(buffer, 0, buffer.length) > 0)
> { out.write(buffer); out.close(); }
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (COMPRESS-496) SevenZFile.read got an exception when extracting empty file

[yiang li (Jira)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yiang li updated COMPRESS-496:
--
Description: 
When extracting an empty file in SevenZFile, an exception will be thrown. This 
is because the `deferredBlockStreams` in SevenZFile was clear here

 
{code:java}
if (folderIndex < 0) {
 deferredBlockStreams.clear();
 // TODO: previously it'd return an empty stream?
 // new BoundedInputStream(new ByteArrayInputStream(new byte[0]), 0);
 return;
}{code}
Maybe an empty stream should be added to deferredBlockStreams here as the TODO 
said?

 

Code to reproduce the exception
{code:java}
byte[] buffer = new byte[4096];
 String destination = "/output/dir/of/7z";
 SevenZFile sevenZFile = new SevenZFile(new File("/file/to/extract.7z"));
 SevenZArchiveEntry entry;
 while ((entry = sevenZFile.getNextEntry()) != null){
 if (entry.isDirectory())
{ continue; }
File curfile = new File(destination, entry.getName());
 File parent = curfile.getParentFile();
 if (!parent.exists())
{ parent.mkdirs(); }
FileOutputStream out = new FileOutputStream(curfile);
while(sevenZFile.read(buffer, 0, buffer.length) > 0)
{ out.write(buffer); out.close(); }
}
{code}

  was:
When extracting an empty file in SevenZFile, an exception will be thrown. This 
is because the `deferredBlockStreams` in SevenZFile was clear here

 
{code:java}
if (folderIndex < 0) {
 deferredBlockStreams.clear();
 // TODO: previously it'd return an empty stream?
 // new BoundedInputStream(new ByteArrayInputStream(new byte[0]), 0);
 return;
}{code}
Maybe an empty stream should be added to deferredBlockStreams here as the TODO 
said?

 

Code to reproduce the exception

 
{code:java}
byte[] buffer = new byte[4096];
 String destination = "/output/dir/of/7z";
 SevenZFile sevenZFile = new SevenZFile(new File("/file/to/extract.7z"));
 SevenZArchiveEntry entry;
 while ((entry = sevenZFile.getNextEntry()) != null){
 if (entry.isDirectory())
{ continue; }
File curfile = new File(destination, entry.getName());
 File parent = curfile.getParentFile();
 if (!parent.exists())
{ parent.mkdirs(); }
FileOutputStream out = new FileOutputStream(curfile);
while(sevenZFile.read(buffer, 0, buffer.length) > 0)
{ out.write(buffer); out.close(); }
}
{code}


> SevenZFile.read got an exception when extracting empty file
> ---
>
> Key: COMPRESS-496
> URL: https://issues.apache.org/jira/browse/COMPRESS-496
> Project: Commons Compress
>  Issue Type: Bug
>Reporter: yiang li
>Priority: Minor
>
> When extracting an empty file in SevenZFile, an exception will be thrown. 
> This is because the `deferredBlockStreams` in SevenZFile was clear here
>  
> {code:java}
> if (folderIndex < 0) {
>  deferredBlockStreams.clear();
>  // TODO: previously it'd return an empty stream?
>  // new BoundedInputStream(new ByteArrayInputStream(new byte[0]), 0);
>  return;
> }{code}
> Maybe an empty stream should be added to deferredBlockStreams here as the 
> TODO said?
>  
> Code to reproduce the exception
> {code:java}
> byte[] buffer = new byte[4096];
>  String destination = "/output/dir/of/7z";
>  SevenZFile sevenZFile = new SevenZFile(new File("/file/to/extract.7z"));
>  SevenZArchiveEntry entry;
>  while ((entry = sevenZFile.getNextEntry()) != null){
>  if (entry.isDirectory())
> { continue; }
> File curfile = new File(destination, entry.getName());
>  File parent = curfile.getParentFile();
>  if (!parent.exists())
> { parent.mkdirs(); }
> FileOutputStream out = new FileOutputStream(curfile);
> while(sevenZFile.read(buffer, 0, buffer.length) > 0)
> { out.write(buffer); out.close(); }
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (COMPRESS-496) SevenZFile.read got an exception when extracting empty file

[yiang li (Jira)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yiang li updated COMPRESS-496:
--
Description: 
When extracting an empty file in SevenZFile, an exception will be thrown. This 
is because the `deferredBlockStreams` in SevenZFile was clear here

 
{code:java}
if (folderIndex < 0) {
 deferredBlockStreams.clear();
 // TODO: previously it'd return an empty stream?
 // new BoundedInputStream(new ByteArrayInputStream(new byte[0]), 0);
 return;
}{code}
Maybe an empty stream should be added to deferredBlockStreams here as the TODO 
said?

 

Code to reproduce the exception

 
{code:java}
byte[] buffer = new byte[4096];
 String destination = "/output/dir/of/7z";
 SevenZFile sevenZFile = new SevenZFile(new File("/file/to/extract.7z"));
 SevenZArchiveEntry entry;
 while ((entry = sevenZFile.getNextEntry()) != null){
 if (entry.isDirectory())
{ continue; }
File curfile = new File(destination, entry.getName());
 File parent = curfile.getParentFile();
 if (!parent.exists())
{ parent.mkdirs(); }
FileOutputStream out = new FileOutputStream(curfile);
while(sevenZFile.read(buffer, 0, buffer.length) > 0)
{ out.write(buffer); out.close(); }
}
{code}

  was:
{color:#FF}{color}When extracting an empty file in SevenZFile, an exception 
will be thrown. This is because the `deferredBlockStreams` in SevenZFile was 
clear here

```

if (folderIndex < 0) {
 deferredBlockStreams.clear();
 // TODO: previously it'd return an empty stream?
 // new BoundedInputStream(new ByteArrayInputStream(new byte[0]), 0);
 return;
}

```

Maybe an empty stream should be added to deferredBlockStreams here as the TODO 
said?

 

Code to reproduce the exception

```

byte[] buffer = new byte[4096];
String destination = "/output/dir/of/7z";
SevenZFile sevenZFile = new SevenZFile(new File("/file/to/extract.7z"));
SevenZArchiveEntry entry;
while ((entry = sevenZFile.getNextEntry()) != null){
 if (entry.isDirectory()){
 continue;
 }
 File curfile = new File(destination, entry.getName());
 File parent = curfile.getParentFile();
 if (!parent.exists()) {
 parent.mkdirs();
 }
 FileOutputStream out = new FileOutputStream(curfile);

 while(sevenZFile.read(buffer, 0, buffer.length) > 0) {
 out.write(buffer);
 out.close();
 }
}

```


> SevenZFile.read got an exception when extracting empty file
> ---
>
> Key: COMPRESS-496
> URL: https://issues.apache.org/jira/browse/COMPRESS-496
> Project: Commons Compress
>  Issue Type: Bug
>Reporter: yiang li
>Priority: Minor
>
> When extracting an empty file in SevenZFile, an exception will be thrown. 
> This is because the `deferredBlockStreams` in SevenZFile was clear here
>  
> {code:java}
> if (folderIndex < 0) {
>  deferredBlockStreams.clear();
>  // TODO: previously it'd return an empty stream?
>  // new BoundedInputStream(new ByteArrayInputStream(new byte[0]), 0);
>  return;
> }{code}
> Maybe an empty stream should be added to deferredBlockStreams here as the 
> TODO said?
>  
> Code to reproduce the exception
>  
> {code:java}
> byte[] buffer = new byte[4096];
>  String destination = "/output/dir/of/7z";
>  SevenZFile sevenZFile = new SevenZFile(new File("/file/to/extract.7z"));
>  SevenZArchiveEntry entry;
>  while ((entry = sevenZFile.getNextEntry()) != null){
>  if (entry.isDirectory())
> { continue; }
> File curfile = new File(destination, entry.getName());
>  File parent = curfile.getParentFile();
>  if (!parent.exists())
> { parent.mkdirs(); }
> FileOutputStream out = new FileOutputStream(curfile);
> while(sevenZFile.read(buffer, 0, buffer.length) > 0)
> { out.write(buffer); out.close(); }
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (COMPRESS-496) SevenZFile.read got an exception when extracting empty file

[yiang li (Jira)]

yiang li created COMPRESS-496:
-

 Summary: SevenZFile.read got an exception when extracting empty 
file
 Key: COMPRESS-496
 URL: https://issues.apache.org/jira/browse/COMPRESS-496
 Project: Commons Compress
  Issue Type: Bug
Reporter: yiang li


{color:#FF}{color}When extracting an empty file in SevenZFile, an exception 
will be thrown. This is because the `deferredBlockStreams` in SevenZFile was 
clear here

```

if (folderIndex < 0) {
 deferredBlockStreams.clear();
 // TODO: previously it'd return an empty stream?
 // new BoundedInputStream(new ByteArrayInputStream(new byte[0]), 0);
 return;
}

```

Maybe an empty stream should be added to deferredBlockStreams here as the TODO 
said?

 

Code to reproduce the exception

```

byte[] buffer = new byte[4096];
String destination = "/output/dir/of/7z";
SevenZFile sevenZFile = new SevenZFile(new File("/file/to/extract.7z"));
SevenZArchiveEntry entry;
while ((entry = sevenZFile.getNextEntry()) != null){
 if (entry.isDirectory()){
 continue;
 }
 File curfile = new File(destination, entry.getName());
 File parent = curfile.getParentFile();
 if (!parent.exists()) {
 parent.mkdirs();
 }
 FileOutputStream out = new FileOutputStream(curfile);

 while(sevenZFile.read(buffer, 0, buffer.length) > 0) {
 out.write(buffer);
 out.close();
 }
}

```



--
This message was sent by Atlassian Jira
(v8.3.4#803005)