[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=330296&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-330296
 ]

ASF GitHub Bot logged work on LANG-1177:


Author: ASF GitHub Bot
Created on: 18/Oct/19 05:11
Start Date: 18/Oct/19 05:11
Worklog Time Spent: 10m 
  Work Description: coveralls commented on issue #471: [LANG-1177] Added 
indexesOf methods and simplified removeAllOccurences
URL: https://github.com/apache/commons-lang/pull/471#issuecomment-543509688
 
 
   
   [![Coverage 
Status](https://coveralls.io/builds/26390317/badge)](https://coveralls.io/builds/26390317)
   
   Coverage increased (+0.02%) to 95.376% when pulling 
**f873d0ac37bff96fe63e486b36f9d86d87561309 on lielfr:lang-1177** into 
**9489d55d5c6a33e8ce5cc64b00a3282e84d2a81f 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: 330296)
Time Spent: 20m  (was: 10m)

> 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: 20m
>  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] coveralls commented on issue #471: [LANG-1177] Added indexesOf methods and simplified removeAllOccurences

[GitBox]

coveralls commented on issue #471: [LANG-1177] Added indexesOf methods and 
simplified removeAllOccurences
URL: https://github.com/apache/commons-lang/pull/471#issuecomment-543509688
 
 
   
   [![Coverage 
Status](https://coveralls.io/builds/26390317/badge)](https://coveralls.io/builds/26390317)
   
   Coverage increased (+0.02%) to 95.376% when pulling 
**f873d0ac37bff96fe63e486b36f9d86d87561309 on lielfr:lang-1177** into 
**9489d55d5c6a33e8ce5cc64b00a3282e84d2a81f 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] (LANG-1177) Improve indexOf performance when called multiple times

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on LANG-1177:


Author: ASF GitHub Bot
Created on: 18/Oct/19 04:47
Start Date: 18/Oct/19 04:47
Worklog Time Spent: 10m 
  Work Description: lielfr commented on pull request #471: [LANG-1177] 
Added indexesOf methods and simplified removeAllOccurences
URL: https://github.com/apache/commons-lang/pull/471
 
 
   Based of the opened issue. Tests for indexesOf were also added.
 

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: 330284)
Remaining Estimate: 0h
Time Spent: 10m

> 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: 10m
>  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] lielfr opened a new pull request #471: [LANG-1177] Added indexesOf methods and simplified removeAllOccurences

[GitBox]

lielfr opened a new pull request #471: [LANG-1177] Added indexesOf methods and 
simplified removeAllOccurences
URL: https://github.com/apache/commons-lang/pull/471
 
 
   Based of the opened issue. Tests for indexesOf were also added.


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] (VFS-744) org.apache.commons.vfs2.FileContent.getByteArray() can throw NegativeArraySizeException for BZip2 files

[Gary D. Gregory (Jira)]

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

Gary D. Gregory resolved VFS-744.
-
Fix Version/s: 2.5.0
   Resolution: Fixed

In git master.

> org.apache.commons.vfs2.FileContent.getByteArray() can throw 
> NegativeArraySizeException for BZip2 files
> ---
>
> Key: VFS-744
> URL: https://issues.apache.org/jira/browse/VFS-744
> Project: Commons VFS
>  Issue Type: New Feature
>Reporter: Gary D. Gregory
>Priority: Major
> Fix For: 2.5.0
>
>
> The method {{org.apache.commons.vfs2.FileContent.getByteArray()}} can throw 
> {{NegativeArraySizeException}} for BZip2 files when a file size within the 
> compressed file cannot be determined.
>  This method is called by:
> - org.apache.commons.vfs2.FileContent.getString(Charset)
> - org.apache.commons.vfs2.FileContent.getString(String)
> - org.apache.commons.vfs2.FileUtil.getContent(FileObject)



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

[jira] [Updated] (VFS-744) org.apache.commons.vfs2.FileContent.getByteArray() can throw NegativeArraySizeException for BZip2 files

[Gary D. Gregory (Jira)]

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

Gary D. Gregory updated VFS-744:

Description: 
The method {{org.apache.commons.vfs2.FileContent.getByteArray()}} can throw 
{{NegativeArraySizeException}} for BZip2 files when a file size within the 
compressed file cannot be determined.

 This method is called by:

- org.apache.commons.vfs2.FileContent.getString(Charset)
- org.apache.commons.vfs2.FileContent.getString(String)
- org.apache.commons.vfs2.FileUtil.getContent(FileObject)

  was:
The method {{org.apache.commons.vfs2.FileContent.getByteArray()}} can throw 
{{NegativeArraySizeException}} for BZip2 files when a file size within the 
compressed file cannot be determined.

 


> org.apache.commons.vfs2.FileContent.getByteArray() can throw 
> NegativeArraySizeException for BZip2 files
> ---
>
> Key: VFS-744
> URL: https://issues.apache.org/jira/browse/VFS-744
> Project: Commons VFS
>  Issue Type: New Feature
>Reporter: Gary D. Gregory
>Priority: Major
>
> The method {{org.apache.commons.vfs2.FileContent.getByteArray()}} can throw 
> {{NegativeArraySizeException}} for BZip2 files when a file size within the 
> compressed file cannot be determined.
>  This method is called by:
> - org.apache.commons.vfs2.FileContent.getString(Charset)
> - org.apache.commons.vfs2.FileContent.getString(String)
> - org.apache.commons.vfs2.FileUtil.getContent(FileObject)



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

[jira] [Created] (VFS-744) org.apache.commons.vfs2.FileContent.getByteArray() can throw NegativeArraySizeException for BZip2 files

[Gary D. Gregory (Jira)]

Gary D. Gregory created VFS-744:
---

 Summary: org.apache.commons.vfs2.FileContent.getByteArray() can 
throw NegativeArraySizeException for BZip2 files
 Key: VFS-744
 URL: https://issues.apache.org/jira/browse/VFS-744
 Project: Commons VFS
  Issue Type: New Feature
Reporter: Gary D. Gregory


The method {{org.apache.commons.vfs2.FileContent.getByteArray()}} can throw 
{{NegativeArraySizeException}} for BZip2 files when a file size within the 
compressed file cannot be determined.

 



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

[jira] [Resolved] (VFS-743) Add org.apache.commons.vfs2.provider.compressed.CompressedFileFileObject.SIZE_UNDEFINED

[Gary D. Gregory (Jira)]

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

Gary D. Gregory resolved VFS-743.
-
Fix Version/s: 2.5.0
   Resolution: Fixed

In git master.

> Add 
> org.apache.commons.vfs2.provider.compressed.CompressedFileFileObject.SIZE_UNDEFINED
> ---
>
> Key: VFS-743
> URL: https://issues.apache.org/jira/browse/VFS-743
> Project: Commons VFS
>  Issue Type: New Feature
>Reporter: Gary D. Gregory
>Priority: Major
> Fix For: 2.5.0
>
>
> Add 
> {{org.apache.commons.vfs2.provider.compressed.CompressedFileFileObject.SIZE_UNDEFINED}}



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

[jira] [Created] (VFS-743) Add org.apache.commons.vfs2.provider.compressed.CompressedFileFileObject.SIZE_UNDEFINED

[Gary D. Gregory (Jira)]

Gary D. Gregory created VFS-743:
---

 Summary: Add 
org.apache.commons.vfs2.provider.compressed.CompressedFileFileObject.SIZE_UNDEFINED
 Key: VFS-743
 URL: https://issues.apache.org/jira/browse/VFS-743
 Project: Commons VFS
  Issue Type: New Feature
Reporter: Gary D. Gregory


Add 
{{org.apache.commons.vfs2.provider.compressed.CompressedFileFileObject.SIZE_UNDEFINED}}



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

[jira] [Created] (VFS-742) Add org.apache.commons.vfs2.FileContent.isEmpty()

[Gary D. Gregory (Jira)]

Gary D. Gregory created VFS-742:
---

 Summary: Add org.apache.commons.vfs2.FileContent.isEmpty()
 Key: VFS-742
 URL: https://issues.apache.org/jira/browse/VFS-742
 Project: Commons VFS
  Issue Type: New Feature
Reporter: Gary D. Gregory


Add {{org.apache.commons.vfs2.FileContent.isEmpty()}} as a default method 
calling {{getSize()}}.

 



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

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

[Gary D. Gregory (Jira)]

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

Gary D. Gregory resolved VFS-686.
-
Fix Version/s: 2.5.0
   Resolution: Fixed

In git master. Please verify and close.

> 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] [Work logged] (VFS-686) Upgrade Jackrabbit dependency to the latest 2.x

[ASF GitHub Bot (Jira)]

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

ASF GitHub Bot logged work on VFS-686:
--

Author: ASF GitHub Bot
Created on: 17/Oct/19 15:37
Start Date: 17/Oct/19 15:37
Worklog Time Spent: 10m 
  Work Description: garydgregory commented on pull request #52: VFS-686: 
webdav4 provider based on the latest Jackrabbit 2.x
URL: https://github.com/apache/commons-vfs/pull/52
 
 
   
 

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: 329953)
Time Spent: 20m  (was: 10m)

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

[GitHub] [commons-vfs] garydgregory merged pull request #52: VFS-686: webdav4 provider based on the latest Jackrabbit 2.x

[GitBox]

garydgregory merged pull request #52: VFS-686: webdav4 provider based on the 
latest Jackrabbit 2.x
URL: https://github.com/apache/commons-vfs/pull/52
 
 
   


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] (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&focusedCommentId=16953853#comment-16953853
 ] 

Woonsan Ko commented on VFS-686:


Hi [~ggregory],
I've just pushed since tag fixes to PR.
Thanks!
Woonsan

P.S. There seemed to have a temporary build error in travis. I assume it's 
travis env issue at the moment. After re-kicking the build, it seems to build 
fine in most envs.


> 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
> 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: 10m
>  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)

[GitHub] [commons-vfs] woonsan commented on issue #52: VFS-686: webdav4 provider based on the latest Jackrabbit 2.x

[GitBox]

woonsan commented on issue #52: VFS-686: webdav4 provider based on the latest 
Jackrabbit 2.x
URL: https://github.com/apache/commons-vfs/pull/52#issuecomment-543232040
 
 
   @garydgregory , after confirming local build with oracle-jdk11 working fine, 
I kicked in travis again and it seems to build fine now.
   
   Regarding the java.lang.ClassCastException from jetty (v6.x), unfortunately 
JR 1.6.5 is the latest release in 1.x range. However, it seems like not 
affecting the test running itself; it seems to throw an exception only when 
initializing JSP engine which is never used in JR webdav server.
   FYI, JR2.x uses jetty 9.x.


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-vfs] garydgregory commented on issue #52: VFS-686: webdav4 provider based on the latest Jackrabbit 2.x

[GitBox]

garydgregory commented on issue #52: VFS-686: webdav4 provider based on the 
latest Jackrabbit 2.x
URL: https://github.com/apache/commons-vfs/pull/52#issuecomment-543221367
 
 
   And somehow we are back to failing builds on Java >= 11 
https://travis-ci.org/apache/commons-vfs/builds/599194873
   arg. @woonsan May you take a look SVP?


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-vfs] garydgregory commented on issue #52: VFS-686: webdav4 provider based on the latest Jackrabbit 2.x

[GitBox]

garydgregory commented on issue #52: VFS-686: webdav4 provider based on the 
latest Jackrabbit 2.x
URL: https://github.com/apache/commons-vfs/pull/52#issuecomment-543220858
 
 
   Is there a version of JR 1.x that would avoid:
   ```
   Running org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase
   SLF4J: Class path contains multiple SLF4J bindings.
   SLF4J: Found binding in 
[jar:file:/home/travis/.m2/repository/org/slf4j/slf4j-log4j12/1.5.11/slf4j-log4j12-1.5.11.jar!/org/slf4j/impl/StaticLoggerBinder.class]
   SLF4J: Found binding in 
[jar:file:/home/travis/.m2/repository/org/apache/jackrabbit/jackrabbit-standalone/1.6.5/jackrabbit-standalone-1.6.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
   SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an 
explanation.
   2019-10-17 09:08:58,002 [main] ERROR unavailable
   java.lang.ClassCastException: class 
jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to class 
java.net.URLClassLoader (jdk.internal.loader.ClassLoaders$AppClassLoader and 
java.net.URLClassLoader are in module java.base of loader 'bootstrap')
at 
org.apache.jasper.compiler.JspRuntimeContext.(JspRuntimeContext.java:174)
at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:150)
at 
org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:431)
at 
org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
at 
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at 
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:643)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
at 
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1234)
at 
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
at 
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:460)
at 
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at 
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at 
org.mortbay.jetty.handler.RequestLogHandler.doStart(RequestLogHandler.java:115)
at 
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at 
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at 
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at 
org.apache.commons.vfs2.provider.webdav.test.JackrabbitMain.run(JackrabbitMain.java:232)
at 
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase.startJackrabbit(WebdavProviderTestCase.java:237)
at 
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase.setUpClass(WebdavProviderTestCase.java:216)
at 
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase.access$100(WebdavProviderTestCase.java:55)
at 
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1.setUp(WebdavProviderTestCase.java:245)
at 
org.apache.commons.vfs2.test.AbstractTestSuite.lambda$run$0(AbstractTestSuite.java:129)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at 
org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:134)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
   VfsClassLoaderTests no layered .jar provider, skipping.
   created threads still running:
   #2: main MultiThreadedHttpConnectionManager cleanup  WAITING daemon  
null
   ```
   See https://travis-ci.org/apache/commons-vfs/jobs/599058150


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] (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&focusedCommentId=16953819#comment-16953819
 ] 

Richard commented on CLI-298:
-

The main reason we didn't switch to JCommander was that we already had our 
Apache CLI options already set. Converting to another format, even if it 
reduces the amount of code by a given amount, would still be back-breaking and 
take considerable time to convert from one to the other. The approach I've 
settled with will save me a lot of time, anyway. Plus we here have a lot of 
love for Apache Commons!

Please don't let CLI head to the attic, it's not where it's destined for...

> 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] (FILEUPLOAD-293) FileExistsException: Destination .. already exists when DiskFileItem.write was given an existing file

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16953818#comment-16953818
 ] 

Gary D. Gregory commented on FILEUPLOAD-293:


Feel free to provide a PR with tests on GitHub ;-)


> FileExistsException: Destination .. already exists when DiskFileItem.write 
> was given an existing file
> -
>
> Key: FILEUPLOAD-293
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-293
> Project: Commons FileUpload
>  Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Mladen Girazovski
>Assignee: Jochen Wiedmann
>Priority: Major
> Fix For: 1.4.1
>
>
> Since 1.4, where FILEUPLOAD-248 was shipped, passing an existing file to 
> DiskFileItem.write will cause an FileExistsException with the message 
> "Destination FILE already exist", this prevents us from upgrading to 1.4 from 
> 1.3.3.
>  
> {{2019-02-20 01:12:56,504 http-nio-2990-exec-3 ERROR 
> [|5ccb9b99-a96f-42ba-ad01-ac278516e1a4|] 
> [IssueAttachmentsResource.privacy-safe] Error saving attachment}}
> {{org.apache.commons.io.FileExistsException: Destination 
> '/buildeng/bamboo-agent-home/xml-data/build-dir/CLOUDRELEASE-AGILEWD15421-FT18/jira-test-runner-jira/target/cargo/configurations/tomcat9x/temp/attachment-3404789743778163937.tmp'
>  already exists}}
> {{ at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:3001)}}
> {{ at 
> org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405)}}
> {{ at 
> com.atlassian.plugins.rest.common.multipart.fileupload.CommonsFileUploadFilePart.write(CommonsFileUploadFilePart.java:49)}}
> {{ at 
> com.atlassian.jira.rest.v2.issue.IssueAttachmentsResource.getFileFromFilePart(IssueAttachmentsResource.java:175)}}
> {{...}}
>  
> Apache Felix also ran into the same bug:
> https://issues.apache.org/jira/browse/FELIX-6037 



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

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

[Gilles Sadowski (Jira)]

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

Gilles Sadowski commented on CLI-298:
-

bq. JCommander and picoli are already there and working nicely.

For components that are heading towards the attic, shouldn't it be mentioned on 
the web site, so that people don't waste their time (and are redirected to the 
appropriate places)?


> 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] (VFS-686) Upgrade Jackrabbit dependency to the latest 2.x

[Gary D. Gregory (Jira)]

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

Gary D. Gregory commented on VFS-686:
-

I'd like to use GitHub to squash and merge, can you make sure the PR is 
up-to-date WRT {{@since}} tags?

> 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
> 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: 10m
>  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] [Commented] (CLI-298) Define CLI options via configuration file

[Gary D. Gregory (Jira)]

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

Gary D. Gregory commented on CLI-298:
-

My personal preference is to keep Commons CLI bare bones unless someone wants 
to take the annotations approach; but honestly, I do not know why anyone would 
want to do that when JCommander and picoli are already there and working nicely.


> 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] (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&focusedCommentId=16953776#comment-16953776
 ] 

Richard commented on CLI-298:
-

One other thing: I started this project with the intent of not modifying any of 
the main code. However, I am wondering once I've hooked in all the 
type-conversion formatting and checking for different types (ints, files etc.) 
that it might have application to be brought into the main code WRT configuring 
and coding CLI options.

> 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] (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&focusedCommentId=16953773#comment-16953773
 ] 

Richard commented on CLI-298:
-

OK should I just shelve this and maintain my own version? I don't want to waste 
your folks time posting here if you're not keen on my changes. Or I can go 
silent until I'm finished, update and you can see if it fits the bill.

You're right about the object model - as I stated, it's about reduction of the 
amount of code we write,  using this is an alternative to manually writing 
code, you just need your configuration file and about 20-30 lines of code - 
which is a great reduction of one of our applications. For example, there's one 
where the options and definitions with error checking arguments comes to just 
over 600 lines, and that's just one application! For all projects combined I 
imagine it's several thousand lines.

I'm not sure with my current example posted above that you see the benefit to 
using this as an alternative to manually writing options, so feel free to ask 
questions if you're not sure. Thanks for the feedback either way.

One important point: I'm not proposing these changes as a new and better way to 
use CLI - more that there's an alternative way if one wants to use it.

> 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] [Resolved] (VFS-741) Listing files with known prefix still fails

[Bernd Eckenfels (Jira)]

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

Bernd Eckenfels resolved VFS-741.
-
Fix Version/s: 2.5.0
 Assignee: Bernd Eckenfels
   Resolution: Fixed

Fixed on master 
https://gitbox.apache.org/repos/asf?p=commons-vfs.git;a=commit;h=d79524d567f4bbd9e9b8e056451ede70e89abd35

> Listing files with known prefix still fails
> ---
>
> Key: VFS-741
> URL: https://issues.apache.org/jira/browse/VFS-741
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.4.1
>Reporter: Bernd Eckenfels
>Assignee: Bernd Eckenfels
>Priority: Major
> Fix For: 2.5.0
>
>
> Efen after VFS-298 the listing of files in a directory may fail with 
> "FileSystemException: Invalid descendent file name" if the filename contains 
> a known/registered scheme.
> A trivial fix is in AFO to simply resolve the children names with a ./ 
> prefix, which makes them parse without a scheme.



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

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

[Emmanuel Bourg (Jira)]

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

Emmanuel Bourg commented on CLI-298:


I admit I'm not seduced either by the format proposed. There is a duplication 
between the options defined in the file and the options parsed in the listener. 
Also, the purpose of the listener seems mostly to be to build an object model 
equivalent to the command line arguments. This problem is more cleanly solved 
by an annotation based approach like JCommander.

We could get some inspiration from other CLI libraries but we would probably 
end up rewriting the same code. Unless we have a clever novel design idea I 
don't think it's worth rewriting what others have already done.

> 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] (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&focusedCommentId=16953756#comment-16953756
 ] 

Richard commented on CLI-298:
-

Agreed about text file format, for myself with the projects we're working on, 
once I've completed this, it will massively reduce code overhead because some 
of our CLI applications have dozens of options, and currently about to hit half 
a dozen for the amount of individual applications we maintain that use CLI. I'd 
love to see annotations too but this is more of a priority for myself at the 
moment.

Talking of which, how do you folks work here? My current section is now 
finished, and what's left (in no strict order) is:

* File corruption/modification detection;
* Add ability to coerce arguments to integers, floating point numbers, dates, 
files, IP addresses, URLs along with the ability to create your own builders; 
on top of this will be the ability to say that a file must exist, must be a 
directory, must not exist, check integer value limits etc. and add all the 
handling to print back to the user if there's a problem.;
* Expanding on the previous point, the ability to defines options as taking 
lists of any of the above e.g. \-\-portNums=80,8080,8081 etc;
* Add I18N since currently the user could be defining text to be output in 
their native language but currently errors will be reported in English;

So my question is shall I keep updating this task or create new tasks, also 
should I treat this as one pull request or do one per feature update? Happy to 
conform to your working standards.

> 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] (CLI-298) Define CLI options via configuration file

[Gary D. Gregory (Jira)]

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

Gary D. Gregory commented on CLI-298:
-

I am not a fan of the text file format, it is too brittle, not type-safe, and 
too easy to mess up. 

I see annotations as the way forward here. 

External files are good for I18N of course. 

Sadly it seems to me that Commons CLI has really fallen behind the times, we 
should look for inspiration at JCommander http://jcommander.org/ and picocli 
https://picocli.info/ 

I've am currently using JCommander for new projects but still have some Commons 
CLI in older ones.


> 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] (CLI-298) Define CLI options via configuration file

[Emmanuel Bourg (Jira)]

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

Emmanuel Bourg commented on CLI-298:


MD5 is still fine if the purpose is to detect accidental corruption. It isn't 
if security is at stake.

> 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] (CLI-298) Define CLI options via configuration file

[Gary D. Gregory (Jira)]

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

Gary D. Gregory commented on CLI-298:
-

Tangent (regardless of the merit of this ticket): Do not use MD5, it is broken, 
use SHA-256 or 512.

> 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] (VFS-741) Listing files with known prefix still fails

[Gary D. Gregory (Jira)]

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

Gary D. Gregory commented on VFS-741:
-

Can this issue be closed now ?

> Listing files with known prefix still fails
> ---
>
> Key: VFS-741
> URL: https://issues.apache.org/jira/browse/VFS-741
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.4.1
>Reporter: Bernd Eckenfels
>Priority: Major
>
> Efen after VFS-298 the listing of files in a directory may fail with 
> "FileSystemException: Invalid descendent file name" if the filename contains 
> a known/registered scheme.
> A trivial fix is in AFO to simply resolve the children names with a ./ 
> prefix, which makes them parse without a scheme.



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

[GitHub] [commons-collections] garydgregory merged pull request #88: find and fix fixtypo

[GitBox]

garydgregory merged pull request #88: find and fix fixtypo
URL: https://github.com/apache/commons-collections/pull/88
 
 
   


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-vfs] garydgregory edited a comment on issue #52: VFS-686: webdav4 provider based on the latest Jackrabbit 2.x

[GitBox]

garydgregory edited a comment on issue #52: VFS-686: webdav4 provider based on 
the latest Jackrabbit 2.x
URL: https://github.com/apache/commons-vfs/pull/52#issuecomment-543147684
 
 
   Hi @woonsan 
   Thank you for the update, I think the hopefully last item to take care of is 
to update new `@since` tags to `2.5.0`.
   
   Eariler, you said:
   
   > Once Jackrabbit 2.19.2 or higher becomes available, we can probably enable 
the tests by default later.
   > Is this okay?
   
   Are these tests enabled now?
   


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-vfs] garydgregory commented on issue #52: VFS-686: webdav4 provider based on the latest Jackrabbit 2.x

[GitBox]

garydgregory commented on issue #52: VFS-686: webdav4 provider based on the 
latest Jackrabbit 2.x
URL: https://github.com/apache/commons-vfs/pull/52#issuecomment-543147684
 
 
   Hi @woonsan 
   Thank you for the update, I think the hopefully last item to take care of is 
to update new `@since` tags to `2.5.0`.


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] [Created] (VFS-741) Listing files with known prefix still fails

[Bernd Eckenfels (Jira)]

Bernd Eckenfels created VFS-741:
---

 Summary: Listing files with known prefix still fails
 Key: VFS-741
 URL: https://issues.apache.org/jira/browse/VFS-741
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 2.4.1
Reporter: Bernd Eckenfels


Efen after VFS-298 the listing of files in a directory may fail with 
"FileSystemException: Invalid descendent file name" if the filename contains a 
known/registered scheme.

A trivial fix is in AFO to simply resolve the children names with a ./ prefix, 
which makes them parse without a scheme.



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

[jira] [Commented] (CLI-237) CLIMessageBundle for Portuguese (attached)

[Richard (Jira)]

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

Richard commented on CLI-237:
-

I'm interested in this since I need to add I18N to my changes for CLI-298: As 
it stands, if users define their descriptions in another language, any errors 
will be printed in English and won't make sense to anyone that doesn't 
understand English.

Tambem falo portuguese poquinho

(Translation: I also speak a little bit of Portuguese)

> CLIMessageBundle for Portuguese (attached)
> --
>
> Key: CLI-237
> URL: https://issues.apache.org/jira/browse/CLI-237
> Project: Commons CLI
>  Issue Type: Improvement
>  Components: CLI-2.x
>Affects Versions: 2.0, Nightly Builds
>Reporter: Ricardo Espirito Santo
>Priority: Minor
>  Labels: i18n
> Fix For: 2.1
>
> Attachments: CLIMessageBundle_pt_PT.properties
>
>
> A Portuguese (Portugal) message bundle



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

[GitHub] [commons-cli] coveralls edited a comment on issue #32: New sources for defining CLI options via a configuration file.

[GitBox]

coveralls edited a comment on issue #32: New sources for defining CLI options 
via a configuration file.
URL: https://github.com/apache/commons-cli/pull/32#issuecomment-542780525
 
 
   
   [![Coverage 
Status](https://coveralls.io/builds/26372359/badge)](https://coveralls.io/builds/26372359)
   
   Coverage increased (+0.9%) to 97.299% when pulling 
**a56dfddc06ac2c982ce1e9237446e5b798390448 on zendawg:cli-configuration** into 
**64900674a1d10f51ca9ef61423d6695be17d8c33 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-cli] coveralls edited a comment on issue #32: New sources for defining CLI options via a configuration file.

[GitBox]

coveralls edited a comment on issue #32: New sources for defining CLI options 
via a configuration file.
URL: https://github.com/apache/commons-cli/pull/32#issuecomment-542780525
 
 
   
   [![Coverage 
Status](https://coveralls.io/builds/26371859/badge)](https://coveralls.io/builds/26371859)
   
   Coverage increased (+0.9%) to 97.284% when pulling 
**77a115c6744832636f22a23f32056ae44928ce92 on zendawg:cli-configuration** into 
**64900674a1d10f51ca9ef61423d6695be17d8c33 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] (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&focusedCommentId=16953607#comment-16953607
 ] 

Richard commented on CLI-298:
-

Strictly speaking I suppose they are properties files since (at the moment) all 
definition take the form x=y.

So right now they are configuration files that are property-based.

However, I am not sure if this will always hold since there are more phases to 
this to finish. For example adding builder and checkers to get values as 
integral values and checking that the values are correct according to 
user-defined 'properties'. This will greatly reduce the amount of code users 
have to write.

As it stands, I believe that future updates (I plan to finish this by the end 
of next week) will take the same form.

I assume that you're thinking that it would be worthwhile renaming the test 
files to .properties instead of .conf?

The reason I've not read them in as a properties file is that there's a strict 
format to which the options appear which I believe reading as a properties file 
would break.

What are your thoughts on this?

> 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] (CLI-298) Define CLI options via configuration file

[Emmanuel Bourg (Jira)]

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

Emmanuel Bourg commented on CLI-298:


The config file is a properties file or a custom format?

> 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] (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&focusedCommentId=16953597#comment-16953597
 ] 

Richard commented on CLI-298:
-

Tests updated, new test files added. Stricter parsing of options now enforces 
that they are defined in groups and options cannot have their members set more 
than once.

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

[GitHub] [commons-collections] dota17 opened a new pull request #88: find and fix fixtypo

[GitBox]

dota17 opened a new pull request #88: find and fix fixtypo
URL: https://github.com/apache/commons-collections/pull/88
 
 
   find and fix fixtypo


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] (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&focusedCommentId=16953539#comment-16953539
 ] 

Woonsan Ko commented on VFS-686:


Latest patch generated from PR:  [^feature-VFS-686-6.patch] 
{noformat:title=example command}
$ git apply --whitespace=fix feature-VFS-686-6.patch
{noformat}

> 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
> 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: 10m
>  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] (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 updated VFS-686:
---
Attachment: feature-VFS-686-6.patch

> 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
> 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: 10m
>  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] [Commented] (FILEUPLOAD-293) FileExistsException: Destination .. already exists when DiskFileItem.write was given an existing file

[Robert Lichtenberger (Jira)]

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16953526#comment-16953526
 ] 

Robert Lichtenberger commented on FILEUPLOAD-293:
-

I would also welcome a bugfix release for this regression.

> FileExistsException: Destination .. already exists when DiskFileItem.write 
> was given an existing file
> -
>
> Key: FILEUPLOAD-293
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-293
> Project: Commons FileUpload
>  Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Mladen Girazovski
>Assignee: Jochen Wiedmann
>Priority: Major
> Fix For: 1.4.1
>
>
> Since 1.4, where FILEUPLOAD-248 was shipped, passing an existing file to 
> DiskFileItem.write will cause an FileExistsException with the message 
> "Destination FILE already exist", this prevents us from upgrading to 1.4 from 
> 1.3.3.
>  
> {{2019-02-20 01:12:56,504 http-nio-2990-exec-3 ERROR 
> [|5ccb9b99-a96f-42ba-ad01-ac278516e1a4|] 
> [IssueAttachmentsResource.privacy-safe] Error saving attachment}}
> {{org.apache.commons.io.FileExistsException: Destination 
> '/buildeng/bamboo-agent-home/xml-data/build-dir/CLOUDRELEASE-AGILEWD15421-FT18/jira-test-runner-jira/target/cargo/configurations/tomcat9x/temp/attachment-3404789743778163937.tmp'
>  already exists}}
> {{ at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:3001)}}
> {{ at 
> org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405)}}
> {{ at 
> com.atlassian.plugins.rest.common.multipart.fileupload.CommonsFileUploadFilePart.write(CommonsFileUploadFilePart.java:49)}}
> {{ at 
> com.atlassian.jira.rest.v2.issue.IssueAttachmentsResource.getFileFromFilePart(IssueAttachmentsResource.java:175)}}
> {{...}}
>  
> Apache Felix also ran into the same bug:
> https://issues.apache.org/jira/browse/FELIX-6037 



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

[jira] [Commented] (FILEUPLOAD-299) Error replacing an existing file using FileItem.write

[Robert Lichtenberger (Jira)]

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16953523#comment-16953523
 ] 

Robert Lichtenberger commented on FILEUPLOAD-299:
-

This is a regression caused by the fix for 
https://issues.apache.org/jira/browse/FILEUPLOAD-248. While one might argue 
that it is safer not to overwrite existing files, consider the following 
pattern:

{{item.write(File.createTempFile("x", "y"));}}

In this case an empty temporary file is created. It makes no sense (and is even 
potentially dangerous) to require client code to delete the created temp file 
first.

 

> Error replacing an existing file using FileItem.write
> -
>
> Key: FILEUPLOAD-299
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-299
> Project: Commons FileUpload
>  Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Senthur Rajakumar
>Priority: Major
>
> FileItem.write throws FileExistsException 
> (org.apache.commons.io.FileExistsException) when we try to re-upload (or 
> overwrite) a file.
> *What works in v1.3.3:*
>  # User tries to upload a file user1.png
>  # It is stored in the server at c:\data\avatar\user1.png using FileItem.write
>  # User tries to upload the same file user1.png
>  # FileItem.write replaces the file c:\data\avatar\user1.png in the server 
> with the new file
> *In v1.4:*
> Step 4 fails with an exception - org.apache.commons.io.FileExistsException
>  
> *Stack Trace:*
> org.apache.commons.io.FileExistsException: Destination 
> 'c:\data\avatar\user1.png' already exists
>    at org.apache.commons.io.FileUtils.moveFile(FileUtils.java:3001)
>    at 
> org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:405)



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

[GitHub] [commons-collections] Claudenw commented on issue #83: WIP: Initial bloom filter code contribution

[GitBox]

Claudenw commented on issue #83: WIP: Initial bloom filter code contribution
URL: 
https://github.com/apache/commons-collections/pull/83#issuecomment-543048050
 
 
   If you were not to build a bloom filter what would you do to check if
   something was in the filter?
   
   I am going to guess at an answer here.
   
   1) create a bit array
   2) do some hashing of the object and turn on bits in the array
   3) execute [ array & filter == array ] test to see if it was in there.
   
   In essence you build a bloom filter.  These same steps are done when you
   create a bloom filter instance in the class
   
   So yes you have to build a bloom filter but the overhead is virtually
   non-existent as using the builder pattern removes/replaces steps from your
   process:
   
   Assumeing partA partB and partC of the object are to be hashed, the steps
   using the library are:
   
   // assuming 10K entries in the filter and 1 in 50K collision rate.  This
   only needs to be build once.
   BloomFilterConfiguration config = new BloomFIlterConfiguration( 1,
   1.0/5 );/
   
   BloomFilter bf = new StandardBloomFilter( ProtoBloomFilter.builder().with(
   obj.partA ).with( obj.partB ).with( obj.partC).build(), config );
   
   So the over head for comparisson is minimal.
   
   The filters are immutable because if you pass them as parameters you want
   to ensure that they are not modified by external operations (either
   intentionally or through error).  In most use cases once the filter is
   constructed it is used in one or more comparisons.  The only time a filter
   is modified is when another filter is added to the collection.  In my
   experience the rate at which you add filters to collections is much lower
   than the rate at which you compare them.
   
   The other reason is that the equality and the hashCode of a filter are
   based on the bits that are on.  So leaving them mutable would mean that the
   filters could not be used in a Hash based Set, because the hash would
   change after insertion when a new object was added.
   
   Claude
   Claude
   
   On Thu, Oct 17, 2019 at 2:20 AM SilverNarcissus 
   wrote:
   
   > Hi~ Thanks for your work! I have a question about you use immutable bloom
   > filter and if we want to judge whether an object is in a bloom filter, we
   > have to build a new bloom filter and compare them. There may be a
   > performance impact. How come you choose this design?
   >
   > —
   > You are receiving this because you were mentioned.
   > Reply to this email directly, view it on GitHub
   > 
,
   > or unsubscribe
   > 

   > .
   >
   
   
   -- 
   I like: Like Like - The likeliest place on the web
   
   LinkedIn: http://www.linkedin.com/in/claudewarren
   


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