[jira] [Work logged] (CRYPTO-151) Migrate to Junit 5
[ https://issues.apache.org/jira/browse/CRYPTO-151?focusedWorklogId=520662=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520662 ] ASF GitHub Bot logged work on CRYPTO-151: - Author: ASF GitHub Bot Created on: 06/Dec/20 07:54 Start Date: 06/Dec/20 07:54 Worklog Time Spent: 10m Work Description: arturobernalg opened a new pull request #114: URL: https://github.com/apache/commons-crypto/pull/114 Migrate to Junit 5 https://issues.apache.org/jira/browse/CRYPTO-151 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: 520662) Time Spent: 50m (was: 40m) > Migrate to Junit 5 > -- > > Key: CRYPTO-151 > URL: https://issues.apache.org/jira/browse/CRYPTO-151 > Project: Commons Crypto > Issue Type: Improvement >Affects Versions: 1.1.0 >Reporter: Arturo Bernal >Priority: Minor > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-crypto] arturobernalg opened a new pull request #114: [CRYPTO-151] - Migrate to Junit 5
arturobernalg opened a new pull request #114: URL: https://github.com/apache/commons-crypto/pull/114 Migrate to Junit 5 https://issues.apache.org/jira/browse/CRYPTO-151 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
[jira] [Work logged] (CRYPTO-151) Migrate to Junit 5
[ https://issues.apache.org/jira/browse/CRYPTO-151?focusedWorklogId=520661=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520661 ] ASF GitHub Bot logged work on CRYPTO-151: - Author: ASF GitHub Bot Created on: 06/Dec/20 07:53 Start Date: 06/Dec/20 07:53 Worklog Time Spent: 10m Work Description: arturobernalg closed pull request #109: URL: https://github.com/apache/commons-crypto/pull/109 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: 520661) Time Spent: 40m (was: 0.5h) > Migrate to Junit 5 > -- > > Key: CRYPTO-151 > URL: https://issues.apache.org/jira/browse/CRYPTO-151 > Project: Commons Crypto > Issue Type: Improvement >Affects Versions: 1.1.0 >Reporter: Arturo Bernal >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-crypto] arturobernalg closed pull request #109: [CRYPTO-151] - Migrate to Junit 5
arturobernalg closed pull request #109: URL: https://github.com/apache/commons-crypto/pull/109 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
[jira] [Work logged] (CRYPTO-154) Dangling Javadoc comment
[ https://issues.apache.org/jira/browse/CRYPTO-154?focusedWorklogId=520655=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520655 ] ASF GitHub Bot logged work on CRYPTO-154: - Author: ASF GitHub Bot Created on: 06/Dec/20 07:34 Start Date: 06/Dec/20 07:34 Worklog Time Spent: 10m Work Description: arturobernalg opened a new pull request #113: URL: https://github.com/apache/commons-crypto/pull/113 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: 520655) Remaining Estimate: 0h Time Spent: 10m > Dangling Javadoc comment > - > > Key: CRYPTO-154 > URL: https://issues.apache.org/jira/browse/CRYPTO-154 > Project: Commons Crypto > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Remove double star > > /** > * Licensed to the Apache Software Foundation (ASF) under one > * or more contributor license agreements. See the NOTICE file > * distributed with this work for additional information > * regarding copyright ownership. The ASF licenses this file > * to you under the Apache License, Version 2.0 (the > * "License"); you may not use this file except in compliance > * with the License. You may obtain a copy of the License at > * > * http://www.apache.org/licenses/LICENSE-2.0 > * > * Unless required by applicable law or agreed to in writing, software > * distributed under the License is distributed on an "AS IS" BASIS, > * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > * See the License for the specific language governing permissions and > * limitations under the License. > */ > > > for > > > /* > * Licensed to the Apache Software Foundation (ASF) under one > * or more contributor license agreements. See the NOTICE file > * distributed with this work for additional information > * regarding copyright ownership. The ASF licenses this file > * to you under the Apache License, Version 2.0 (the > * "License"); you may not use this file except in compliance > * with the License. You may obtain a copy of the License at > * > * http://www.apache.org/licenses/LICENSE-2.0 > * > * Unless required by applicable law or agreed to in writing, software > * distributed under the License is distributed on an "AS IS" BASIS, > * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > * See the License for the specific language governing permissions and > * limitations under the License. > */ > > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-crypto] arturobernalg opened a new pull request #113: [CRYPTO-154] - Dangling Javadoc comment
arturobernalg opened a new pull request #113: URL: https://github.com/apache/commons-crypto/pull/113 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
[jira] [Created] (CRYPTO-154) Dangling Javadoc comment
Arturo Bernal created CRYPTO-154: Summary: Dangling Javadoc comment Key: CRYPTO-154 URL: https://issues.apache.org/jira/browse/CRYPTO-154 Project: Commons Crypto Issue Type: Improvement Reporter: Arturo Bernal Remove double star /** * Licensed to the Apache Software Foundation (ASF) under one * or more contributor license agreements. See the NOTICE file * distributed with this work for additional information * regarding copyright ownership. The ASF licenses this file * to you under the Apache License, Version 2.0 (the * "License"); you may not use this file except in compliance * with the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ for /* * Licensed to the Apache Software Foundation (ASF) under one * or more contributor license agreements. See the NOTICE file * distributed with this work for additional information * regarding copyright ownership. The ASF licenses this file * to you under the Apache License, Version 2.0 (the * "License"); you may not use this file except in compliance * with the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] coveralls edited a comment on pull request #89: Replace FindBugs by SpotBugs, and suppress current issues
coveralls edited a comment on pull request #89: URL: https://github.com/apache/commons-imaging/pull/89#issuecomment-663934555 [](https://coveralls.io/builds/3547) Coverage increased (+0.005%) to 76.43% when pulling **506711743863b079703287f736a240383960bf90 on kinow:findbugs-2-spotbugs** into **01218150c258e3034ed1af1cf36e13533fb9defc 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
[jira] [Created] (MATH-1563) Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm
AVIJIT BASAK created MATH-1563: -- Summary: Implementation of Adaptive Probability Generation Strategy for Genetic Algorithm Key: MATH-1563 URL: https://issues.apache.org/jira/browse/MATH-1563 Project: Commons Math Issue Type: Improvement Reporter: AVIJIT BASAK In Genetic Algorithm probability of crossover and mutation operation can be generated in an adaptive manner. Some experiment was done related to this and published in this article "https://www.ijcaonline.org/archives/volume175/number10/basak-2020-ijca-920572.pdf;. Currently Apache's API works on constant probability strategy. I would like to propose incorporation of rank based adaptive probability generation strategy as described in the mentioned article. This will improve the performance and robustness of the algorithm and would make this more suitable for use in higher dimensional problems like machine learning or deep learning. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CRYPTO-153) Bump coveralls-maven-plugin from 3.1.0 to 4.3.0
[ https://issues.apache.org/jira/browse/CRYPTO-153?focusedWorklogId=520555=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520555 ] ASF GitHub Bot logged work on CRYPTO-153: - Author: ASF GitHub Bot Created on: 05/Dec/20 20:43 Start Date: 05/Dec/20 20:43 Worklog Time Spent: 10m Work Description: arturobernalg commented on pull request #112: URL: https://github.com/apache/commons-crypto/pull/112#issuecomment-739413467 idem --> Please help here @sebbASF @garydgregory @sundapeng 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: 520555) Time Spent: 20m (was: 10m) > Bump coveralls-maven-plugin from 3.1.0 to 4.3.0 > --- > > Key: CRYPTO-153 > URL: https://issues.apache.org/jira/browse/CRYPTO-153 > Project: Commons Crypto > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > The idea its update the version of coveralls in order to have the last one -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CRYPTO-152) Bump maven-antrun-plugin from 1.8 to 3.0.0
[ https://issues.apache.org/jira/browse/CRYPTO-152?focusedWorklogId=520554=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520554 ] ASF GitHub Bot logged work on CRYPTO-152: - Author: ASF GitHub Bot Created on: 05/Dec/20 20:43 Start Date: 05/Dec/20 20:43 Worklog Time Spent: 10m Work Description: arturobernalg commented on pull request #111: URL: https://github.com/apache/commons-crypto/pull/111#issuecomment-739413442 Idem --> Please help here @sebbASF @garydgregory @sundapeng 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: 520554) Time Spent: 1h 10m (was: 1h) > Bump maven-antrun-plugin from 1.8 to 3.0.0 > -- > > Key: CRYPTO-152 > URL: https://issues.apache.org/jira/browse/CRYPTO-152 > Project: Commons Crypto > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Minor > Labels: pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > Bump maven-antrun-plugin from 1.8 to 3.0.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-crypto] arturobernalg commented on pull request #112: [CRYPTO-153] - Bump coveralls-maven-plugin from 3.1.0 to 4.3.0
arturobernalg commented on pull request #112: URL: https://github.com/apache/commons-crypto/pull/112#issuecomment-739413467 idem --> Please help here @sebbASF @garydgregory @sundapeng 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
[GitHub] [commons-crypto] arturobernalg commented on pull request #111: [CRYPTO-152] - Bump maven-antrun-plugin from 1.8 to 3.0.0
arturobernalg commented on pull request #111: URL: https://github.com/apache/commons-crypto/pull/111#issuecomment-739413442 Idem --> Please help here @sebbASF @garydgregory @sundapeng 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
[jira] [Commented] (GEOMETRY-103) Migrate to JUnit 5
[ https://issues.apache.org/jira/browse/GEOMETRY-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244566#comment-17244566 ] Arturo Bernal commented on GEOMETRY-103: Hi [~mattjuntunen] What do you think if I do that as a sub task? I completely agree but I prefer do that in other jira cos I need to modify at lest commons-geometry-core commons-geometry-enclosing commons-geometry-euclidean commons-geometry-examples-io commons-geometry-spherical this module and --> !Screenshot 2020-12-05 at 21.27.20.png! > Migrate to JUnit 5 > -- > > Key: GEOMETRY-103 > URL: https://issues.apache.org/jira/browse/GEOMETRY-103 > Project: Apache Commons Geometry > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Labels: pull-request-available > Attachments: Screenshot 2020-12-05 at 21.27.20.png > > > the idea it's migrate all the project to JUnit 5 version -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEOMETRY-103) Migrate to JUnit 5
[ https://issues.apache.org/jira/browse/GEOMETRY-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal updated GEOMETRY-103: --- Attachment: Screenshot 2020-12-05 at 21.27.20.png > Migrate to JUnit 5 > -- > > Key: GEOMETRY-103 > URL: https://issues.apache.org/jira/browse/GEOMETRY-103 > Project: Apache Commons Geometry > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Labels: pull-request-available > Attachments: Screenshot 2020-12-05 at 21.27.20.png > > > the idea it's migrate all the project to JUnit 5 version -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-geometry] arturobernalg opened a new pull request #105: [GEOMETRY-104] - Add Dependabot config file
arturobernalg opened a new pull request #105: URL: https://github.com/apache/commons-geometry/pull/105 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
[jira] [Created] (GEOMETRY-104) Add Dependabot config file
Arturo Bernal created GEOMETRY-104: -- Summary: Add Dependabot config file Key: GEOMETRY-104 URL: https://issues.apache.org/jira/browse/GEOMETRY-104 Project: Apache Commons Geometry Issue Type: Improvement Reporter: Arturo Bernal The idea is Add Dependabot config file in oder to auto update the libs -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (LANG-1623) Add Dependabot config file
[ https://issues.apache.org/jira/browse/LANG-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal resolved LANG-1623. - Resolution: Fixed > Add Dependabot config file > -- > > Key: LANG-1623 > URL: https://issues.apache.org/jira/browse/LANG-1623 > Project: Commons Lang > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > > Add Dependabot config file in order to automatic update the libs -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (LANG-1623) Add Dependabot config file
[ https://issues.apache.org/jira/browse/LANG-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal closed LANG-1623. --- > Add Dependabot config file > -- > > Key: LANG-1623 > URL: https://issues.apache.org/jira/browse/LANG-1623 > Project: Commons Lang > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > > Add Dependabot config file in order to automatic update the libs -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (LANG-1623) Add Dependabot config file
Arturo Bernal created LANG-1623: --- Summary: Add Dependabot config file Key: LANG-1623 URL: https://issues.apache.org/jira/browse/LANG-1623 Project: Commons Lang Issue Type: Improvement Reporter: Arturo Bernal Add Dependabot config file in order to automatic update the libs -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CRYPTO-151) Migrate to Junit 5
[ https://issues.apache.org/jira/browse/CRYPTO-151?focusedWorklogId=520549=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520549 ] ASF GitHub Bot logged work on CRYPTO-151: - Author: ASF GitHub Bot Created on: 05/Dec/20 20:10 Start Date: 05/Dec/20 20:10 Worklog Time Spent: 10m Work Description: arturobernalg commented on pull request #109: URL: https://github.com/apache/commons-crypto/pull/109#issuecomment-739391947 Please help here @sebbASF @garydgregory @sundapeng 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: 520549) Time Spent: 0.5h (was: 20m) > Migrate to Junit 5 > -- > > Key: CRYPTO-151 > URL: https://issues.apache.org/jira/browse/CRYPTO-151 > Project: Commons Crypto > Issue Type: Improvement >Affects Versions: 1.1.0 >Reporter: Arturo Bernal >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-crypto] arturobernalg commented on pull request #109: [CRYPTO-151] - Migrate to Junit 5
arturobernalg commented on pull request #109: URL: https://github.com/apache/commons-crypto/pull/109#issuecomment-739391947 Please help here @sebbASF @garydgregory @sundapeng 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
[GitHub] [commons-geometry] arturobernalg commented on a change in pull request #104: [GEOMETRY-103] - Migrate to JUnit 5
arturobernalg commented on a change in pull request #104:
URL: https://github.com/apache/commons-geometry/pull/104#discussion_r536883746
##
File path:
commons-geometry-core/src/test/java/org/apache/commons/geometry/core/GeometryTestUtils.java
##
@@ -68,15 +68,15 @@ public static void assertThrows(final Runnable r, final
Class exceptionType)
public static void assertThrows(final Runnable r, final Class
exceptionType, final String message) {
try {
r.run();
-Assert.fail("Operation should have thrown an exception");
+Assertions.fail("Operation should have thrown an exception");
Review comment:
Hi @darkma773r ,
I completely agree with you. but, what do you think to do this in a separate
jira? as a upgrade?
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
[jira] [Comment Edited] (IO-693) FileUtils.deleteDirectory & PathUtils.deleteDirectory are behaving differently
[
https://issues.apache.org/jira/browse/IO-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244564#comment-17244564
]
Gary D. Gregory edited comment on IO-693 at 12/5/20, 7:30 PM:
--
[~xpyrus]
Thanks for your patience. Let's take these one API at a time.
Hm, I just added
{{org.apache.commons.io.FileUtilsTestCase.testForceDeleteReadOnlyFile()}}
May you please add a test that shows your failure?
See also:
- {{org.apache.commons.io.file.PathUtilsDeleteDirectoryTest}}
- {{org.apache.commons.io.file.PathUtilsDeleteFileTest}}
- {{org.apache.commons.io.file.PathUtilsDeleteTest}}
was (Author: garydgregory):
[~xpyrus]
Thanks for your patience. Let's take these one API at a time.
Hm, I just added
{{org.apache.commons.io.FileUtilsTestCase.testForceDeleteReadOnlyFile()}}
May you please add a test that shows your failure?
> FileUtils.deleteDirectory & PathUtils.deleteDirectory are behaving differently
> --
>
> Key: IO-693
> URL: https://issues.apache.org/jira/browse/IO-693
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Robert Seidel
>Priority: Major
>
> # With the newly added PathUtils, the behavior of FileUtils.deleteDirectory
> has changed. Now nio is used instead of the old File.delete. The problem is,
> nio does not delete files with read only attribute and failes instead.
> # The interface of FileUtils was not extended to provide the possibility to
> use a DeleteOption, so I guess, if someone wants to remove "all" files, then
> PathUtils should be used. But here comes the next problem,
> FileUtils.deleteDirectory checks for the existence (in opposite to its
> javadoc), where PathUtils.deleteDirectory does not. Thats very inconsistent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IO-693) FileUtils.deleteDirectory & PathUtils.deleteDirectory are behaving differently
[
https://issues.apache.org/jira/browse/IO-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244564#comment-17244564
]
Gary D. Gregory edited comment on IO-693 at 12/5/20, 7:25 PM:
--
[~xpyrus]
Thanks for your patience. Let's take these one API at a time.
Hm, I just added
{{org.apache.commons.io.FileUtilsTestCase.testForceDeleteReadOnlyFile()}}
May you please add a test that shows your failure?
was (Author: garydgregory):
[~xpyrus]
Thanks for your patience. Let's take these one API at a time.
Hm, I just added
{{org.apache.commons.io.FileUtilsTestCase.testForceDeleteReadOnlyFile()}}
> FileUtils.deleteDirectory & PathUtils.deleteDirectory are behaving differently
> --
>
> Key: IO-693
> URL: https://issues.apache.org/jira/browse/IO-693
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Robert Seidel
>Priority: Major
>
> # With the newly added PathUtils, the behavior of FileUtils.deleteDirectory
> has changed. Now nio is used instead of the old File.delete. The problem is,
> nio does not delete files with read only attribute and failes instead.
> # The interface of FileUtils was not extended to provide the possibility to
> use a DeleteOption, so I guess, if someone wants to remove "all" files, then
> PathUtils should be used. But here comes the next problem,
> FileUtils.deleteDirectory checks for the existence (in opposite to its
> javadoc), where PathUtils.deleteDirectory does not. Thats very inconsistent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IO-693) FileUtils.deleteDirectory & PathUtils.deleteDirectory are behaving differently
[
https://issues.apache.org/jira/browse/IO-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244564#comment-17244564
]
Gary D. Gregory commented on IO-693:
[~xpyrus]
Thanks for your patience. Let's take these one API at a time.
Hm, I just added
{{org.apache.commons.io.FileUtilsTestCase.testForceDeleteReadOnlyFile()}}
> FileUtils.deleteDirectory & PathUtils.deleteDirectory are behaving differently
> --
>
> Key: IO-693
> URL: https://issues.apache.org/jira/browse/IO-693
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Robert Seidel
>Priority: Major
>
> # With the newly added PathUtils, the behavior of FileUtils.deleteDirectory
> has changed. Now nio is used instead of the old File.delete. The problem is,
> nio does not delete files with read only attribute and failes instead.
> # The interface of FileUtils was not extended to provide the possibility to
> use a DeleteOption, so I guess, if someone wants to remove "all" files, then
> PathUtils should be used. But here comes the next problem,
> FileUtils.deleteDirectory checks for the existence (in opposite to its
> javadoc), where PathUtils.deleteDirectory does not. Thats very inconsistent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (LANG-1580) Refine StringUtils.deleteWhitespace
[ https://issues.apache.org/jira/browse/LANG-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved LANG-1580. --- Fix Version/s: 3.12 Resolution: Fixed > Refine StringUtils.deleteWhitespace > --- > > Key: LANG-1580 > URL: https://issues.apache.org/jira/browse/LANG-1580 > Project: Commons Lang > Issue Type: Sub-task >Reporter: Jin Xu >Priority: Minor > Fix For: 3.12 > > Time Spent: 0.5h > Remaining Estimate: 0h > > [https://github.com/apache/commons-lang/pull/569] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (LANG-1580) Refine StringUtils.deleteWhitespace
[ https://issues.apache.org/jira/browse/LANG-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated LANG-1580: -- Summary: Refine StringUtils.deleteWhitespace (was: refine StringUtils.deleteWhitespace) > Refine StringUtils.deleteWhitespace > --- > > Key: LANG-1580 > URL: https://issues.apache.org/jira/browse/LANG-1580 > Project: Commons Lang > Issue Type: Sub-task >Reporter: Jin Xu >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > [https://github.com/apache/commons-lang/pull/569] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (LANG-1580) refine StringUtils.deleteWhitespace
[ https://issues.apache.org/jira/browse/LANG-1580?focusedWorklogId=520524=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520524 ] ASF GitHub Bot logged work on LANG-1580: Author: ASF GitHub Bot Created on: 05/Dec/20 17:31 Start Date: 05/Dec/20 17:31 Worklog Time Spent: 10m Work Description: garydgregory merged pull request #569: URL: https://github.com/apache/commons-lang/pull/569 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: 520524) Time Spent: 0.5h (was: 20m) > refine StringUtils.deleteWhitespace > --- > > Key: LANG-1580 > URL: https://issues.apache.org/jira/browse/LANG-1580 > Project: Commons Lang > Issue Type: Sub-task >Reporter: Jin Xu >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > [https://github.com/apache/commons-lang/pull/569] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] garydgregory merged pull request #569: [LANG-1580] refine StringUtils.deleteWhitespace
garydgregory merged pull request #569: URL: https://github.com/apache/commons-lang/pull/569 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
[jira] [Updated] (LANG-1620) Refine StringUtils.lastIndexOfIgnoreCase
[
https://issues.apache.org/jira/browse/LANG-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LANG-1620:
--
Summary: Refine StringUtils.lastIndexOfIgnoreCase (was: refine
StringUtils.lastIndexOfIgnoreCase)
> Refine StringUtils.lastIndexOfIgnoreCase
>
>
> Key: LANG-1620
> URL: https://issues.apache.org/jira/browse/LANG-1620
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Arturo Bernal
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.12
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Avoid Multiple calls to calculate the length of the chain
>
> {code:java}
> final int searchStrLength = searchStr.length();
> final int strLength = str.length();
> {code}
> https://github.com/apache/commons-lang/pull/664
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (LANG-1584) refine StringUtils.isNumericSpace
[ https://issues.apache.org/jira/browse/LANG-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved LANG-1584. --- Fix Version/s: 3.12 Resolution: Fixed > refine StringUtils.isNumericSpace > -- > > Key: LANG-1584 > URL: https://issues.apache.org/jira/browse/LANG-1584 > Project: Commons Lang > Issue Type: Sub-task >Reporter: Jin Xu >Priority: Minor > Fix For: 3.12 > > Time Spent: 0.5h > Remaining Estimate: 0h > > https://github.com/apache/commons-lang/pull/573 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (LANG-1584) Refine StringUtils.isNumericSpace
[ https://issues.apache.org/jira/browse/LANG-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated LANG-1584: -- Summary: Refine StringUtils.isNumericSpace (was: refine StringUtils.isNumericSpace ) > Refine StringUtils.isNumericSpace > -- > > Key: LANG-1584 > URL: https://issues.apache.org/jira/browse/LANG-1584 > Project: Commons Lang > Issue Type: Sub-task >Reporter: Jin Xu >Priority: Minor > Fix For: 3.12 > > Time Spent: 0.5h > Remaining Estimate: 0h > > https://github.com/apache/commons-lang/pull/573 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (LANG-1584) refine StringUtils.isNumericSpace
[ https://issues.apache.org/jira/browse/LANG-1584?focusedWorklogId=520522=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520522 ] ASF GitHub Bot logged work on LANG-1584: Author: ASF GitHub Bot Created on: 05/Dec/20 17:24 Start Date: 05/Dec/20 17:24 Worklog Time Spent: 10m Work Description: garydgregory merged pull request #573: URL: https://github.com/apache/commons-lang/pull/573 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: 520522) Time Spent: 0.5h (was: 20m) > refine StringUtils.isNumericSpace > -- > > Key: LANG-1584 > URL: https://issues.apache.org/jira/browse/LANG-1584 > Project: Commons Lang > Issue Type: Sub-task >Reporter: Jin Xu >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > https://github.com/apache/commons-lang/pull/573 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] garydgregory merged pull request #573: [LANG-1584] Refine StringUtils.isNumericSpace
garydgregory merged pull request #573: URL: https://github.com/apache/commons-lang/pull/573 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
[jira] [Resolved] (LANG-1619) Refine StringUtils.abbreviate
[
https://issues.apache.org/jira/browse/LANG-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LANG-1619.
---
Fix Version/s: 3.12
Resolution: Fixed
> Refine StringUtils.abbreviate
> -
>
> Key: LANG-1619
> URL: https://issues.apache.org/jira/browse/LANG-1619
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Arturo Bernal
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.12
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Avoid Multiple calls to calculate the length of the chain
>
> [https://github.com/apache/commons-lang/pull/663]
> {code:java}
> public static String abbreviate(final String str, final String abbrevMarker,
> int offset, final int maxWidth) {
> if (isNotEmpty(str) && EMPTY.equals(abbrevMarker) && maxWidth > 0) {
> return substring(str, 0, maxWidth);
> } else if (isAnyEmpty(str, abbrevMarker)) {
> return str;
> }
> final int abbrevMarkerLength = abbrevMarker.length();
> final int minAbbrevWidth = abbrevMarkerLength + 1;
> final int minAbbrevWidthOffset = abbrevMarkerLength +
> abbrevMarkerLength + 1;
> if (maxWidth < minAbbrevWidth) {
> throw new IllegalArgumentException(String.format("Minimum
> abbreviation width is %d", minAbbrevWidth));
> }
> final int strLen = str.length();
> if (strLen <= maxWidth) {
> return str;
> }
> if (offset > strLen) {
> offset = strLen;
> }
> if (strLen - offset < maxWidth - abbrevMarkerLength) {
> offset = strLen - (maxWidth - abbrevMarkerLength);
> }
> if (offset <= abbrevMarkerLength+1) {
> return str.substring(0, maxWidth - abbrevMarkerLength) +
> abbrevMarker;
> }
> if (maxWidth < minAbbrevWidthOffset) {
> throw new IllegalArgumentException(String.format("Minimum
> abbreviation width with offset is %d", minAbbrevWidthOffset));
> }
> if (offset + maxWidth - abbrevMarkerLength < strLen) {
> return abbrevMarker + abbreviate(str.substring(offset),
> abbrevMarker, maxWidth - abbrevMarkerLength);
> }
> return abbrevMarker + str.substring(strLen - (maxWidth -
> abbrevMarkerLength));
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (LANG-1619) Refine StringUtils.abbreviate
[
https://issues.apache.org/jira/browse/LANG-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated LANG-1619:
--
Summary: Refine StringUtils.abbreviate (was: refine StringUtils.abbreviate)
> Refine StringUtils.abbreviate
> -
>
> Key: LANG-1619
> URL: https://issues.apache.org/jira/browse/LANG-1619
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Arturo Bernal
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Avoid Multiple calls to calculate the length of the chain
>
> [https://github.com/apache/commons-lang/pull/663]
> {code:java}
> public static String abbreviate(final String str, final String abbrevMarker,
> int offset, final int maxWidth) {
> if (isNotEmpty(str) && EMPTY.equals(abbrevMarker) && maxWidth > 0) {
> return substring(str, 0, maxWidth);
> } else if (isAnyEmpty(str, abbrevMarker)) {
> return str;
> }
> final int abbrevMarkerLength = abbrevMarker.length();
> final int minAbbrevWidth = abbrevMarkerLength + 1;
> final int minAbbrevWidthOffset = abbrevMarkerLength +
> abbrevMarkerLength + 1;
> if (maxWidth < minAbbrevWidth) {
> throw new IllegalArgumentException(String.format("Minimum
> abbreviation width is %d", minAbbrevWidth));
> }
> final int strLen = str.length();
> if (strLen <= maxWidth) {
> return str;
> }
> if (offset > strLen) {
> offset = strLen;
> }
> if (strLen - offset < maxWidth - abbrevMarkerLength) {
> offset = strLen - (maxWidth - abbrevMarkerLength);
> }
> if (offset <= abbrevMarkerLength+1) {
> return str.substring(0, maxWidth - abbrevMarkerLength) +
> abbrevMarker;
> }
> if (maxWidth < minAbbrevWidthOffset) {
> throw new IllegalArgumentException(String.format("Minimum
> abbreviation width with offset is %d", minAbbrevWidthOffset));
> }
> if (offset + maxWidth - abbrevMarkerLength < strLen) {
> return abbrevMarker + abbreviate(str.substring(offset),
> abbrevMarker, maxWidth - abbrevMarkerLength);
> }
> return abbrevMarker + str.substring(strLen - (maxWidth -
> abbrevMarkerLength));
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1619) refine StringUtils.abbreviate
[
https://issues.apache.org/jira/browse/LANG-1619?focusedWorklogId=520521=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520521
]
ASF GitHub Bot logged work on LANG-1619:
Author: ASF GitHub Bot
Created on: 05/Dec/20 17:20
Start Date: 05/Dec/20 17:20
Worklog Time Spent: 10m
Work Description: garydgregory merged pull request #663:
URL: https://github.com/apache/commons-lang/pull/663
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: 520521)
Time Spent: 50m (was: 40m)
> refine StringUtils.abbreviate
> -
>
> Key: LANG-1619
> URL: https://issues.apache.org/jira/browse/LANG-1619
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Arturo Bernal
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Avoid Multiple calls to calculate the length of the chain
>
> [https://github.com/apache/commons-lang/pull/663]
> {code:java}
> public static String abbreviate(final String str, final String abbrevMarker,
> int offset, final int maxWidth) {
> if (isNotEmpty(str) && EMPTY.equals(abbrevMarker) && maxWidth > 0) {
> return substring(str, 0, maxWidth);
> } else if (isAnyEmpty(str, abbrevMarker)) {
> return str;
> }
> final int abbrevMarkerLength = abbrevMarker.length();
> final int minAbbrevWidth = abbrevMarkerLength + 1;
> final int minAbbrevWidthOffset = abbrevMarkerLength +
> abbrevMarkerLength + 1;
> if (maxWidth < minAbbrevWidth) {
> throw new IllegalArgumentException(String.format("Minimum
> abbreviation width is %d", minAbbrevWidth));
> }
> final int strLen = str.length();
> if (strLen <= maxWidth) {
> return str;
> }
> if (offset > strLen) {
> offset = strLen;
> }
> if (strLen - offset < maxWidth - abbrevMarkerLength) {
> offset = strLen - (maxWidth - abbrevMarkerLength);
> }
> if (offset <= abbrevMarkerLength+1) {
> return str.substring(0, maxWidth - abbrevMarkerLength) +
> abbrevMarker;
> }
> if (maxWidth < minAbbrevWidthOffset) {
> throw new IllegalArgumentException(String.format("Minimum
> abbreviation width with offset is %d", minAbbrevWidthOffset));
> }
> if (offset + maxWidth - abbrevMarkerLength < strLen) {
> return abbrevMarker + abbreviate(str.substring(offset),
> abbrevMarker, maxWidth - abbrevMarkerLength);
> }
> return abbrevMarker + str.substring(strLen - (maxWidth -
> abbrevMarkerLength));
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] garydgregory merged pull request #663: [LANG-1619] - refine StringUtils.abbreviate
garydgregory merged pull request #663: URL: https://github.com/apache/commons-lang/pull/663 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
[jira] [Resolved] (LANG-1620) refine StringUtils.lastIndexOfIgnoreCase
[
https://issues.apache.org/jira/browse/LANG-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LANG-1620.
---
Fix Version/s: 3.12
Resolution: Fixed
> refine StringUtils.lastIndexOfIgnoreCase
>
>
> Key: LANG-1620
> URL: https://issues.apache.org/jira/browse/LANG-1620
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Arturo Bernal
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.12
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Avoid Multiple calls to calculate the length of the chain
>
> {code:java}
> final int searchStrLength = searchStr.length();
> final int strLength = str.length();
> {code}
> https://github.com/apache/commons-lang/pull/664
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1620) refine StringUtils.lastIndexOfIgnoreCase
[
https://issues.apache.org/jira/browse/LANG-1620?focusedWorklogId=520518=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520518
]
ASF GitHub Bot logged work on LANG-1620:
Author: ASF GitHub Bot
Created on: 05/Dec/20 17:16
Start Date: 05/Dec/20 17:16
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #664:
URL: https://github.com/apache/commons-lang/pull/664#issuecomment-739323081
No need for a JIRA for this kind of issues when the changes are so minor.
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: 520518)
Time Spent: 50m (was: 40m)
> refine StringUtils.lastIndexOfIgnoreCase
>
>
> Key: LANG-1620
> URL: https://issues.apache.org/jira/browse/LANG-1620
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Arturo Bernal
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Avoid Multiple calls to calculate the length of the chain
>
> {code:java}
> final int searchStrLength = searchStr.length();
> final int strLength = str.length();
> {code}
> https://github.com/apache/commons-lang/pull/664
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-1620) refine StringUtils.lastIndexOfIgnoreCase
[
https://issues.apache.org/jira/browse/LANG-1620?focusedWorklogId=520519=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520519
]
ASF GitHub Bot logged work on LANG-1620:
Author: ASF GitHub Bot
Created on: 05/Dec/20 17:16
Start Date: 05/Dec/20 17:16
Worklog Time Spent: 10m
Work Description: garydgregory merged pull request #664:
URL: https://github.com/apache/commons-lang/pull/664
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: 520519)
Time Spent: 1h (was: 50m)
> refine StringUtils.lastIndexOfIgnoreCase
>
>
> Key: LANG-1620
> URL: https://issues.apache.org/jira/browse/LANG-1620
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Arturo Bernal
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Avoid Multiple calls to calculate the length of the chain
>
> {code:java}
> final int searchStrLength = searchStr.length();
> final int strLength = str.length();
> {code}
> https://github.com/apache/commons-lang/pull/664
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] garydgregory merged pull request #664: [LANG-1620] - refine StringUtils.lastIndexOfIgnoreCase
garydgregory merged pull request #664: URL: https://github.com/apache/commons-lang/pull/664 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
[GitHub] [commons-lang] garydgregory commented on pull request #664: [LANG-1620] - refine StringUtils.lastIndexOfIgnoreCase
garydgregory commented on pull request #664: URL: https://github.com/apache/commons-lang/pull/664#issuecomment-739323081 No need for a JIRA for this kind of issues when the changes are so minor. 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
[jira] [Work logged] (LANG-1620) refine StringUtils.lastIndexOfIgnoreCase
[
https://issues.apache.org/jira/browse/LANG-1620?focusedWorklogId=520517=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520517
]
ASF GitHub Bot logged work on LANG-1620:
Author: ASF GitHub Bot
Created on: 05/Dec/20 17:15
Start Date: 05/Dec/20 17:15
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #664:
URL: https://github.com/apache/commons-lang/pull/664#issuecomment-739322983
Minor improvement, but ok, sure.
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: 520517)
Time Spent: 40m (was: 0.5h)
> refine StringUtils.lastIndexOfIgnoreCase
>
>
> Key: LANG-1620
> URL: https://issues.apache.org/jira/browse/LANG-1620
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Arturo Bernal
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Avoid Multiple calls to calculate the length of the chain
>
> {code:java}
> final int searchStrLength = searchStr.length();
> final int strLength = str.length();
> {code}
> https://github.com/apache/commons-lang/pull/664
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] garydgregory commented on pull request #664: [LANG-1620] - refine StringUtils.lastIndexOfIgnoreCase
garydgregory commented on pull request #664: URL: https://github.com/apache/commons-lang/pull/664#issuecomment-739322983 Minor improvement, but ok, sure. 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
[GitHub] [commons-lang] garydgregory merged pull request #660: Bump maven-pmd-plugin from 3.13.0 to 3.14.0
garydgregory merged pull request #660: URL: https://github.com/apache/commons-lang/pull/660 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
[GitHub] [commons-lang] garydgregory merged pull request #662: Bump junit-pioneer from 1.0.0 to 1.1.0
garydgregory merged pull request #662: URL: https://github.com/apache/commons-lang/pull/662 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
[GitHub] [commons-lang] garydgregory merged pull request #665: Bump checkstyle from 8.37 to 8.38
garydgregory merged pull request #665: URL: https://github.com/apache/commons-lang/pull/665 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
[jira] [Work logged] (LANG-1622) Javadoc of some methods incorrectly refers to another method
[
https://issues.apache.org/jira/browse/LANG-1622?focusedWorklogId=520507=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520507
]
ASF GitHub Bot logged work on LANG-1622:
Author: ASF GitHub Bot
Created on: 05/Dec/20 16:20
Start Date: 05/Dec/20 16:20
Worklog Time Spent: 10m
Work Description: garydgregory merged pull request #670:
URL: https://github.com/apache/commons-lang/pull/670
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: 520507)
Time Spent: 1.5h (was: 1h 20m)
> Javadoc of some methods incorrectly refers to another method
>
>
> Key: LANG-1622
> URL: https://issues.apache.org/jira/browse/LANG-1622
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.11
>Reporter: Ludek
>Priority: Trivial
> Labels: StringUtils
> Fix For: 3.12
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> two examples in javadoc of StringUtils.isNumericSpace incorrectly refer to
> {color:#172b4d}isNumeric{color}
>
> {color:#808080}* StringUtils.isNumeric("\u0967\u0968\u0969") =
> true{color}{color:#808080}* StringUtils.isNumeric("\u0967\u0968 \u0969") =
> true{color}
> {color:#ff00dc} {color}
> {color:#172b4d}and same for BooleanUtils.toBoolean{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] garydgregory merged pull request #670: [LANG-1622] Javadoc of BooleanUtils incorrectly refers to another method
garydgregory merged pull request #670: URL: https://github.com/apache/commons-lang/pull/670 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
[jira] [Work logged] (LANG-1622) Javadoc of some methods incorrectly refers to another method
[
https://issues.apache.org/jira/browse/LANG-1622?focusedWorklogId=520506=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520506
]
ASF GitHub Bot logged work on LANG-1622:
Author: ASF GitHub Bot
Created on: 05/Dec/20 16:17
Start Date: 05/Dec/20 16:17
Worklog Time Spent: 10m
Work Description: garydgregory merged pull request #667:
URL: https://github.com/apache/commons-lang/pull/667
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: 520506)
Time Spent: 1h 20m (was: 1h 10m)
> Javadoc of some methods incorrectly refers to another method
>
>
> Key: LANG-1622
> URL: https://issues.apache.org/jira/browse/LANG-1622
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.11
>Reporter: Ludek
>Priority: Trivial
> Labels: StringUtils
> Fix For: 3.12
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> two examples in javadoc of StringUtils.isNumericSpace incorrectly refer to
> {color:#172b4d}isNumeric{color}
>
> {color:#808080}* StringUtils.isNumeric("\u0967\u0968\u0969") =
> true{color}{color:#808080}* StringUtils.isNumeric("\u0967\u0968 \u0969") =
> true{color}
> {color:#ff00dc} {color}
> {color:#172b4d}and same for BooleanUtils.toBoolean{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] garydgregory merged pull request #667: [LANG-1622] Corrected reference to right methods.
garydgregory merged pull request #667: URL: https://github.com/apache/commons-lang/pull/667 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
[jira] [Work logged] (COLLECTIONS-768) Flat3MapTest.tesetEntrySet() is flaky
[
https://issues.apache.org/jira/browse/COLLECTIONS-768?focusedWorklogId=520502=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520502
]
ASF GitHub Bot logged work on COLLECTIONS-768:
--
Author: ASF GitHub Bot
Created on: 05/Dec/20 15:49
Start Date: 05/Dec/20 15:49
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #189:
URL:
https://github.com/apache/commons-collections/pull/189#issuecomment-739312957
@tongxin97
I do not think so.
While it is not documented, the iteration order for a Flat3Map is in fact
predictable when the size <= 3, and this is in fact checked, intentionally or
not by the test.
So this PR fixes the sanity check portion of test and looses the ordering
test for the map we actually want to test.
Therefore, the simple fix should be for the sanity check to use a
`LinkedHashMap` instead of a `HashMap`, like this:
```
public void testEntrySet() {
// Sanity check
putAndRemove(new LinkedHashMap<>());
// Actual test
putAndRemove(new Flat3Map<>());
}
```
This is presumably the intent of the test since the `putAndRemove` test
method uses exactly three entries which matches exactly the intended size of
useful Flat3Map instances.
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: 520502)
Time Spent: 2h 20m (was: 2h 10m)
> Flat3MapTest.tesetEntrySet() is flaky
> -
>
> Key: COLLECTIONS-768
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-768
> Project: Commons Collections
> Issue Type: Bug
> Components: Map
>Affects Versions: 4.4
>Reporter: XinT
>Priority: Minor
> Labels: easyfix, pull-request-available
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> The testEntrySet() function
> (org.apache.commons.collections4.map.Flat3MapTest#testEntrySet) is flaky
> because it uses a flaky helper function putAndRemove(). The helper function
> wrongly assumes that map iterators execute in insertion order, while in fact
> it can be any order.
> The current test asserts the last element iterated (and subsequently removed)
> is the last element inserted. Therefore, the test passes when it so happens
> that the last iterated element is the last inserted element, but fails
> otherwise.
>
> The proposed fix is: https://github.com/apache/commons-collections/pull/189
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-collections] garydgregory commented on pull request #189: [COLLECTIONS-768] Fix flaky Flat3MapTest.testEntrySet()
garydgregory commented on pull request #189:
URL:
https://github.com/apache/commons-collections/pull/189#issuecomment-739312957
@tongxin97
I do not think so.
While it is not documented, the iteration order for a Flat3Map is in fact
predictable when the size <= 3, and this is in fact checked, intentionally or
not by the test.
So this PR fixes the sanity check portion of test and looses the ordering
test for the map we actually want to test.
Therefore, the simple fix should be for the sanity check to use a
`LinkedHashMap` instead of a `HashMap`, like this:
```
public void testEntrySet() {
// Sanity check
putAndRemove(new LinkedHashMap<>());
// Actual test
putAndRemove(new Flat3Map<>());
}
```
This is presumably the intent of the test since the `putAndRemove` test
method uses exactly three entries which matches exactly the intended size of
useful Flat3Map instances.
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
[jira] [Commented] (GEOMETRY-103) Migrate to JUnit 5
[ https://issues.apache.org/jira/browse/GEOMETRY-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244522#comment-17244522 ] Matt Juntunen commented on GEOMETRY-103: Thanks for the contribution! I've added some comments on the Github PR. > Migrate to JUnit 5 > -- > > Key: GEOMETRY-103 > URL: https://issues.apache.org/jira/browse/GEOMETRY-103 > Project: Apache Commons Geometry > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Labels: pull-request-available > > the idea it's migrate all the project to JUnit 5 version -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-geometry] darkma773r commented on a change in pull request #104: [GEOMETRY-103] - Migrate to JUnit 5
darkma773r commented on a change in pull request #104:
URL: https://github.com/apache/commons-geometry/pull/104#discussion_r536811344
##
File path:
commons-geometry-core/src/test/java/org/apache/commons/geometry/core/GeometryTestUtils.java
##
@@ -68,15 +68,15 @@ public static void assertThrows(final Runnable r, final
Class exceptionType)
public static void assertThrows(final Runnable r, final Class
exceptionType, final String message) {
try {
r.run();
-Assert.fail("Operation should have thrown an exception");
+Assertions.fail("Operation should have thrown an exception");
Review comment:
Could this entire method be replaced with the JUnit assertThrows?
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
[jira] [Work logged] (COLLECTIONS-768) Flat3MapTest.tesetEntrySet() is flaky
[ https://issues.apache.org/jira/browse/COLLECTIONS-768?focusedWorklogId=520501=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520501 ] ASF GitHub Bot logged work on COLLECTIONS-768: -- Author: ASF GitHub Bot Created on: 05/Dec/20 15:40 Start Date: 05/Dec/20 15:40 Worklog Time Spent: 10m Work Description: tongxin97 commented on pull request #189: URL: https://github.com/apache/commons-collections/pull/189#issuecomment-739309631 @garydgregory thanks for taking a look. Do you think this is a valid fix? 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: 520501) Time Spent: 2h 10m (was: 2h) > Flat3MapTest.tesetEntrySet() is flaky > - > > Key: COLLECTIONS-768 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-768 > Project: Commons Collections > Issue Type: Bug > Components: Map >Affects Versions: 4.4 >Reporter: XinT >Priority: Minor > Labels: easyfix, pull-request-available > Time Spent: 2h 10m > Remaining Estimate: 0h > > The testEntrySet() function > (org.apache.commons.collections4.map.Flat3MapTest#testEntrySet) is flaky > because it uses a flaky helper function putAndRemove(). The helper function > wrongly assumes that map iterators execute in insertion order, while in fact > it can be any order. > The current test asserts the last element iterated (and subsequently removed) > is the last element inserted. Therefore, the test passes when it so happens > that the last iterated element is the last inserted element, but fails > otherwise. > > The proposed fix is: https://github.com/apache/commons-collections/pull/189 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-collections] tongxin97 commented on pull request #189: [COLLECTIONS-768] Fix flaky Flat3MapTest.testEntrySet()
tongxin97 commented on pull request #189: URL: https://github.com/apache/commons-collections/pull/189#issuecomment-739309631 @garydgregory thanks for taking a look. Do you think this is a valid fix? 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
[jira] [Work logged] (COLLECTIONS-768) Flat3MapTest.tesetEntrySet() is flaky
[ https://issues.apache.org/jira/browse/COLLECTIONS-768?focusedWorklogId=520500=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520500 ] ASF GitHub Bot logged work on COLLECTIONS-768: -- Author: ASF GitHub Bot Created on: 05/Dec/20 15:37 Start Date: 05/Dec/20 15:37 Worklog Time Spent: 10m Work Description: garydgregory commented on pull request #189: URL: https://github.com/apache/commons-collections/pull/189#issuecomment-739306828 FYI `Flat3Map` make no order guarantee just like `Map`. 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: 520500) Time Spent: 2h (was: 1h 50m) > Flat3MapTest.tesetEntrySet() is flaky > - > > Key: COLLECTIONS-768 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-768 > Project: Commons Collections > Issue Type: Bug > Components: Map >Affects Versions: 4.4 >Reporter: XinT >Priority: Minor > Labels: easyfix, pull-request-available > Time Spent: 2h > Remaining Estimate: 0h > > The testEntrySet() function > (org.apache.commons.collections4.map.Flat3MapTest#testEntrySet) is flaky > because it uses a flaky helper function putAndRemove(). The helper function > wrongly assumes that map iterators execute in insertion order, while in fact > it can be any order. > The current test asserts the last element iterated (and subsequently removed) > is the last element inserted. Therefore, the test passes when it so happens > that the last iterated element is the last inserted element, but fails > otherwise. > > The proposed fix is: https://github.com/apache/commons-collections/pull/189 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-collections] garydgregory commented on pull request #189: [COLLECTIONS-768] Fix flaky Flat3MapTest.testEntrySet()
garydgregory commented on pull request #189: URL: https://github.com/apache/commons-collections/pull/189#issuecomment-739306828 FYI `Flat3Map` make no order guarantee just like `Map`. 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
[jira] [Updated] (COLLECTIONS-775) CollectionUtilsTest.getFromMap() is flaky
[
https://issues.apache.org/jira/browse/COLLECTIONS-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated COLLECTIONS-775:
External issue URL: https://github.com/apache/commons-collections/pull/200
> CollectionUtilsTest.getFromMap() is flaky
> -
>
> Key: COLLECTIONS-775
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-775
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 4.4
>Reporter: XinT
>Priority: Minor
> Labels: pull-request-available, test
> Time Spent: 40m
> Remaining Estimate: 0h
>
> CollectionUtilsTest.getFromMap() is flaky on line 996: assertEquals(expected,
> found). We can get the following failure:
> [ERROR] CollectionUtilsTest.getFromMap:996 expected:<\{oneKey=one,
> zeroKey=zero}> but was:<\{oneKey=one}>
>
> The flakiness is introduced by calls to CollectionUtils.get(expected, 0) and
> CollectionUtils.get(expected, 1). Because CollectionUtils.get() uses a new
> Java Iterator each time it is called, it's possible that get(0) != get(0) and
> get(0) = get(1) in two subsequent calls to the "expected" HashMap. The end
> result is we may have only added \{oneKey=one} or \{zeroKey=zero}, but not
> both, to the "found" HashMap.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (COLLECTIONS-775) CollectionUtilsTest.getFromMap() is flaky
[
https://issues.apache.org/jira/browse/COLLECTIONS-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved COLLECTIONS-775.
-
Fix Version/s: 4.5
Resolution: Fixed
> CollectionUtilsTest.getFromMap() is flaky
> -
>
> Key: COLLECTIONS-775
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-775
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 4.4
>Reporter: XinT
>Priority: Minor
> Labels: pull-request-available, test
> Fix For: 4.5
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> CollectionUtilsTest.getFromMap() is flaky on line 996: assertEquals(expected,
> found). We can get the following failure:
> [ERROR] CollectionUtilsTest.getFromMap:996 expected:<\{oneKey=one,
> zeroKey=zero}> but was:<\{oneKey=one}>
>
> The flakiness is introduced by calls to CollectionUtils.get(expected, 0) and
> CollectionUtils.get(expected, 1). Because CollectionUtils.get() uses a new
> Java Iterator each time it is called, it's possible that get(0) != get(0) and
> get(0) = get(1) in two subsequent calls to the "expected" HashMap. The end
> result is we may have only added \{oneKey=one} or \{zeroKey=zero}, but not
> both, to the "found" HashMap.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-775) CollectionUtilsTest.getFromMap() is flaky
[
https://issues.apache.org/jira/browse/COLLECTIONS-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244520#comment-17244520
]
Gary D. Gregory commented on COLLECTIONS-775:
-
Hi [~xint5]
Merged in git master. I also broke up the test and added a new one for ORDERED
maps like {{LinkedHashMap}}.
Please verify and close this ticket.
> CollectionUtilsTest.getFromMap() is flaky
> -
>
> Key: COLLECTIONS-775
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-775
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 4.4
>Reporter: XinT
>Priority: Minor
> Labels: pull-request-available, test
> Time Spent: 40m
> Remaining Estimate: 0h
>
> CollectionUtilsTest.getFromMap() is flaky on line 996: assertEquals(expected,
> found). We can get the following failure:
> [ERROR] CollectionUtilsTest.getFromMap:996 expected:<\{oneKey=one,
> zeroKey=zero}> but was:<\{oneKey=one}>
>
> The flakiness is introduced by calls to CollectionUtils.get(expected, 0) and
> CollectionUtils.get(expected, 1). Because CollectionUtils.get() uses a new
> Java Iterator each time it is called, it's possible that get(0) != get(0) and
> get(0) = get(1) in two subsequent calls to the "expected" HashMap. The end
> result is we may have only added \{oneKey=one} or \{zeroKey=zero}, but not
> both, to the "found" HashMap.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (COLLECTIONS-775) CollectionUtilsTest.getFromMap() is flaky
[
https://issues.apache.org/jira/browse/COLLECTIONS-775?focusedWorklogId=520497=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520497
]
ASF GitHub Bot logged work on COLLECTIONS-775:
--
Author: ASF GitHub Bot
Created on: 05/Dec/20 15:17
Start Date: 05/Dec/20 15:17
Worklog Time Spent: 10m
Work Description: garydgregory merged pull request #200:
URL: https://github.com/apache/commons-collections/pull/200
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: 520497)
Time Spent: 40m (was: 0.5h)
> CollectionUtilsTest.getFromMap() is flaky
> -
>
> Key: COLLECTIONS-775
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-775
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 4.4
>Reporter: XinT
>Priority: Minor
> Labels: pull-request-available, test
> Time Spent: 40m
> Remaining Estimate: 0h
>
> CollectionUtilsTest.getFromMap() is flaky on line 996: assertEquals(expected,
> found). We can get the following failure:
> [ERROR] CollectionUtilsTest.getFromMap:996 expected:<\{oneKey=one,
> zeroKey=zero}> but was:<\{oneKey=one}>
>
> The flakiness is introduced by calls to CollectionUtils.get(expected, 0) and
> CollectionUtils.get(expected, 1). Because CollectionUtils.get() uses a new
> Java Iterator each time it is called, it's possible that get(0) != get(0) and
> get(0) = get(1) in two subsequent calls to the "expected" HashMap. The end
> result is we may have only added \{oneKey=one} or \{zeroKey=zero}, but not
> both, to the "found" HashMap.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-collections] garydgregory merged pull request #200: [COLLECTIONS-775] Fix flaky CollectionUtilsTest.getFromMap()
garydgregory merged pull request #200: URL: https://github.com/apache/commons-collections/pull/200 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
[jira] [Commented] (VFS-790) VFS2 handles files with special characters incorrectly
[
https://issues.apache.org/jira/browse/VFS-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244514#comment-17244514
]
Gary D. Gregory commented on VFS-790:
-
[~vnashkev]
I added a different version of this test case here:
{{org.apache.commons.vfs2.provider.local.test.FileNameTests.testLocalFile()}}
Note that the above new test method creates a legal URI, it does not contain a
NB-SP char (0xA0).
Sadly, the URI class lets you create URIs with paths which contains character
that are not escaped which end up causing havoc later when you try to use them
as actual legal URIs when in fact they are not.
The bottom line is that one must sanitize URI input before creating them.
> VFS2 handles files with special characters incorrectly
> --
>
> Key: VFS-790
> URL: https://issues.apache.org/jira/browse/VFS-790
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2, 2.7.0
> Environment: windows 10
> java 8
> vfs 2.7
>Reporter: Vitali Nashkevich
>Priority: Major
> Attachments: LocalFileProviderTest.java
>
>
> The following Testcase fails :
>
> {code:java}
> @Test
> public final static void testLocalFile()
> throws Exception
> {
> final String prefix = new String(new char[] { '\u0074', '\u0065',
> '\u00a0', '\u0074' });
> final File f = File.createTempFile(prefix + "-" , "-" + prefix);
> assert f.exists();
>
> final URI uri = f.toURI();
>
> try ( final FileSystemManager m = VFS.getManager() )
> {
> try ( final FileObject s = m.resolveFile(uri) )
> {
> try ( final FileContent sourceContent = s.getContent() )
> {
> final long size = sourceContent.getSize();
> assert size==f.length();
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (COLLECTIONS-775) CollectionUtilsTest.getFromMap() is flaky
[
https://issues.apache.org/jira/browse/COLLECTIONS-775?focusedWorklogId=520495=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520495
]
ASF GitHub Bot logged work on COLLECTIONS-775:
--
Author: ASF GitHub Bot
Created on: 05/Dec/20 14:39
Start Date: 05/Dec/20 14:39
Worklog Time Spent: 10m
Work Description: tongxin97 commented on pull request #200:
URL:
https://github.com/apache/commons-collections/pull/200#issuecomment-739258842
Hi @kinow, are you going to merge this PR since it's accepted?
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: 520495)
Time Spent: 0.5h (was: 20m)
> CollectionUtilsTest.getFromMap() is flaky
> -
>
> Key: COLLECTIONS-775
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-775
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 4.4
>Reporter: XinT
>Priority: Minor
> Labels: pull-request-available, test
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> CollectionUtilsTest.getFromMap() is flaky on line 996: assertEquals(expected,
> found). We can get the following failure:
> [ERROR] CollectionUtilsTest.getFromMap:996 expected:<\{oneKey=one,
> zeroKey=zero}> but was:<\{oneKey=one}>
>
> The flakiness is introduced by calls to CollectionUtils.get(expected, 0) and
> CollectionUtils.get(expected, 1). Because CollectionUtils.get() uses a new
> Java Iterator each time it is called, it's possible that get(0) != get(0) and
> get(0) = get(1) in two subsequent calls to the "expected" HashMap. The end
> result is we may have only added \{oneKey=one} or \{zeroKey=zero}, but not
> both, to the "found" HashMap.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-collections] tongxin97 commented on pull request #200: [COLLECTIONS-775] Fix flaky CollectionUtilsTest.getFromMap()
tongxin97 commented on pull request #200: URL: https://github.com/apache/commons-collections/pull/200#issuecomment-739258842 Hi @kinow, are you going to merge this PR since it's accepted? 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
[jira] [Commented] (NET-686) Most files aren't downloaded completely from an FTP server
[ https://issues.apache.org/jira/browse/NET-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244507#comment-17244507 ] Gary D. Gregory commented on NET-686: - Hi [~vkhudenko] I'm afraid I can't do much for you here unless you can provide a test in a PR or you can talk through which code in NET is wrong. This is challenging I know, since you are dealing with a whole software stack involving Android. See my my previous comment https://issues.apache.org/jira/browse/NET-686?focusedCommentId=17221564=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17221564 > Most files aren't downloaded completely from an FTP server > -- > > Key: NET-686 > URL: https://issues.apache.org/jira/browse/NET-686 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6, 3.7.2 > Environment: Win 10 > Java 8 > Android Studio 3.6.1 (min SDK 24, target SDK 27) >Reporter: JRRR >Priority: Major > Attachments: 2a-original.png, 2b-corrupt.png, 2c-corrupt.png, > 5a-original.jpg, 5b-corrupt.jpg, 5c-corrupt.jpg, DownloadProblem.java > > > About a month ago I opened another > [issue|https://issues.apache.org/jira/browse/NET-684] that was closed because > it wasn't reproducible with macOS and a public FTP server. > Short summary: Downloading files from an FTP server results in these files > randomly missing bytes. It looks like the download always "completes" and > there are no error messages/exceptions but random bytes in random files are > simply skipped. Images (jpg & png) are usually affected more (up to 30, maybe > 40, bytes smaller than the original), and are then also visibly corrupt, than > text files (usually only 2-3 bytes smaller, rarely more). > I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK > 24, target SDK 27), which I'm testing with FTP servers in the same network > (1x Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what > method in the library I use (retrieveFile, retrieveFileStream, > sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a > single file that's corrupted. > I also tested the same code with public servers and even though I didn't have > a lot of time because those servers regularely delete uploaded files, I never > experienced said problem with them. > I even wrote my own mini-library (just for login/logout and download) using > Java's default "Socket" but I still had the same problem on Android Studio's > simulator/a real device. BUT: When I used the same code to create a small > Windows/Swing/Java app, there were no more corrupted files. > It looks like this bug is only affecting a very specific combination of > OS,...: > Android (emulator/real device) + Java (8) + FTP server in the same network > (accessed via IP) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-exec] garydgregory merged pull request #26: Java-style Array declaration and remove empty finally block
garydgregory merged pull request #26: URL: https://github.com/apache/commons-exec/pull/26 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
[jira] [Updated] (GEOMETRY-103) Migrate to JUnit 5
[ https://issues.apache.org/jira/browse/GEOMETRY-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal updated GEOMETRY-103: --- Labels: pull-request-available (was: pull pull-request-available) > Migrate to JUnit 5 > -- > > Key: GEOMETRY-103 > URL: https://issues.apache.org/jira/browse/GEOMETRY-103 > Project: Apache Commons Geometry > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Labels: pull-request-available > > the idea it's migrate all the project to JUnit 5 version -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEOMETRY-103) Migrate to JUnit 5
[ https://issues.apache.org/jira/browse/GEOMETRY-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal updated GEOMETRY-103: --- Labels: pull pull-request-available (was: ) > Migrate to JUnit 5 > -- > > Key: GEOMETRY-103 > URL: https://issues.apache.org/jira/browse/GEOMETRY-103 > Project: Apache Commons Geometry > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Labels: pull, pull-request-available > > the idea it's migrate all the project to JUnit 5 version -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-geometry] arturobernalg opened a new pull request #104: [GEOMETRY-103] - Migrate to JUnit 5
arturobernalg opened a new pull request #104: URL: https://github.com/apache/commons-geometry/pull/104 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
[jira] [Created] (GEOMETRY-103) Migrate to JUnit 5
Arturo Bernal created GEOMETRY-103: -- Summary: Migrate to JUnit 5 Key: GEOMETRY-103 URL: https://issues.apache.org/jira/browse/GEOMETRY-103 Project: Apache Commons Geometry Issue Type: Improvement Reporter: Arturo Bernal the idea it's migrate all the project to JUnit 5 version -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (NET-686) Most files aren't downloaded completely from an FTP server
[
https://issues.apache.org/jira/browse/NET-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244465#comment-17244465
]
Vitaliy Khudenko edited comment on NET-686 at 12/5/20, 11:57 AM:
-
Looks like I've encountered this issue too.
My setup is an Android app as an FTPS client (FTPSClient v3.7.2) running on a
physical device (Google Nexus, Android 8.1) or an emulator (Android 10) from
Android Studio (Win 10). VPN.
On the FTPS server I have 3 zip files (1, 4 and 74 KBytes).
Small files (1 and 4 KB) are never causing troubles. However for the largest
one the issue happens with ~25-33% probability.
The exact file size is 75'743 bytes. But it happens that only 75'741 bytes or
75'740 bytes is downloaded (missing just a few bytes) with no errors reported
by {{FTPSClient}}.
Here is my code (Kotlin):
{code:java}
private val CONNECT_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val SO_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val BUFFER_SIZE = 1024 // 1 KB
val client: FTPSClient = FTPSClient("TLS", false)
client.connectTimeout = CONNECT_TIMEOUT_MILLIS
client.connect(hostname, port)
client.soTimeout = SO_TIMEOUT_MILLIS
if (!FTPReply.isPositiveCompletion(client.replyCode)) {
throw Exception("FTP server refused connection")
}
if (!client.login(username, password)) {
throw Exception("FTP server refused to authenticate $username")
}
client.enterLocalPassiveMode()
client.bufferSize = BUFFER_SIZE
check(client.setFileType(FTP.BINARY_FILE_TYPE)) { "failure to set binary file
type for FTP connection" }
FileOutputStream(localTargetFile).use { outputStream: FileOutputStream ->
val status = client.retrieveFile(ftpFilePath, outputStream)
outputStream.flush()
check(status) { "negative retrieveFile status" } // throws Exception if
status is false, but status is always true
}
{code}
I tried to mitigate this with a retry mechanism where I would resume
downloading for the number of the missing bytes only (e.g. the second attempt
only fetches the last missing few bytes). But it still results in a corrupted
zip file, despite the total number of bytes is correct. Looks like the first
pass/attempt already brings a corrupted chunk, so resumed download does not
help:
{code:java}
repeat(ATTEMPTS_TO_DOWNLOAD) {
if (localTargetFile.exists()) {
client.restartOffset = localTargetFile.length()
FileOutputStream(localTargetFile, true)
} else {
FileOutputStream(localTargetFile)
}.use { outputStream: FileOutputStream ->
val status = client.retrieveFile(ftpFilePath, outputStream)
outputStream.flush()
check(status) { "negative retrieveFile status" } // throws Exception if
status is false, but status is always true
}
}{code}
The odd things I noticed (which is maybe due to FTPS server misconfig/missetup,
but FTPS server setup is beyond my control):
* {{FTPClient.mlistFile()}} always returns {{null}}
* I am not able to browse the FTPS content via WinSCP
was (Author: vkhudenko):
Looks like I've encountered this issue too.
My setup is an Android app as an FTPS client (FTPSClient v3.7.2) running on a
physical device (Google Nexus, Android 8.1) or an emulator (Android 10) from
Android Studio (Win 10). VPN.
On the FTPS server I have 3 zip files (1, 4 and 74 KBytes).
Small files (1 and 4 KB) are never causing troubles. However for the largest
one the issue happens with ~25-33% probability.
The exact file size is 75'743 bytes. But it happens that only 75'741 bytes or
75'740 bytes is downloaded (missing just a few bytes) with no errors reported
by {{FTPSClient}}.
Here is my code (Kotlin):
{code:java}
private val CONNECT_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val SO_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val BUFFER_SIZE = 1024 // 1 KB
val client: FTPSClient = FTPSClient("TLS", false)
client.connectTimeout = CONNECT_TIMEOUT_MILLIS
client.connect(hostname, port)
client.soTimeout = SO_TIMEOUT_MILLIS
if (!FTPReply.isPositiveCompletion(client.replyCode)) {
throw Exception("FTP server refused connection")
}
if (!client.login(username, password)) {
throw Exception("FTP server refused to authenticate $username")
}
client.enterLocalPassiveMode()
client.bufferSize = BUFFER_SIZE
check(client.setFileType(FTP.BINARY_FILE_TYPE)) { "failure to set binary file
type for FTP connection" }
FileOutputStream(localTargetFile).use { outputStream: FileOutputStream ->
val status = client.retrieveFile(ftpFilePath, outputStream)
outputStream.flush()
check(status) { "negative retrieveFile status" } // throws Exception if
status is false, but this is always true
}
{code}
I tried to mitigate this with a retry mechanism where I would resume
downloading for the number of the missing bytes only (e.g. the second attempt
only fetches the last missing few bytes). But it still results in a corrupted
zip
[jira] [Comment Edited] (NET-686) Most files aren't downloaded completely from an FTP server
[
https://issues.apache.org/jira/browse/NET-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244465#comment-17244465
]
Vitaliy Khudenko edited comment on NET-686 at 12/5/20, 11:56 AM:
-
Looks like I've encountered this issue too.
My setup is an Android app as an FTPS client (FTPSClient v3.7.2) running on a
physical device (Google Nexus, Android 8.1) or an emulator (Android 10) from
Android Studio (Win 10). VPN.
On the FTPS server I have 3 zip files (1, 4 and 74 KBytes).
Small files (1 and 4 KB) are never causing troubles. However for the largest
one the issue happens with ~25-33% probability.
The exact file size is 75'743 bytes. But it happens that only 75'741 bytes or
75'740 bytes is downloaded (missing just a few bytes) with no errors reported
by {{FTPSClient}}.
Here is my code (Kotlin):
{code:java}
private val CONNECT_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val SO_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val BUFFER_SIZE = 1024 // 1 KB
val client: FTPSClient = FTPSClient("TLS", false)
client.connectTimeout = CONNECT_TIMEOUT_MILLIS
client.connect(hostname, port)
client.soTimeout = SO_TIMEOUT_MILLIS
if (!FTPReply.isPositiveCompletion(client.replyCode)) {
throw Exception("FTP server refused connection")
}
if (!client.login(username, password)) {
throw Exception("FTP server refused to authenticate $username")
}
client.enterLocalPassiveMode()
client.bufferSize = BUFFER_SIZE
check(client.setFileType(FTP.BINARY_FILE_TYPE)) { "failure to set binary file
type for FTP connection" }
FileOutputStream(localTargetFile).use { outputStream: FileOutputStream ->
val status = client.retrieveFile(ftpFilePath, outputStream)
outputStream.flush()
check(status) { "negative retrieveFile status" } // throws Exception if
status is false, but this is always true
}
{code}
I tried to mitigate this with a retry mechanism where I would resume
downloading for the number of the missing bytes only (e.g. the second attempt
only fetches the last missing few bytes). But it still results in a corrupted
zip file, despite the total number of bytes is correct. Looks like the first
pass/attempt already brings a corrupted chunk, so resumed download does not
help:
{code:java}
repeat(ATTEMPTS_TO_DOWNLOAD) {
if (localTargetFile.exists()) {
client.restartOffset = localTargetFile.length()
FileOutputStream(localTargetFile, true)
} else {
FileOutputStream(localTargetFile)
}.use { outputStream: FileOutputStream ->
val status = client.retrieveFile(ftpFilePath, outputStream)
outputStream.flush()
check(status) { "negative retrieveFile status" } // throws Exception if
status is false, but this is always true
}
}{code}
The odd things I noticed (which is maybe due to FTPS server misconfig/missetup,
but FTPS server setup is beyond my control):
* {{FTPClient.mlistFile()}} always returns {{null}}
* I am not able to browse the FTPS content via WinSCP
was (Author: vkhudenko):
Looks like I've encountered this issue too.
My setup is an Android app as an FTPS client (FTPSClient v3.7.2) running on a
physical device (Google Nexus, Android 8.1) or an emulator (Android 10) from
Android Studio (Win 10). VPN.
On the FTPS server I have 3 zip files (1, 4 and 74 KBytes).
Small files (1 and 4 KB) are never causing troubles. However for the largest
one the issue happens with ~25-33% probability.
The exact file size is 75'743 bytes. But it happens that only 75'741 bytes or
75'740 bytes is downloaded (missing just a few bytes) with no errors reported
by {{FTPSClient}}.
Here is my code (Kotlin):
{code:java}
private val CONNECT_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val SO_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val BUFFER_SIZE = 1024 // 1 KB
val client: FTPSClient = FTPSClient("TLS", false)
client.connectTimeout = CONNECT_TIMEOUT_MILLIS
client.connect(hostname, port)
client.soTimeout = SO_TIMEOUT_MILLIS
if (!FTPReply.isPositiveCompletion(client.replyCode)) {
throw Exception("FTP server refused connection")
}
if (!client.login(username, password)) {
throw Exception("FTP server refused to authenticate $username")
}
FileOutputStream(localTargetFile).use { outputStream: FileOutputStream ->
val status = client.retrieveFile(ftpFilePath, outputStream)
outputStream.flush()
check(status) { "negative retrieveFile status" } // throws Exception if
status is false, but this is always true
}
{code}
I tried to mitigate this with a retry mechanism where I would resume
downloading for the number of the missing bytes only (e.g. the second attempt
only fetches the last missing few bytes). But it still results in a corrupted
zip file, despite the total number of bytes is correct. Looks like the first
pass/attempt already brings a corrupted chunk, so resumed download does not
help:
{code:java}
[jira] [Comment Edited] (NET-686) Most files aren't downloaded completely from an FTP server
[
https://issues.apache.org/jira/browse/NET-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244465#comment-17244465
]
Vitaliy Khudenko edited comment on NET-686 at 12/5/20, 11:52 AM:
-
Looks like I've encountered this issue too.
My setup is an Android app as an FTPS client (FTPSClient v3.7.2) running on a
physical device (Google Nexus, Android 8.1) or an emulator (Android 10) from
Android Studio (Win 10). VPN.
On the FTPS server I have 3 zip files (1, 4 and 74 KBytes).
Small files (1 and 4 KB) are never causing troubles. However for the largest
one the issue happens with ~25-33% probability.
The exact file size is 75'743 bytes. But it happens that only 75'741 bytes or
75'740 bytes is downloaded (missing just a few bytes) with no errors reported
by {{FTPSClient}}.
Here is my code (Kotlin):
{code:java}
private val CONNECT_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val SO_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val BUFFER_SIZE = 1024 // 1 KB
val client: FTPSClient = FTPSClient("TLS", false)
client.connectTimeout = CONNECT_TIMEOUT_MILLIS
client.connect(hostname, port)
client.soTimeout = SO_TIMEOUT_MILLIS
if (!FTPReply.isPositiveCompletion(client.replyCode)) {
throw Exception("FTP server refused connection")
}
if (!client.login(username, password)) {
throw Exception("FTP server refused to authenticate $username")
}
FileOutputStream(localTargetFile).use { outputStream: FileOutputStream ->
val status = client.retrieveFile(ftpFilePath, outputStream)
outputStream.flush()
check(status) { "negative retrieveFile status" } // throws Exception if
status is false, but this is always true
}
{code}
I tried to mitigate this with a retry mechanism where I would resume
downloading for the number of the missing bytes only (e.g. the second attempt
only fetches the last missing few bytes). But it still results in a corrupted
zip file, despite the total number of bytes is correct. Looks like the first
pass/attempt already brings a corrupted chunk, so resumed download does not
help:
{code:java}
repeat(ATTEMPTS_TO_DOWNLOAD) {
if (localTargetFile.exists()) {
client.restartOffset = localTargetFile.length()
FileOutputStream(localTargetFile, true)
} else {
FileOutputStream(localTargetFile)
}.use { outputStream: FileOutputStream ->
val status = client.retrieveFile(ftpFilePath, outputStream)
outputStream.flush()
check(status) { "negative retrieveFile status" } // throws Exception if
status is false, but this is always true
}
}{code}
The odd things I noticed (which is maybe due to FTPS server misconfig/missetup,
but FTPS server setup is beyond my control):
* {{FTPClient.mlistFile()}} always returns {{null}}
* I am not able to browse the FTPS content via WinSCP
was (Author: vkhudenko):
Looks like I've encountered this issue too.
My setup is an Android app as an FTPS client ({{FTPSClient v}}3.7.2) running on
a physical device (Google Nexus, Android 8.1) or an emulator (Android 10) from
Android Studio (Win 10). VPN.
On the FTPS server I have 3 zip files (1, 4 and 74 KBytes).
Small files (1 and 4 KB) are never causing troubles. However for the largest
one the issue happens with ~25-33% probability.
The exact file size is 75'743 bytes. But it happens that only 75'741 bytes or
75'740 bytes is downloaded (missing just a few bytes) with no errors reported
by {{FTPSClient}}.
Here is my code (Kotlin):
{code:java}
private val CONNECT_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val SO_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val BUFFER_SIZE = 1024 // 1 KB
val client: FTPSClient = FTPSClient("TLS", false)
client.connectTimeout = CONNECT_TIMEOUT_MILLIS
client.connect(hostname, port)
client.soTimeout = SO_TIMEOUT_MILLIS
if (!FTPReply.isPositiveCompletion(client.replyCode)) {
throw Exception("FTP server refused connection")
}
if (!client.login(username, password)) {
throw Exception("FTP server refused to authenticate $username")
}
FileOutputStream(localTargetFile).use { outputStream: FileOutputStream ->
val status = client.retrieveFile(ftpFilePath, outputStream)
outputStream.flush()
check(status) { "negative retrieveFile status" } // throws Exception if
status is false, but this is always true
}
{code}
I tried to mitigate this with a retry mechanism where I would resume
downloading for the number of the missing bytes only (e.g. the second attempt
only fetches the last missing few bytes). But it still results in a corrupted
zip file, despite the total number of bytes is correct. Looks like the first
pass/attempt already brings a corrupted chunk, so resumed download does not
help:
{code:java}
repeat(ATTEMPTS_TO_DOWNLOAD) {
if (localTargetFile.exists()) {
client.restartOffset = localTargetFile.length()
FileOutputStream(localTargetFile, true)
[jira] [Comment Edited] (NET-686) Most files aren't downloaded completely from an FTP server
[
https://issues.apache.org/jira/browse/NET-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244465#comment-17244465
]
Vitaliy Khudenko edited comment on NET-686 at 12/5/20, 11:52 AM:
-
Looks like I've encountered this issue too.
My setup is an Android app as an FTPS client ({{FTPSClient v}}3.7.2) running on
a physical device (Google Nexus, Android 8.1) or an emulator (Android 10) from
Android Studio (Win 10). VPN.
On the FTPS server I have 3 zip files (1, 4 and 74 KBytes).
Small files (1 and 4 KB) are never causing troubles. However for the largest
one the issue happens with ~25-33% probability.
The exact file size is 75'743 bytes. But it happens that only 75'741 bytes or
75'740 bytes is downloaded (missing just a few bytes) with no errors reported
by {{FTPSClient}}.
Here is my code (Kotlin):
{code:java}
private val CONNECT_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val SO_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val BUFFER_SIZE = 1024 // 1 KB
val client: FTPSClient = FTPSClient("TLS", false)
client.connectTimeout = CONNECT_TIMEOUT_MILLIS
client.connect(hostname, port)
client.soTimeout = SO_TIMEOUT_MILLIS
if (!FTPReply.isPositiveCompletion(client.replyCode)) {
throw Exception("FTP server refused connection")
}
if (!client.login(username, password)) {
throw Exception("FTP server refused to authenticate $username")
}
FileOutputStream(localTargetFile).use { outputStream: FileOutputStream ->
val status = client.retrieveFile(ftpFilePath, outputStream)
outputStream.flush()
check(status) { "negative retrieveFile status" } // throws Exception if
status is false, but this is always true
}
{code}
I tried to mitigate this with a retry mechanism where I would resume
downloading for the number of the missing bytes only (e.g. the second attempt
only fetches the last missing few bytes). But it still results in a corrupted
zip file, despite the total number of bytes is correct. Looks like the first
pass/attempt already brings a corrupted chunk, so resumed download does not
help:
{code:java}
repeat(ATTEMPTS_TO_DOWNLOAD) {
if (localTargetFile.exists()) {
client.restartOffset = localTargetFile.length()
FileOutputStream(localTargetFile, true)
} else {
FileOutputStream(localTargetFile)
}.use { outputStream: FileOutputStream ->
val status = client.retrieveFile(ftpFilePath, outputStream)
outputStream.flush()
check(status) { "negative retrieveFile status" } // throws Exception if
status is false, but this is always true
}
}{code}
The odd things I noticed (which is maybe due to FTPS server misconfig/missetup,
but FTPS server setup is beyond my control):
* {{FTPClient.mlistFile()}} always returns {{null}}
* I am not able to browse the FTPS content via WinSCP
was (Author: vkhudenko):
Looks like I've encountered this issue too.
My setup is an Android app as an FTPS client running on a physical device
(Google Nexus, Android 8.1) or an emulator (Android 10) from Android Studio
(Win 10). VPN.
On the FTPS server I have 3 zip files (1, 4 and 74 KBytes).
Small files (1 and 4 KB) are never causing troubles. However for the largest
one the issue happens with ~25-33% probability.
The exact file size is 75'743 bytes. But it happens that only 75'741 bytes or
75'740 bytes is downloaded (missing just a few bytes) with no errors reported
by {{FTPSClient}}.
Here is my code (Kotlin):
{code:java}
private val CONNECT_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val SO_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val BUFFER_SIZE = 1024 // 1 KB
val client: FTPSClient = FTPSClient("TLS", false)
client.connectTimeout = CONNECT_TIMEOUT_MILLIS
client.connect(hostname, port)
client.soTimeout = SO_TIMEOUT_MILLIS
if (!FTPReply.isPositiveCompletion(client.replyCode)) {
throw Exception("FTP server refused connection")
}
if (!client.login(username, password)) {
throw Exception("FTP server refused to authenticate $username")
}
FileOutputStream(localTargetFile).use { outputStream: FileOutputStream ->
val status = client.retrieveFile(ftpFilePath, outputStream)
outputStream.flush()
check(status) { "negative retrieveFile status" } // throws Exception if
status is false, but this is always true
}
{code}
I tried to mitigate this with a retry mechanism where I would resume
downloading for the number of the missing bytes only (e.g. the second attempt
only fetches the last missing few bytes). But it still results in a corrupted
zip file, despite the total number of bytes is correct. Looks like the first
pass/attempt already brings a corrupted chunk, so resumed download does not
help:
{code:java}
repeat(ATTEMPTS_TO_DOWNLOAD) {
if (localTargetFile.exists()) {
client.restartOffset = localTargetFile.length()
FileOutputStream(localTargetFile, true)
} else {
[jira] [Comment Edited] (NET-686) Most files aren't downloaded completely from an FTP server
[
https://issues.apache.org/jira/browse/NET-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244465#comment-17244465
]
Vitaliy Khudenko edited comment on NET-686 at 12/5/20, 11:30 AM:
-
Looks like I've encountered this issue too.
My setup is an Android app as an FTPS client running on a physical device
(Google Nexus, Android 8.1) or an emulator (Android 10) from Android Studio
(Win 10). VPN.
On the FTPS server I have 3 zip files (1, 4 and 74 KBytes).
Small files (1 and 4 KB) are never causing troubles. However for the largest
one the issue happens with ~25-33% probability.
The exact file size is 75'743 bytes. But it happens that only 75'741 bytes or
75'740 bytes is downloaded (missing just a few bytes) with no errors reported
by {{FTPSClient}}.
Here is my code (Kotlin):
{code:java}
private val CONNECT_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val SO_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val BUFFER_SIZE = 1024 // 1 KB
val client: FTPSClient = FTPSClient("TLS", false)
client.connectTimeout = CONNECT_TIMEOUT_MILLIS
client.connect(hostname, port)
client.soTimeout = SO_TIMEOUT_MILLIS
if (!FTPReply.isPositiveCompletion(client.replyCode)) {
throw Exception("FTP server refused connection")
}
if (!client.login(username, password)) {
throw Exception("FTP server refused to authenticate $username")
}
FileOutputStream(localTargetFile).use { outputStream: FileOutputStream ->
val status = client.retrieveFile(ftpFilePath, outputStream)
outputStream.flush()
check(status) { "negative retrieveFile status" } // throws Exception if
status is false, but this is always true
}
{code}
I tried to mitigate this with a retry mechanism where I would resume
downloading for the number of the missing bytes only (e.g. the second attempt
only fetches the last missing few bytes). But it still results in a corrupted
zip file, despite the total number of bytes is correct. Looks like the first
pass/attempt already brings a corrupted chunk, so resumed download does not
help:
{code:java}
repeat(ATTEMPTS_TO_DOWNLOAD) {
if (localTargetFile.exists()) {
client.restartOffset = localTargetFile.length()
FileOutputStream(localTargetFile, true)
} else {
FileOutputStream(localTargetFile)
}.use { outputStream: FileOutputStream ->
val status = client.retrieveFile(ftpFilePath, outputStream)
outputStream.flush()
check(status) { "negative retrieveFile status" } // throws Exception if
status is false, but this is always true
}
}{code}
The odd things I noticed (which is maybe due to FTPS server misconfig/missetup,
but FTPS server setup is beyond my control):
* {{FTPClient.mlistFile()}} always returns {{null}}
* I am not able to browse the FTPS content via WinSCP
was (Author: vkhudenko):
Looks like I've encountered this issue too.
My setup is an Android app as an FTPS client running on a physical device
(Google Nexus, Android 8.1) or an emulator (Android 10) from Android Studio
(Win 10). VPN.
On the FTPS server I have 3 zip files (1, 4 and 74 KBytes).
Small files (1 and 4 KB) are never causing troubles. However for the largest
one the issue happens with ~25-33% probability.
The exact file size is 75'743 bytes. But it happens that only 75'741 bytes or
75'740 bytes is downloaded (missing just a few bytes) with no errors reported
by {{FTPSClient}}.
Here is my code (Kotlin):
{code:java}
private val CONNECT_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val SO_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val BUFFER_SIZE = 1024 // 1 KB
val client: FTPSClient = FTPSClient("TLS", false)
client.connectTimeout = CONNECT_TIMEOUT_MILLIS
client.connect(config.hostname, config.port)
client.soTimeout = SO_TIMEOUT_MILLIS
if (!FTPReply.isPositiveCompletion(client.replyCode)) {
throw Exception("FTP server refused connection")
}
if (!client.login(username, password)) {
throw Exception("FTP server refused to authenticate $username")
}
FileOutputStream(localTargetFile).use { outputStream: FileOutputStream ->
val status = client.retrieveFile(ftpFilePath, outputStream)
outputStream.flush()
check(status) { "negative retrieveFile status" } // throws Exception if
status is false, but this is always true
}
{code}
I tried to mitigate this with a retry mechanism where I would resume
downloading for the number of the missing bytes only (e.g. the second attempt
only fetches the last missing few bytes). But it still results in a corrupted
zip file, despite the total number of bytes is correct. Looks like the first
pass/attempt already brings a corrupted chunk, so resumed download does not
help:
{code:java}
repeat(ATTEMPTS_TO_DOWNLOAD) {
if (localTargetFile.exists()) {
client.restartOffset = localTargetFile.length()
FileOutputStream(localTargetFile, true)
} else {
[jira] [Commented] (NET-686) Most files aren't downloaded completely from an FTP server
[
https://issues.apache.org/jira/browse/NET-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244465#comment-17244465
]
Vitaliy Khudenko commented on NET-686:
--
Looks like I've encountered this issue too.
My setup is an Android app as an FTPS client running on a physical device
(Google Nexus, Android 8.1) or an emulator (Android 10) from Android Studio
(Win 10). VPN.
On the FTPS server I have 3 zip files (1, 4 and 74 KBytes).
Small files (1 and 4 KB) are never causing troubles. However for the largest
one the issue happens with ~25-33% probability.
The exact file size is 75'743 bytes. But it happens that only 75'741 bytes or
75'740 bytes is downloaded (missing just a few bytes) with no errors reported
by {{FTPSClient}}.
Here is my code (Kotlin):
{code:java}
private val CONNECT_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val SO_TIMEOUT_MILLIS = 120_000 // 2 minutes
private val BUFFER_SIZE = 1024 // 1 KB
val client: FTPSClient = FTPSClient("TLS", false)
client.connectTimeout = CONNECT_TIMEOUT_MILLIS
client.connect(config.hostname, config.port)
client.soTimeout = SO_TIMEOUT_MILLIS
if (!FTPReply.isPositiveCompletion(client.replyCode)) {
throw Exception("FTP server refused connection")
}
if (!client.login(username, password)) {
throw Exception("FTP server refused to authenticate $username")
}
FileOutputStream(localTargetFile).use { outputStream: FileOutputStream ->
val status = client.retrieveFile(ftpFilePath, outputStream)
outputStream.flush()
check(status) { "negative retrieveFile status" } // throws Exception if
status is false, but this is always true
}
{code}
I tried to mitigate this with a retry mechanism where I would resume
downloading for the number of the missing bytes only (e.g. the second attempt
only fetches the last missing few bytes). But it still results in a corrupted
zip file, despite the total number of bytes is correct. Looks like the first
pass/attempt already brings a corrupted chunk, so resumed download does not
help:
{code:java}
repeat(ATTEMPTS_TO_DOWNLOAD) {
if (localTargetFile.exists()) {
client.restartOffset = localTargetFile.length()
FileOutputStream(localTargetFile, true)
} else {
FileOutputStream(localTargetFile)
}.use { outputStream: FileOutputStream ->
val status = client.retrieveFile(ftpFilePath, outputStream)
outputStream.flush()
check(status) { "negative retrieveFile status" } // throws Exception if
status is false, but this is always true
}
}{code}
The odd things I noticed (which is maybe due to FTPS server misconfig/missetup,
but FTPS server setup is beyond my control):
* {{FTPClient.mlistFile()}} always returns {{null}}
* I am not able to browse the FTPS content via WinSCP
> Most files aren't downloaded completely from an FTP server
> --
>
> Key: NET-686
> URL: https://issues.apache.org/jira/browse/NET-686
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.6, 3.7.2
> Environment: Win 10
> Java 8
> Android Studio 3.6.1 (min SDK 24, target SDK 27)
>Reporter: JRRR
>Priority: Major
> Attachments: 2a-original.png, 2b-corrupt.png, 2c-corrupt.png,
> 5a-original.jpg, 5b-corrupt.jpg, 5c-corrupt.jpg, DownloadProblem.java
>
>
> About a month ago I opened another
> [issue|https://issues.apache.org/jira/browse/NET-684] that was closed because
> it wasn't reproducible with macOS and a public FTP server.
> Short summary: Downloading files from an FTP server results in these files
> randomly missing bytes. It looks like the download always "completes" and
> there are no error messages/exceptions but random bytes in random files are
> simply skipped. Images (jpg & png) are usually affected more (up to 30, maybe
> 40, bytes smaller than the original), and are then also visibly corrupt, than
> text files (usually only 2-3 bytes smaller, rarely more).
> I'm working on an Android app (Win 10, Java 8, Android Studio 3.6.1, min SDK
> 24, target SDK 27), which I'm testing with FTP servers in the same network
> (1x Win 10, 1x Linux, both accessed via IP - "10.1.1.xxx"). No matter what
> method in the library I use (retrieveFile, retrieveFileStream,
> sendCommand(FTPCmd.RETRIEVE, filename)), most of the time there's at least a
> single file that's corrupted.
> I also tested the same code with public servers and even though I didn't have
> a lot of time because those servers regularely delete uploaded files, I never
> experienced said problem with them.
> I even wrote my own mini-library (just for login/logout and download) using
> Java's default "Socket" but I still had the same problem on Android Studio's
> simulator/a real device. BUT: When I used the same code to create a small
>
[GitHub] [commons-exec] CnNullptr opened a new pull request #26: Java-style Array declaration and remove empty finally block
CnNullptr opened a new pull request #26: URL: https://github.com/apache/commons-exec/pull/26 Use Java-style arrya declaration, and remove an empty finally block. make this repo better 邏 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
