[jira] [Updated] (CRYPTO-149) testGcmTamperedData() in GCMCipherTest Intermittent Failure
[ https://issues.apache.org/jira/browse/CRYPTO-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Remily updated CRYPTO-149: --- Component/s: (was: Native) Cipher > testGcmTamperedData() in GCMCipherTest Intermittent Failure > --- > > Key: CRYPTO-149 > URL: https://issues.apache.org/jira/browse/CRYPTO-149 > Project: Commons Crypto > Issue Type: Bug > Components: Cipher >Affects Versions: 1.0.0, 1.1.0 >Reporter: Alex Remily >Priority: Major > Fix For: 1.1.0 > > > Gary Gregory > Aug 5, 2020, 10:53 PM (20 hours ago) > to Commons > Hi All: > I am seeing what may be a random AEADBadTagException in GcmCipherTest? > For example: > [ERROR] testGcmTamperedData(org.apache.commons.crypto.cipher.GcmCipherTest) > Time elapsed: 0.015 s <<< ERROR! > 881java.lang.Exception: Unexpected exception, > expected but > was > 882 at > org.apache.commons.crypto.cipher.GcmCipherTest.testGcmTamperedData(GcmCipherTest.java:224) > 883 > 884 > Any thoughts? > The above is from > https://travis-ci.org/github/apache/commons-crypto/jobs/715348986 > Gary > Alex Remily > 8:10 AM (11 hours ago) > to Commons > That is an intermittent issue that I haven't been able to reliably reproduce. > As I recall, the test that's failing is supposed to fail, but in a different > way. I think it's supposed to fail because of a short buffer but > occasionally fails because of an internal error, and when that happens this > test fails. I don't know when it was introduced. We should probably > document it in jira and or realese notes. > Matt Sicker > 10:33 AM (8 hours ago) > to Commons > Now I hope we don't have unit tests depending on non-static state for > its random number generator! ;) I'd expect a crypto library's test > suites to include several hard-coded known-good and known-bad > ciphertexts with static keys/IVs similar to the test cases presented > in their RFCs (especially since said tests are typically small enough > to copy/paste the binary data fairly easily). > -- > Matt Sicker > Rob Tompkins > 10:37 AM (8 hours ago) > to Commons > We actually do have a considerable number of those in our projects where we > use probabilistic epsilons on the output. See commons-rng. Note, Gilles is > quite good at writing such tests. > -Rob > Matt Sicker > 10:42 AM (8 hours ago) > to Commons > Well, for testing RNGs, I can understand using property testing, yes. > It would also be useful for testing fuzzing scenarios like making sure > the GCM tag is invalid for any random input data (giving a near zero > probability of valid data) or that an elliptic curve implementation > doesn't leak out information about points outside the curve or respond > to invalid inputs improperly or things like that. > Rob Tompkins > 10:50 AM (8 hours ago) > to Commons > +1 - the elliptic curve stuff I’ll have to defer to you on as I’m less a > number theorist and more of a logician. > -Rob > Gary Gregory > 10:56 AM (8 hours ago) > to Commons > This is all fine and good but how would you fix the test such that it does > not fail randomly. PR anyone? > Gary > Rob Tompkins > 10:57 AM (8 hours ago) > to Commons > Either static inputs for determinism, or putting a probabilistic boundary in > which the solution can fall. > -Rob > Matt Sicker > 11:00 AM (8 hours ago) > to Commons > Choose a seed value for the `new Random()` constructor and the tests > will be deterministic. > Matt Sicker > 11:02 AM (8 hours ago) > to Commons > Or alternatively, if using random values each time, have it retry the > test with a different value. It's typically better to use an actual > property testing library for these types of tests anyways. One example > library I found is https://jqwik.net/ (these types of testing > libraries are more common in functional programming like in Scala). > Rob Tompkins > 11:03 AM (8 hours ago) > to Commons > Precisely. That’s another technique we’ve used in rng. > -Ropb -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CRYPTO-149) testGcmTamperedData() in GCMCipherTest Intermittent Failure
[ https://issues.apache.org/jira/browse/CRYPTO-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Remily resolved CRYPTO-149. Fix Version/s: 1.1.0 Resolution: Fixed I'm fairly confident that this bug is fixed. The length of the cipher's initialization vector is set by a call to the Random class's nextInt method. The return value for that method was bounded between zero and sixty, inclusive. When that method returned zero, it resulted in an error setting GCM initial vector length. I changed the bounds of the return value to between 1 and 60, inclusive, and tested by running the unit test in a continual loop for several minutes without error. > testGcmTamperedData() in GCMCipherTest Intermittent Failure > --- > > Key: CRYPTO-149 > URL: https://issues.apache.org/jira/browse/CRYPTO-149 > Project: Commons Crypto > Issue Type: Bug > Components: Native >Affects Versions: 1.0.0, 1.1.0 >Reporter: Alex Remily >Priority: Major > Fix For: 1.1.0 > > > Gary Gregory > Aug 5, 2020, 10:53 PM (20 hours ago) > to Commons > Hi All: > I am seeing what may be a random AEADBadTagException in GcmCipherTest? > For example: > [ERROR] testGcmTamperedData(org.apache.commons.crypto.cipher.GcmCipherTest) > Time elapsed: 0.015 s <<< ERROR! > 881java.lang.Exception: Unexpected exception, > expected but > was > 882 at > org.apache.commons.crypto.cipher.GcmCipherTest.testGcmTamperedData(GcmCipherTest.java:224) > 883 > 884 > Any thoughts? > The above is from > https://travis-ci.org/github/apache/commons-crypto/jobs/715348986 > Gary > Alex Remily > 8:10 AM (11 hours ago) > to Commons > That is an intermittent issue that I haven't been able to reliably reproduce. > As I recall, the test that's failing is supposed to fail, but in a different > way. I think it's supposed to fail because of a short buffer but > occasionally fails because of an internal error, and when that happens this > test fails. I don't know when it was introduced. We should probably > document it in jira and or realese notes. > Matt Sicker > 10:33 AM (8 hours ago) > to Commons > Now I hope we don't have unit tests depending on non-static state for > its random number generator! ;) I'd expect a crypto library's test > suites to include several hard-coded known-good and known-bad > ciphertexts with static keys/IVs similar to the test cases presented > in their RFCs (especially since said tests are typically small enough > to copy/paste the binary data fairly easily). > -- > Matt Sicker > Rob Tompkins > 10:37 AM (8 hours ago) > to Commons > We actually do have a considerable number of those in our projects where we > use probabilistic epsilons on the output. See commons-rng. Note, Gilles is > quite good at writing such tests. > -Rob > Matt Sicker > 10:42 AM (8 hours ago) > to Commons > Well, for testing RNGs, I can understand using property testing, yes. > It would also be useful for testing fuzzing scenarios like making sure > the GCM tag is invalid for any random input data (giving a near zero > probability of valid data) or that an elliptic curve implementation > doesn't leak out information about points outside the curve or respond > to invalid inputs improperly or things like that. > Rob Tompkins > 10:50 AM (8 hours ago) > to Commons > +1 - the elliptic curve stuff I’ll have to defer to you on as I’m less a > number theorist and more of a logician. > -Rob > Gary Gregory > 10:56 AM (8 hours ago) > to Commons > This is all fine and good but how would you fix the test such that it does > not fail randomly. PR anyone? > Gary > Rob Tompkins > 10:57 AM (8 hours ago) > to Commons > Either static inputs for determinism, or putting a probabilistic boundary in > which the solution can fall. > -Rob > Matt Sicker > 11:00 AM (8 hours ago) > to Commons > Choose a seed value for the `new Random()` constructor and the tests > will be deterministic. > Matt Sicker > 11:02 AM (8 hours ago) > to Commons > Or alternatively, if using random values each time, have it retry the > test with a different value. It's typically better to use an actual > property testing library for these types of tests anyways. One example > library I found is https://jqwik.net/ (these types of testing > libraries are more common in functional programming like in Scala). > Rob Tompkins > 11:03 AM (8 hours ago) > to Commons > Precisely. That’s another technique we’ve used in rng. > -Ropb -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CRYPTO-149) testGcmTamperedData() in GCMCipherTest Intermittent Failure
[ https://issues.apache.org/jira/browse/CRYPTO-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173727#comment-17173727 ] Alex Remily commented on CRYPTO-149: This is the PR with the fix: https://github.com/apache/commons-crypto/pull/103 > testGcmTamperedData() in GCMCipherTest Intermittent Failure > --- > > Key: CRYPTO-149 > URL: https://issues.apache.org/jira/browse/CRYPTO-149 > Project: Commons Crypto > Issue Type: Bug > Components: Native >Affects Versions: 1.0.0, 1.1.0 >Reporter: Alex Remily >Priority: Major > Fix For: 1.1.0 > > > Gary Gregory > Aug 5, 2020, 10:53 PM (20 hours ago) > to Commons > Hi All: > I am seeing what may be a random AEADBadTagException in GcmCipherTest? > For example: > [ERROR] testGcmTamperedData(org.apache.commons.crypto.cipher.GcmCipherTest) > Time elapsed: 0.015 s <<< ERROR! > 881java.lang.Exception: Unexpected exception, > expected but > was > 882 at > org.apache.commons.crypto.cipher.GcmCipherTest.testGcmTamperedData(GcmCipherTest.java:224) > 883 > 884 > Any thoughts? > The above is from > https://travis-ci.org/github/apache/commons-crypto/jobs/715348986 > Gary > Alex Remily > 8:10 AM (11 hours ago) > to Commons > That is an intermittent issue that I haven't been able to reliably reproduce. > As I recall, the test that's failing is supposed to fail, but in a different > way. I think it's supposed to fail because of a short buffer but > occasionally fails because of an internal error, and when that happens this > test fails. I don't know when it was introduced. We should probably > document it in jira and or realese notes. > Matt Sicker > 10:33 AM (8 hours ago) > to Commons > Now I hope we don't have unit tests depending on non-static state for > its random number generator! ;) I'd expect a crypto library's test > suites to include several hard-coded known-good and known-bad > ciphertexts with static keys/IVs similar to the test cases presented > in their RFCs (especially since said tests are typically small enough > to copy/paste the binary data fairly easily). > -- > Matt Sicker > Rob Tompkins > 10:37 AM (8 hours ago) > to Commons > We actually do have a considerable number of those in our projects where we > use probabilistic epsilons on the output. See commons-rng. Note, Gilles is > quite good at writing such tests. > -Rob > Matt Sicker > 10:42 AM (8 hours ago) > to Commons > Well, for testing RNGs, I can understand using property testing, yes. > It would also be useful for testing fuzzing scenarios like making sure > the GCM tag is invalid for any random input data (giving a near zero > probability of valid data) or that an elliptic curve implementation > doesn't leak out information about points outside the curve or respond > to invalid inputs improperly or things like that. > Rob Tompkins > 10:50 AM (8 hours ago) > to Commons > +1 - the elliptic curve stuff I’ll have to defer to you on as I’m less a > number theorist and more of a logician. > -Rob > Gary Gregory > 10:56 AM (8 hours ago) > to Commons > This is all fine and good but how would you fix the test such that it does > not fail randomly. PR anyone? > Gary > Rob Tompkins > 10:57 AM (8 hours ago) > to Commons > Either static inputs for determinism, or putting a probabilistic boundary in > which the solution can fall. > -Rob > Matt Sicker > 11:00 AM (8 hours ago) > to Commons > Choose a seed value for the `new Random()` constructor and the tests > will be deterministic. > Matt Sicker > 11:02 AM (8 hours ago) > to Commons > Or alternatively, if using random values each time, have it retry the > test with a different value. It's typically better to use an actual > property testing library for these types of tests anyways. One example > library I found is https://jqwik.net/ (these types of testing > libraries are more common in functional programming like in Scala). > Rob Tompkins > 11:03 AM (8 hours ago) > to Commons > Precisely. That’s another technique we’ve used in rng. > -Ropb -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-crypto] coveralls edited a comment on pull request #103: Standardize the release build process with Docker.
coveralls edited a comment on pull request #103: URL: https://github.com/apache/commons-crypto/pull/103#issuecomment-667682795 [](https://coveralls.io/builds/32627702) Coverage decreased (-0.2%) to 82.867% when pulling **35d1cc33a48e6b490a131ef71414a81676e409d5 on aremily:build** into **c2b0e6e736c3d7f8379671ddfb9175f7c7f68283 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] [Updated] (CRYPTO-149) testGcmTamperedData() in GCMCipherTest Intermittent Failure
[ https://issues.apache.org/jira/browse/CRYPTO-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Remily updated CRYPTO-149: --- Summary: testGcmTamperedData() in GCMCipherTest Intermittent Failure (was: testGMacTamperedData() in GCMCipherTest Intermittent Failure) > testGcmTamperedData() in GCMCipherTest Intermittent Failure > --- > > Key: CRYPTO-149 > URL: https://issues.apache.org/jira/browse/CRYPTO-149 > Project: Commons Crypto > Issue Type: Bug > Components: Native >Affects Versions: 1.0.0, 1.1.0 >Reporter: Alex Remily >Priority: Major > > Gary Gregory > Aug 5, 2020, 10:53 PM (20 hours ago) > to Commons > Hi All: > I am seeing what may be a random AEADBadTagException in GcmCipherTest? > For example: > [ERROR] testGcmTamperedData(org.apache.commons.crypto.cipher.GcmCipherTest) > Time elapsed: 0.015 s <<< ERROR! > 881java.lang.Exception: Unexpected exception, > expected but > was > 882 at > org.apache.commons.crypto.cipher.GcmCipherTest.testGcmTamperedData(GcmCipherTest.java:224) > 883 > 884 > Any thoughts? > The above is from > https://travis-ci.org/github/apache/commons-crypto/jobs/715348986 > Gary > Alex Remily > 8:10 AM (11 hours ago) > to Commons > That is an intermittent issue that I haven't been able to reliably reproduce. > As I recall, the test that's failing is supposed to fail, but in a different > way. I think it's supposed to fail because of a short buffer but > occasionally fails because of an internal error, and when that happens this > test fails. I don't know when it was introduced. We should probably > document it in jira and or realese notes. > Matt Sicker > 10:33 AM (8 hours ago) > to Commons > Now I hope we don't have unit tests depending on non-static state for > its random number generator! ;) I'd expect a crypto library's test > suites to include several hard-coded known-good and known-bad > ciphertexts with static keys/IVs similar to the test cases presented > in their RFCs (especially since said tests are typically small enough > to copy/paste the binary data fairly easily). > -- > Matt Sicker > Rob Tompkins > 10:37 AM (8 hours ago) > to Commons > We actually do have a considerable number of those in our projects where we > use probabilistic epsilons on the output. See commons-rng. Note, Gilles is > quite good at writing such tests. > -Rob > Matt Sicker > 10:42 AM (8 hours ago) > to Commons > Well, for testing RNGs, I can understand using property testing, yes. > It would also be useful for testing fuzzing scenarios like making sure > the GCM tag is invalid for any random input data (giving a near zero > probability of valid data) or that an elliptic curve implementation > doesn't leak out information about points outside the curve or respond > to invalid inputs improperly or things like that. > Rob Tompkins > 10:50 AM (8 hours ago) > to Commons > +1 - the elliptic curve stuff I’ll have to defer to you on as I’m less a > number theorist and more of a logician. > -Rob > Gary Gregory > 10:56 AM (8 hours ago) > to Commons > This is all fine and good but how would you fix the test such that it does > not fail randomly. PR anyone? > Gary > Rob Tompkins > 10:57 AM (8 hours ago) > to Commons > Either static inputs for determinism, or putting a probabilistic boundary in > which the solution can fall. > -Rob > Matt Sicker > 11:00 AM (8 hours ago) > to Commons > Choose a seed value for the `new Random()` constructor and the tests > will be deterministic. > Matt Sicker > 11:02 AM (8 hours ago) > to Commons > Or alternatively, if using random values each time, have it retry the > test with a different value. It's typically better to use an actual > property testing library for these types of tests anyways. One example > library I found is https://jqwik.net/ (these types of testing > libraries are more common in functional programming like in Scala). > Rob Tompkins > 11:03 AM (8 hours ago) > to Commons > Precisely. That’s another technique we’ve used in rng. > -Ropb -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (EXEC-111) Update Java requirement from Java 5 to 8
[ https://issues.apache.org/jira/browse/EXEC-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated EXEC-111: - Description: Update Java requirement from Java 5 to 8. This will allow to build on Java 9 and up. was: Update Java requirement from Java 5 to 7. This will allow to build on Java 9 and up. > Update Java requirement from Java 5 to 8 > > > Key: EXEC-111 > URL: https://issues.apache.org/jira/browse/EXEC-111 > Project: Commons Exec > Issue Type: Improvement >Reporter: Gary D. Gregory >Priority: Major > Fix For: 1.4 > > > Update Java requirement from Java 5 to 8. > This will allow to build on Java 9 and up. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (EXEC-111) Update Java requirement from Java 5 to 8
[ https://issues.apache.org/jira/browse/EXEC-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated EXEC-111: - Summary: Update Java requirement from Java 5 to 8 (was: Update Java requirement from Java 5 to 7) > Update Java requirement from Java 5 to 8 > > > Key: EXEC-111 > URL: https://issues.apache.org/jira/browse/EXEC-111 > Project: Commons Exec > Issue Type: Improvement >Reporter: Gary D. Gregory >Priority: Major > Fix For: 1.4 > > > Update Java requirement from Java 5 to 7. > This will allow to build on Java 9 and up. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-compress] garydgregory merged pull request #123: Add Path support to ZipArchiveOutputStream
garydgregory merged pull request #123: URL: https://github.com/apache/commons-compress/pull/123 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] (DBCP-559) 数据库连接可以通过BasicDataSource类的close()方法进行关闭，但该类没有提供open()方法使得新建的数据库连接生效
[ https://issues.apache.org/jira/browse/DBCP-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173447#comment-17173447 ] Phil Steitz edited comment on DBCP-559 at 8/8/20, 5:20 PM: --- I am working on a PR with tests for this, though I will happily review any PRs that come in before I finish. A [similar request|https://s.apache.org/gb0lk] was recently posted to tomcat-user. I am hoping that close followed by the simple open proposed in the attachment file (possibly also exposed as combined, "restart") will lead to # Idle connections get immediately closed (close contract) # Checked out connections get closed as they return (but abandoned connection cleanup stops for the pool being closed) # Any config changes made since initialization of running pool are applied to the new pool # New connections get sourced from a new pool that is initialized in "open" # No timer thread leaks or other untoward side effects I will try to add tests to confirm. was (Author: psteitz): I am working on a PR with tests for this, though I will happily review any PRs that come in before I finish. A [similar request|[https://lists.apache.org/thread.html/rf9006a5e3285bc32f0742ad4833c39852601305d5e56fc03dde60043%40%3Cusers.tomcat.apache.org%3E]] was recently posted to tomcat-user. I am hoping that close followed by the simple open proposed in the attachment file (possibly also exposed as combined, "restart") will lead to # Idle connections get immediately closed (close contract) # Checked out connections get closed as they return (but abandoned connection cleanup stops for the pool being closed) # Any config changes made since initialization of running pool are applied to the new pool # New connections get sourced from a new pool that is initialized in "open" # No timer thread leaks or other untoward side effects I will try to add tests to confirm. > 数据库连接可以通过BasicDataSource类的close()方法进行关闭，但该类没有提供open()方法使得新建的数据库连接生效 > --- > > Key: DBCP-559 > URL: https://issues.apache.org/jira/browse/DBCP-559 > Project: Commons DBCP > Issue Type: Improvement >Affects Versions: 2.8.0 >Reporter: Wenzhi Ji >Priority: Major > Labels: ready-to-commit > Fix For: 2.8.0 > > Attachments: BasicDataSource.java, BasicDataSourceMXBean.java > > Original Estimate: 1h > Remaining Estimate: 1h > > 当前该开源软件具备的功能：若数据库连接被关闭（即closed置为true），则必须重启服务，才能使新的数据库连接生效（closed置为false）。 > 针对容灾场景，若数据库连接串发生变化，为了使新的数据库连接动态生效（热生效），不需要手工重启服务，建议该开源软件BasicDataSource类提供一个open()方法用于置closed > = false；以使建立的数据库连接生效。 > 变更的代码见附件。 > 注：附件是基于2.7.0版本代码进行优化的。 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (DBCP-559) 数据库连接可以通过BasicDataSource类的close()方法进行关闭，但该类没有提供open()方法使得新建的数据库连接生效
[ https://issues.apache.org/jira/browse/DBCP-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173447#comment-17173447 ] Phil Steitz edited comment on DBCP-559 at 8/8/20, 5:15 PM: --- I am working on a PR with tests for this, though I will happily review any PRs that come in before I finish. A [similar request|[https://lists.apache.org/thread.html/rf9006a5e3285bc32f0742ad4833c39852601305d5e56fc03dde60043%40%3Cusers.tomcat.apache.org%3E]] was recently posted to tomcat-user. I am hoping that close followed by the simple open proposed in the attachment file (possibly also exposed as combined, "restart") will lead to # Idle connections get immediately closed (close contract) # Checked out connections get closed as they return (but abandoned connection cleanup stops for the pool being closed) # Any config changes made since initialization of running pool are applied to the new pool # New connections get sourced from a new pool that is initialized in "open" # No timer thread leaks or other untoward side effects I will try to add tests to confirm. was (Author: psteitz): I am working on a PR with tests for this, though I will happily review any PRs that come in before I finish. A [similar request|[https://lists.apache.org/thread.html/rf9006a5e3285bc32f0742ad4833c39852601305d5e56fc03dde60043%40%3Cusers.tomcat.apache.org%3E]] was recently posted to tomcat-user. I am hoping that close followed by the simple open proposed in the attachment file (possibly also exposed as combined, "restart") will lead to # Idle connections get immediately closed (close contract) # Checked out connections get closed as they return (but abandoned connection cleanup stops for the pool being closed) # Any config changes made since initialization of running pool are applied to the new pool # New connections get sourced from a new pool that is initialized in "open" # No timer thread leaks or other untoward side effects I will try to add tests to confirm. > 数据库连接可以通过BasicDataSource类的close()方法进行关闭，但该类没有提供open()方法使得新建的数据库连接生效 > --- > > Key: DBCP-559 > URL: https://issues.apache.org/jira/browse/DBCP-559 > Project: Commons DBCP > Issue Type: Improvement >Affects Versions: 2.8.0 >Reporter: Wenzhi Ji >Priority: Major > Labels: ready-to-commit > Fix For: 2.8.0 > > Attachments: BasicDataSource.java, BasicDataSourceMXBean.java > > Original Estimate: 1h > Remaining Estimate: 1h > > 当前该开源软件具备的功能：若数据库连接被关闭（即closed置为true），则必须重启服务，才能使新的数据库连接生效（closed置为false）。 > 针对容灾场景，若数据库连接串发生变化，为了使新的数据库连接动态生效（热生效），不需要手工重启服务，建议该开源软件BasicDataSource类提供一个open()方法用于置closed > = false；以使建立的数据库连接生效。 > 变更的代码见附件。 > 注：附件是基于2.7.0版本代码进行优化的。 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IO-646) org.apache.commons.io.FileUtils.writeStringToFile causes crashes on Android 4.2
[
https://issues.apache.org/jira/browse/IO-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved IO-646.
-
Fix Version/s: (was: 2.5)
Resolution: Won't Fix
> org.apache.commons.io.FileUtils.writeStringToFile causes crashes on Android
> 4.2
>
>
> Key: IO-646
> URL: https://issues.apache.org/jira/browse/IO-646
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.6
> Environment: Android 4.2 (API 17)
>Reporter: Hong Zhang
>Priority: Major
>
> Version 2.6 causes the following crash on Android 4.2 (probably on versions
> lower than 4.2 too)
> {{java.lang.NoClassDefFoundError:
> at org.apache.commons.io.Charsets. (Charsets.java:120)
> at org.apache.commons.io.FileUtils.writeStringToFile (FileUtils.java:2035)
> at org.apache.commons.io.FileUtils.writeStringToFile (FileUtils.java:1999)}}
> {{}}
> {{}}Version 2.5 works flawlessly
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IO-637) Technical Support Expiration Date
[ https://issues.apache.org/jira/browse/IO-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved IO-637. - Resolution: Information Provided > Technical Support Expiration Date > - > > Key: IO-637 > URL: https://issues.apache.org/jira/browse/IO-637 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Sergi Comeche >Priority: Major > > Hello, > I work for a long-term project which requires strong and stable technical > support for every software used. > I want to know how long you are providing technical support for Commons-io > 2.1. > Please I appreciate so much that you can give me expiration dates for this > software product or expectations of its EOL. > Thank you! > Sergi -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (IO-682) Add lines() methods for InputStream and Reader.
[ https://issues.apache.org/jira/browse/IO-682?focusedWorklogId=468256&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-468256 ] ASF GitHub Bot logged work on IO-682: - Author: ASF GitHub Bot Created on: 08/Aug/20 14:47 Start Date: 08/Aug/20 14:47 Worklog Time Spent: 10m Work Description: coveralls edited a comment on pull request #139: URL: https://github.com/apache/commons-io/pull/139#issuecomment-670931555 [](https://coveralls.io/builds/32623824) Coverage increased (+0.006%) to 89.935% when pulling **bb7852045b352f0da8d817b8215f9dc25fe1bc60 on Isira-Seneviratne:Add_lines_methods** into **b20e61e2d4af17c51d2411ff5b9e0d3aa2441d73 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 468256) Time Spent: 0.5h (was: 20m) > Add lines() methods for InputStream and Reader. > --- > > Key: IO-682 > URL: https://issues.apache.org/jira/browse/IO-682 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Reporter: Isira Seneviratne >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Add lines() methods that return a Stream object for InputStream and Reader. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-io] coveralls edited a comment on pull request #139: [IO-682] Add lines() methods for InputStream and Reader.
coveralls edited a comment on pull request #139: URL: https://github.com/apache/commons-io/pull/139#issuecomment-670931555 [](https://coveralls.io/builds/32623824) Coverage increased (+0.006%) to 89.935% when pulling **bb7852045b352f0da8d817b8215f9dc25fe1bc60 on Isira-Seneviratne:Add_lines_methods** into **b20e61e2d4af17c51d2411ff5b9e0d3aa2441d73 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] [Work logged] (IO-652) Spring Clean .gitignore
[ https://issues.apache.org/jira/browse/IO-652?focusedWorklogId=468250&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-468250 ] ASF GitHub Bot logged work on IO-652: - Author: ASF GitHub Bot Created on: 08/Aug/20 13:53 Start Date: 08/Aug/20 13:53 Worklog Time Spent: 10m Work Description: sebbASF commented on pull request #103: URL: https://github.com/apache/commons-io/pull/103#issuecomment-670931790 I think some of the files should not be ignored. For example pom.* (apart from pom.xml) should not be present normally. I wonder if OS-specific files should even be listed - I would expect them to be defined by the developer at system level. 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: 468250) Time Spent: 0.5h (was: 20m) > Spring Clean .gitignore > --- > > Key: IO-652 > URL: https://issues.apache.org/jira/browse/IO-652 > Project: Commons IO > Issue Type: Improvement >Reporter: John Patrick >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > As Per Email 2020/03/01 11:07, "Java Modules Codec, Collections, IO and > Lang", and > https://github.com/apache/commons-collections/blob/master/CONTRIBUTING.md. > Step 1, cleaning up .gitignore -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-io] sebbASF commented on pull request #103: IO-652 spring clean .gitignore
sebbASF commented on pull request #103: URL: https://github.com/apache/commons-io/pull/103#issuecomment-670931790 I think some of the files should not be ignored. For example pom.* (apart from pom.xml) should not be present normally. I wonder if OS-specific files should even be listed - I would expect them to be defined by the developer at system level. 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-io] coveralls commented on pull request #139: [IO-682] Add lines() methods for InputStream and Reader.
coveralls commented on pull request #139: URL: https://github.com/apache/commons-io/pull/139#issuecomment-670931555 [](https://coveralls.io/builds/32623357) Coverage decreased (-0.06%) to 89.871% when pulling **a204ec6913942a63ac114b3b2c1dcf9864863115 on Isira-Seneviratne:Add_lines_methods** into **b20e61e2d4af17c51d2411ff5b9e0d3aa2441d73 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] [Work logged] (IO-682) Add lines() methods for InputStream and Reader.
[ https://issues.apache.org/jira/browse/IO-682?focusedWorklogId=468249&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-468249 ] ASF GitHub Bot logged work on IO-682: - Author: ASF GitHub Bot Created on: 08/Aug/20 13:51 Start Date: 08/Aug/20 13:51 Worklog Time Spent: 10m Work Description: coveralls commented on pull request #139: URL: https://github.com/apache/commons-io/pull/139#issuecomment-670931555 [](https://coveralls.io/builds/32623357) Coverage decreased (-0.06%) to 89.871% when pulling **a204ec6913942a63ac114b3b2c1dcf9864863115 on Isira-Seneviratne:Add_lines_methods** into **b20e61e2d4af17c51d2411ff5b9e0d3aa2441d73 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 468249) Time Spent: 20m (was: 10m) > Add lines() methods for InputStream and Reader. > --- > > Key: IO-682 > URL: https://issues.apache.org/jira/browse/IO-682 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Reporter: Isira Seneviratne >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Add lines() methods that return a Stream object for InputStream and Reader. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-io] XenoAmess commented on pull request #116: refine travis-ci scripts
XenoAmess commented on pull request #116: URL: https://github.com/apache/commons-io/pull/116#issuecomment-670931228 @sebbASF > What is the purpose of the change? to add cache for m2 folder, means dependencies jars, to avoid downloading them times and times. 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-io] sebbASF commented on pull request #116: refine travis-ci scripts
sebbASF commented on pull request #116: URL: https://github.com/apache/commons-io/pull/116#issuecomment-670931069 What is the purpose of the change? 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-io] sebbASF closed pull request #81: Create issue
sebbASF closed pull request #81: URL: https://github.com/apache/commons-io/pull/81 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-io] sebbASF commented on pull request #81: Create issue
sebbASF commented on pull request #81: URL: https://github.com/apache/commons-io/pull/81#issuecomment-670930545 Insufficient information 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-validator] sebbASF merged pull request #37: Bump commons-parent from 51 to 52
sebbASF merged pull request #37: URL: https://github.com/apache/commons-validator/pull/37 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] (IO-676) Add isFileNewer() and isFileOlder() methods that support the Java 8 Date/Time API.
[ https://issues.apache.org/jira/browse/IO-676?focusedWorklogId=468240&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-468240 ] ASF GitHub Bot logged work on IO-676: - Author: ASF GitHub Bot Created on: 08/Aug/20 13:13 Start Date: 08/Aug/20 13:13 Worklog Time Spent: 10m Work Description: coveralls edited a comment on pull request #124: URL: https://github.com/apache/commons-io/pull/124#issuecomment-657222432 [](https://coveralls.io/builds/32623040) Coverage increased (+0.03%) to 89.956% when pulling **a6a5159c1bcee5fb48c7cc51786e18370bf3f7d9 on Isira-Seneviratne:Add_file_modified_methods** into **b20e61e2d4af17c51d2411ff5b9e0d3aa2441d73 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 468240) Time Spent: 4h 40m (was: 4.5h) > Add isFileNewer() and isFileOlder() methods that support the Java 8 Date/Time > API. > -- > > Key: IO-676 > URL: https://issues.apache.org/jira/browse/IO-676 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Reporter: Isira Seneviratne >Priority: Major > Fix For: 2.8 > > Time Spent: 4h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-io] coveralls edited a comment on pull request #124: [IO-676] Add isFileNewer() and isFileOlder() methods that support the Java 8 Date/Time API.
coveralls edited a comment on pull request #124: URL: https://github.com/apache/commons-io/pull/124#issuecomment-657222432 [](https://coveralls.io/builds/32623040) Coverage increased (+0.03%) to 89.956% when pulling **a6a5159c1bcee5fb48c7cc51786e18370bf3f7d9 on Isira-Seneviratne:Add_file_modified_methods** into **b20e61e2d4af17c51d2411ff5b9e0d3aa2441d73 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] [Work logged] (IO-682) Add lines() methods for InputStream and Reader.
[ https://issues.apache.org/jira/browse/IO-682?focusedWorklogId=468239&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-468239 ] ASF GitHub Bot logged work on IO-682: - Author: ASF GitHub Bot Created on: 08/Aug/20 13:11 Start Date: 08/Aug/20 13:11 Worklog Time Spent: 10m Work Description: Isira-Seneviratne opened a new pull request #139: URL: https://github.com/apache/commons-io/pull/139 Add `lines()` methods that return a `Stream` object for `InputStream` and `Reader`. 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: 468239) Remaining Estimate: 0h Time Spent: 10m > Add lines() methods for InputStream and Reader. > --- > > Key: IO-682 > URL: https://issues.apache.org/jira/browse/IO-682 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Reporter: Isira Seneviratne >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Add lines() methods that return a Stream object for InputStream and Reader. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-io] Isira-Seneviratne opened a new pull request #139: [IO-682] Add lines() methods for InputStream and Reader.
Isira-Seneviratne opened a new pull request #139: URL: https://github.com/apache/commons-io/pull/139 Add `lines()` methods that return a `Stream` object for `InputStream` and `Reader`. 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] (IO-682) Add lines() methods for InputStream and Reader.
[ https://issues.apache.org/jira/browse/IO-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isira Seneviratne updated IO-682: - Description: Add lines() methods that return a Stream object for InputStream and Reader. (was: Add `lines()` methods that return a `Stream` object for `InputStream` and `Reader`.) > Add lines() methods for InputStream and Reader. > --- > > Key: IO-682 > URL: https://issues.apache.org/jira/browse/IO-682 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Reporter: Isira Seneviratne >Priority: Major > Fix For: 2.8 > > > Add lines() methods that return a Stream object for InputStream and Reader. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IO-682) Add lines() methods for InputStream and Reader.
Isira Seneviratne created IO-682: Summary: Add lines() methods for InputStream and Reader. Key: IO-682 URL: https://issues.apache.org/jira/browse/IO-682 Project: Commons IO Issue Type: Improvement Components: Utilities Reporter: Isira Seneviratne Fix For: 2.8 Add `lines()` methods that return a `Stream` object for `InputStream` and `Reader`. -- This message was sent by Atlassian Jira (v8.3.4#803005)
