[GitHub] [commons-dbcp] codecov-commenter commented on pull request #197: Bump narayana-jta from 5.12.6.Final to 5.12.7.Final
codecov-commenter commented on PR #197: URL: https://github.com/apache/commons-dbcp/pull/197#issuecomment-1165170510 # [Codecov](https://codecov.io/gh/apache/commons-dbcp/pull/197?src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) Report > Merging [#197](https://codecov.io/gh/apache/commons-dbcp/pull/197?src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (76f9f4f) into [master](https://codecov.io/gh/apache/commons-dbcp/commit/d697b482e485d7f493fd2b6dc480470fc67db125?el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (d697b48) will **not change** coverage. > The diff coverage is `n/a`. ```diff @@Coverage Diff@@ ## master #197 +/- ## = Coverage 59.22% 59.22% Complexity 1794 1794 = Files56 56 Lines 7737 7737 Branches527 527 = Hits 4582 4582 Misses 2900 2900 Partials255 255 ``` -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/commons-dbcp/pull/197?src=pr&el=continue&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/commons-dbcp/pull/197?src=pr&el=footer&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation). Last update [d697b48...76f9f4f](https://codecov.io/gh/apache/commons-dbcp/pull/197?src=pr&el=lastupdated&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation). -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-dbcp] dependabot[bot] opened a new pull request, #197: Bump narayana-jta from 5.12.6.Final to 5.12.7.Final
dependabot[bot] opened a new pull request, #197: URL: https://github.com/apache/commons-dbcp/pull/197 Bumps narayana-jta from 5.12.6.Final to 5.12.7.Final. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (CRYPTO-162) openSslCipher support engine
[
https://issues.apache.org/jira/browse/CRYPTO-162?focusedWorklogId=784406&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-784406
]
ASF GitHub Bot logged work on CRYPTO-162:
-
Author: ASF GitHub Bot
Created on: 24/Jun/22 03:50
Start Date: 24/Jun/22 03:50
Worklog Time Spent: 10m
Work Description: wenwj0 commented on PR #165:
URL: https://github.com/apache/commons-crypto/pull/165#issuecomment-1165164303
If i need to test this PR, we need to install a specific engine. In my case,
i installed kae engine and it works.
Issue Time Tracking
---
Worklog Id: (was: 784406)
Time Spent: 1h 40m (was: 1.5h)
> openSslCipher support engine
>
>
> Key: CRYPTO-162
> URL: https://issues.apache.org/jira/browse/CRYPTO-162
> Project: Commons Crypto
> Issue Type: New Feature
> Components: Cipher
>Reporter: wenweijian
>Priority: Minor
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The engine is the hardware or software implementation used for performing
> cryptographic operations.
>
> Assume we have a hardware device with a super fast implementation of AES. Now
> when we use AES encryption we can set the engine to that hardware device
> (instead of {{{}NULL{}}}), which means that the operations are now computed
> by the hardware device instead of the default OpenSSL software layer.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [commons-crypto] wenwj0 commented on pull request #165: CRYPTO-162 openSslCipher support engine.
wenwj0 commented on PR #165: URL: https://github.com/apache/commons-crypto/pull/165#issuecomment-1165164303 If i need to test this PR, we need to install a specific engine. In my case, i installed kae engine and it works. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] garydgregory commented on a diff in pull request #298: Remove duplicate conditions. Use switch instead.
garydgregory commented on code in PR #298:
URL: https://github.com/apache/commons-compress/pull/298#discussion_r905669230
##
src/main/java/org/apache/commons/compress/harmony/pack200/MetadataBandGroup.java:
##
@@ -242,29 +242,48 @@ public void addParameterAnnotation(final int numParams,
final int[] annoN, final
for (Object element : t) {
final String tag = (String) element;
T.add(tag);
-if (tag.equals("B") || tag.equals("C") || tag.equals("I") ||
tag.equals("S") || tag.equals("Z")) {
-final Integer value = (Integer) valuesIterator.next();
-caseI_KI.add(cpBands.getConstant(value));
-} else if (tag.equals("D")) {
-final Double value = (Double) valuesIterator.next();
-caseD_KD.add(cpBands.getConstant(value));
-} else if (tag.equals("F")) {
-final Float value = (Float) valuesIterator.next();
-caseF_KF.add(cpBands.getConstant(value));
-} else if (tag.equals("J")) {
-final Long value = (Long) valuesIterator.next();
-caseJ_KJ.add(cpBands.getConstant(value));
-} else if (tag.equals("c")) {
-final String value = (String) valuesIterator.next();
-casec_RS.add(cpBands.getCPSignature(value));
-} else if (tag.equals("e")) {
-final String value = (String) valuesIterator.next();
-final String value2 = (String) valuesIterator.next();
-caseet_RS.add(cpBands.getCPSignature(value));
-caseec_RU.add(cpBands.getCPUtf8(value2));
-} else if (tag.equals("s")) {
-final String value = (String) valuesIterator.next();
-cases_RU.add(cpBands.getCPUtf8(value));
+switch (tag) {
+case "B":
+case "C":
+case "I":
+case "S":
+case "Z": {
+final Integer value = (Integer) valuesIterator.next();
Review Comment:
in-line local vars?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (COMPRESS-622) Invalid ZIP throws different exception in 1.21
[
https://issues.apache.org/jira/browse/COMPRESS-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17558288#comment-17558288
]
Gary D. Gregory commented on COMPRESS-622:
--
No need to bisect when you can use git blame ;)
636660fad (ian-lavallee 2020-05-20 17:28:54 -0400 452) throw new
IOException("Error on ZipFile " + archiveName, e);
it looks intentional, the exception is caught and rethrown with more context.
> Invalid ZIP throws different exception in 1.21
> --
>
> Key: COMPRESS-622
> URL: https://issues.apache.org/jira/browse/COMPRESS-622
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Nirmal Vettiankal
>Priority: Major
> Attachments: zbsm.tmp
>
>
> I have an invalid zip file (attached) that is throwing a ZipException in 1.20
> and an IOException in 1.21.
>
> With the following code:
> {code:java}
> import java.nio.file.Paths;
> import org.apache.commons.compress.archivers.zip.ZipFile;
> public class ApacheCompressTest {
> public static void main(String... args) {
> try {
> new ZipFile(Paths.get("src/main/resources/zbsm.tmp").toFile());
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> } {code}
>
> Output in 1.20:
> {code:java}
> java.util.zip.ZipException: Archive is not a ZIP archive
> at
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtEndOfCentralDirectoryRecord(ZipFile.java:1141)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:1021)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:702)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:371)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:256)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:225)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:208)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:169)
> at ApacheCompressTest.main(ApacheCompressTest.java:8)
> {code}
>
> Output in 1.21:
>
> {code:java}
> java.io.IOException: Error on ZipFile
> /Volumes/workplace/Test/ApacheCompressRegression/ApacheCompressRegression/src/main/resources/zbsm.tmp
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:383)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:261)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:230)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:213)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:174)
> at ApacheCompressTest.main(ApacheCompressTest.java:8)
> Caused by: java.util.zip.ZipException: Archive is not a ZIP archive
> at
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtEndOfCentralDirectoryRecord(ZipFile.java:1221)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:1097)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:713)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:376)
> ... 5 more
> {code}
>
> Was this an intended change?
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (COMPRESS-622) Invalid ZIP throws different exception in 1.21
[
https://issues.apache.org/jira/browse/COMPRESS-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17558197#comment-17558197
]
Michael Osipov commented on COMPRESS-622:
-
I would recommend to bisect to the offending change.
> Invalid ZIP throws different exception in 1.21
> --
>
> Key: COMPRESS-622
> URL: https://issues.apache.org/jira/browse/COMPRESS-622
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Nirmal Vettiankal
>Priority: Major
> Attachments: zbsm.tmp
>
>
> I have an invalid zip file (attached) that is throwing a ZipException in 1.20
> and an IOException in 1.21.
>
> With the following code:
> {code:java}
> import java.nio.file.Paths;
> import org.apache.commons.compress.archivers.zip.ZipFile;
> public class ApacheCompressTest {
> public static void main(String... args) {
> try {
> new ZipFile(Paths.get("src/main/resources/zbsm.tmp").toFile());
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> } {code}
>
> Output in 1.20:
> {code:java}
> java.util.zip.ZipException: Archive is not a ZIP archive
> at
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtEndOfCentralDirectoryRecord(ZipFile.java:1141)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:1021)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:702)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:371)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:256)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:225)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:208)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:169)
> at ApacheCompressTest.main(ApacheCompressTest.java:8)
> {code}
>
> Output in 1.21:
>
> {code:java}
> java.io.IOException: Error on ZipFile
> /Volumes/workplace/Test/ApacheCompressRegression/ApacheCompressRegression/src/main/resources/zbsm.tmp
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:383)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:261)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:230)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:213)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:174)
> at ApacheCompressTest.main(ApacheCompressTest.java:8)
> Caused by: java.util.zip.ZipException: Archive is not a ZIP archive
> at
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtEndOfCentralDirectoryRecord(ZipFile.java:1221)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:1097)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:713)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:376)
> ... 5 more
> {code}
>
> Was this an intended change?
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (COMPRESS-622) Invalid ZIP throws different exception in 1.21
Nirmal Vettiankal created COMPRESS-622:
--
Summary: Invalid ZIP throws different exception in 1.21
Key: COMPRESS-622
URL: https://issues.apache.org/jira/browse/COMPRESS-622
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.21
Reporter: Nirmal Vettiankal
Attachments: zbsm.tmp
I have an invalid zip file (attached) that is throwing a ZipException in 1.20
and an IOException in 1.21.
With the following code:
{code:java}
import java.nio.file.Paths;
import org.apache.commons.compress.archivers.zip.ZipFile;
public class ApacheCompressTest {
public static void main(String... args) {
try {
new ZipFile(Paths.get("src/main/resources/zbsm.tmp").toFile());
} catch (Exception e) {
e.printStackTrace();
}
}
} {code}
Output in 1.20:
{code:java}
java.util.zip.ZipException: Archive is not a ZIP archive
at
org.apache.commons.compress.archivers.zip.ZipFile.positionAtEndOfCentralDirectoryRecord(ZipFile.java:1141)
at
org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:1021)
at
org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:702)
at
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:371)
at
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:256)
at
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:225)
at
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:208)
at
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:169)
at ApacheCompressTest.main(ApacheCompressTest.java:8)
{code}
Output in 1.21:
{code:java}
java.io.IOException: Error on ZipFile
/Volumes/workplace/Test/ApacheCompressRegression/ApacheCompressRegression/src/main/resources/zbsm.tmp
at
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:383)
at
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:261)
at
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:230)
at
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:213)
at
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:174)
at ApacheCompressTest.main(ApacheCompressTest.java:8)
Caused by: java.util.zip.ZipException: Archive is not a ZIP archive
at
org.apache.commons.compress.archivers.zip.ZipFile.positionAtEndOfCentralDirectoryRecord(ZipFile.java:1221)
at
org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:1097)
at
org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:713)
at
org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:376)
... 5 more
{code}
Was this an intended change?
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (JEXL-372) Add support for 'standard' for loop
[
https://issues.apache.org/jira/browse/JEXL-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17558174#comment-17558174
]
Dmitri Blinov edited comment on JEXL-372 at 6/23/22 5:27 PM:
-
The following test case fails
{code:java}
@Test public void testForLoop00() {
String src = "(l)->{ for(let x = 0, y = 0; x < 4; ++x) { l.add(x); } }";
JexlEngine jexl = new JexlBuilder().safe(true).create();
JexlScript script = jexl.createScript(src);
List l = new ArrayList<>();
Object result = script.execute(null, l);
Assert.assertNotNull(result);
Assert.assertEquals(Arrays.asList(0, 1, 2, 3), l);
}
{code}
While the following test case passes successfully
{code:java}
@Test public void testForLoop0() {
String src = "(l)->{ for(let x = 0; x < 4; ++x) { l.add(x); } }";
JexlEngine jexl = new JexlBuilder().safe(true).create();
JexlScript script = jexl.createScript(src);
List l = new ArrayList<>();
Object result = script.execute(null, l);
Assert.assertNotNull(result);
Assert.assertEquals(Arrays.asList(0, 1, 2, 3), l);
} {code}
was (Author: dmitri_blinov):
The following test case fails
{code:java}
@Test public void testForLoop00() {
String src = "(l)->{ for(let x = 0, y = 0; x < 4; ++x) { l.add(x); } }";
JexlEngine jexl = new JexlBuilder().safe(true).create();
JexlScript script = jexl.createScript(src);
List l = new ArrayList<>();
Object result = script.execute(null, l);
Assert.assertNotNull(result);
Assert.assertEquals(Arrays.asList(0, 1, 2, 3), l);
}
{code}
While following test case passes successfully
{code:java}
@Test public void testForLoop0() {
String src = "(l)->{ for(let x = 0; x < 4; ++x) { l.add(x); } }";
JexlEngine jexl = new JexlBuilder().safe(true).create();
JexlScript script = jexl.createScript(src);
List l = new ArrayList<>();
Object result = script.execute(null, l);
Assert.assertNotNull(result);
Assert.assertEquals(Arrays.asList(0, 1, 2, 3), l);
} {code}
> Add support for 'standard' for loop
> ---
>
> Key: JEXL-372
> URL: https://issues.apache.org/jira/browse/JEXL-372
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> It would be nice to allow the C/Javascript/Java for loop:
> for(init-expression; predicate-expression; step-expression) body
> This calls for the prefix/postfix increment/decrement operators.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (JEXL-372) Add support for 'standard' for loop
[
https://issues.apache.org/jira/browse/JEXL-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17558174#comment-17558174
]
Dmitri Blinov commented on JEXL-372:
The following test case fails
{code:java}
@Test public void testForLoop00() {
String src = "(l)->{ for(let x = 0, y = 0; x < 4; ++x) { l.add(x); } }";
JexlEngine jexl = new JexlBuilder().safe(true).create();
JexlScript script = jexl.createScript(src);
List l = new ArrayList<>();
Object result = script.execute(null, l);
Assert.assertNotNull(result);
Assert.assertEquals(Arrays.asList(0, 1, 2, 3), l);
}
{code}
While following test case passes successfully
{code:java}
@Test public void testForLoop0() {
String src = "(l)->{ for(let x = 0; x < 4; ++x) { l.add(x); } }";
JexlEngine jexl = new JexlBuilder().safe(true).create();
JexlScript script = jexl.createScript(src);
List l = new ArrayList<>();
Object result = script.execute(null, l);
Assert.assertNotNull(result);
Assert.assertEquals(Arrays.asList(0, 1, 2, 3), l);
} {code}
> Add support for 'standard' for loop
> ---
>
> Key: JEXL-372
> URL: https://issues.apache.org/jira/browse/JEXL-372
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.3
>
>
> It would be nice to allow the C/Javascript/Java for loop:
> for(init-expression; predicate-expression; step-expression) body
> This calls for the prefix/postfix increment/decrement operators.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Work logged] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?focusedWorklogId=784303&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-784303
]
ASF GitHub Bot logged work on VFS-683:
--
Author: ASF GitHub Bot
Created on: 23/Jun/22 16:31
Start Date: 23/Jun/22 16:31
Worklog Time Spent: 10m
Work Description: milleruntime commented on issue #2775:
URL: https://github.com/apache/accumulo/issues/2775#issuecomment-1164628473
> His suggestion was to create a script that copies the jars from HDFS to
lib/ext before starting the Accumulo processes. You might be able to use the
same script to update the jars on the local filesystem when an updated jar is
pushed into HDFS.
We could create a bash script for 1.10.3. We could include it in contrib and
mention it in the release notes and readme.
Issue Time Tracking
---
Worklog Id: (was: 784303)
Time Spent: 1.5h (was: 1h 20m)
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Assignee: Gary D. Gregory
>Priority: Major
> Attachments: Main.java
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (IO-482) BOMInputStream.hasBOM(ByteOrderMark) do not read the BOM header
[ https://issues.apache.org/jira/browse/IO-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-482. -- Fix Version/s: 2.11.0 Resolution: Fixed Fixed in commit d4f28d7ff397386b208823c577180938e15769d3 > BOMInputStream.hasBOM(ByteOrderMark) do not read the BOM header > --- > > Key: IO-482 > URL: https://issues.apache.org/jira/browse/IO-482 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Affects Versions: 2.4 >Reporter: Hansjörg Oppermann >Priority: Minor > Fix For: 2.11.0 > > Attachments: add_fix_for_IO-482.patch, > add_unit_test_testHasBOMFirstThenRead.patch > > > The method hasBOM(ByteOrderMark) in BOMInputStream do not read a BOM prefix. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (IO-495) FileUtils.listFilesAndDirs behaves unexpected
[ https://issues.apache.org/jira/browse/IO-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-495. -- Resolution: Abandoned Closing: No PR, no further discussion in the ticket. > FileUtils.listFilesAndDirs behaves unexpected > - > > Key: IO-495 > URL: https://issues.apache.org/jira/browse/IO-495 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 > Environment: Ubuntu, Java 8 >Reporter: David Georg Reichelt >Priority: Minor > Labels: patch > Attachments: diff.txt > > > The behaviour of listFilesAndDirs is quite unexpected in my opinion. > FileUtils.listFiles searches for files in a directory, where the files match > the filter, including the subdirectories which are matched by the dirFilter. > FileUtils.listFilesAndDirs searches for files and directories, where the > files match the filter and the directories match the directory filter, > including the subdirectories which are matched by the dirFilter. > But, if one extends the listFiles-method, the logical behaviour would be: > FileUtils.listFiles searches for files and directories in a directory, where > the files and directories match the filter, including the subdirectories > which are matched by the dirFilter. > This method has been discussed in > https://issues.apache.org/jira/browse/IO-328, but there the point was, that > listFilesAndDirs also includes the root folder, which was documented > correctly after this bug. In my opinion, the problem not the inclusion of the > root filter but the different behaviour from the listFiles-method. > I'll provide an patch, where the method filters everything with the first > filter and includes subdirectories if they are included by the dirFilter. One > could also keep the current method, but imho it then should be named > different as it behaves different than listFiles (maybe filterFilesAndDirs?). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (IO-499) FilenameUtils.directoryContains(String, String) gives false positive when two directories exist with equal prefixes
[
https://issues.apache.org/jira/browse/IO-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-499.
--
Resolution: Abandoned
Closing: PR closed.
> FilenameUtils.directoryContains(String, String) gives false positive when two
> directories exist with equal prefixes
> ---
>
> Key: IO-499
> URL: https://issues.apache.org/jira/browse/IO-499
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Federico Bonelli
>Priority: Minor
>
> In a folder layout as such:
> {code}
> /foo/a.txt
> /foo2/b.txt
> {code}
> The result of invoking directoryContains is wrong:
> {code}
> FilenameUtils.directoryContains("/foo", "/foo2/b.txt"); // returns true
> {code}
> even if "/foo" and "/foo2/b.txt" are the canonical paths, they start with the
> same characters, and the current implementation of the method fails.
> As workaround we are currently appending a path separator '/' to the first
> argument.
> It is noteworthy that the current implementation of
> FileUtils.directoryContains() reveals this issue because it uses the
> File.getCanonicalPath() to obtain the String paths of "/foo" and
> "/foo2/b.txt".
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (IO-525) ValidatingObjectInputStream does not handle arrays of primitive types
[ https://issues.apache.org/jira/browse/IO-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-525. -- Resolution: Abandoned Closing: No spec, no code, no PR. > ValidatingObjectInputStream does not handle arrays of primitive types > - > > Key: IO-525 > URL: https://issues.apache.org/jira/browse/IO-525 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Jiri Stary >Priority: Major > > ValidatingObjectInputStream does not handle arrays and primitive types > correctly. > The current behaviour expects a classname, but for example for byte arrays it > fails on unknown class with name [B > I would expect some possibility of whitelisting of primitive types and/or > arrays -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (IO-527) Rolling File Output Stream
[ https://issues.apache.org/jira/browse/IO-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved IO-527. Resolution: Won't Fix This is out of scope for Commons IO. If you look deeper, you'll see this is a complex problem with many features like triggering policies and rollover strategies only bound to get more complex over time: [https://logging.apache.org/log4j/2.x/manual/appenders.html#RollingFileAppender] > Rolling File Output Stream > -- > > Key: IO-527 > URL: https://issues.apache.org/jira/browse/IO-527 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: David Mollitor >Priority: Major > > Create two Rolling File Output Streams. They write to a single file and > given a certain circumstance, they stop writing to the file, open a new file, > and continue writing there. > # Based on date > # Based on max file size -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (IO-526) The problem of log acquisition
[ https://issues.apache.org/jira/browse/IO-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-526. -- Resolution: Abandoned This seems like an issue for the app to handle. Two apps accessing the same file concurrently is the domain for the two apps to deal with, this needs a reproducible test to show what problem Commons IO can fix or deal with... > The problem of log acquisition > -- > > Key: IO-526 > URL: https://issues.apache.org/jira/browse/IO-526 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Affects Versions: 2.5 >Reporter: 张华 >Priority: Major > > Problem Description: > Recently a problem appeared in the use of commons io 2.5 when Tailer > class is in the process of monitoring and reading log files: there is lost > logs and repeatedly collected logs for the collection of log files > continuously split by time . > Scene reproduction: > We use log4j-1.2.17 in our project to generate the log file and split > it up once every hour. If the current file name is system.log, the file name > after splitting is system1.log.The Tailer class in commons io 2.5 monitors > changes to the file every 500 milliseconds. > 1. The current system.log length is 10, position is also 10, after > cutting the new system.log length is 20, then this.length is greater than > position and position is set to 0, the old file collection then repeats (ie, > system1. Log). New log is missing. > 2. The current system.log length is 10,position is 10, after cutting new > system.log length is 10, then this.length is equal to position, no log > information is read. New file logs is missing. > I hope commons io team can solve this problem, thank you! -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (IO-532) DirectoryUtils - isEqual to compare directories
[
https://issues.apache.org/jira/browse/IO-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-532.
--
Fix Version/s: 2.7
Resolution: Fixed
Closing per information given in the PR and see APIs in {{PathUtils}}
> DirectoryUtils - isEqual to compare directories
> ---
>
> Key: IO-532
> URL: https://issues.apache.org/jira/browse/IO-532
> Project: Commons IO
> Issue Type: New Feature
>Reporter: Pascal Schumacher
>Priority: Major
> Fix For: 2.7
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (IO-533) Introduce Tailable interface
[
https://issues.apache.org/jira/browse/IO-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-533.
--
Resolution: Information Provided
PR is closed, see also {{org.apache.commons.io.input.Tailer.Tailable}}
> Introduce Tailable interface
>
>
> Key: IO-533
> URL: https://issues.apache.org/jira/browse/IO-533
> Project: Commons IO
> Issue Type: New Feature
>Reporter: Pascal Schumacher
>Priority: Major
>
> suggested in https://github.com/apache/commons-io/pull/32
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (IO-569) Incorrect documentation for cloning repository
[ https://issues.apache.org/jira/browse/IO-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-569. -- Fix Version/s: 2.11.0 Resolution: Fixed > Incorrect documentation for cloning repository > -- > > Key: IO-569 > URL: https://issues.apache.org/jira/browse/IO-569 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Michael Ernst >Priority: Minor > Fix For: 2.11.0 > > > https://commons.apache.org/proper/commons-io/source-repository.html > says: > > Anonymous Access > > > > The source can be checked out anonymously from Git with this command: > > > > git clone --branch commons-io-2.6 > > http://git-wip-us.apache.org/repos/asf/commons-io.git > However, when I run that command, I get: > % git clone --branch commons-io-2.6 > http://git-wip-us.apache.org/repos/asf/commons-io.git > Cloning into 'commons-io'... > warning: redirecting to > https://git1-us-west.apache.org/repos/asf/commons-io.git/ > fatal: Remote branch commons-io-2.6 not found in upstream origin > The tags include these: > commons-io-2.5 > commons-io-2.5-RC1 > commons-io-2.5-RC2 > commons-io-2.5-RC3 > commons-io-2.5-RC4 > commons-io-2.6-RC1 > commons-io-2.6-RC2 > commons-io-2.6-RC3 > but there is no tag for commons-io-2.6. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IO-569) Incorrect documentation for cloning repository
[ https://issues.apache.org/jira/browse/IO-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17558071#comment-17558071 ] Gary D. Gregory commented on IO-569: Clone information is now here [https://commons.apache.org/proper/commons-io/scm.html] > Incorrect documentation for cloning repository > -- > > Key: IO-569 > URL: https://issues.apache.org/jira/browse/IO-569 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Michael Ernst >Priority: Minor > > https://commons.apache.org/proper/commons-io/source-repository.html > says: > > Anonymous Access > > > > The source can be checked out anonymously from Git with this command: > > > > git clone --branch commons-io-2.6 > > http://git-wip-us.apache.org/repos/asf/commons-io.git > However, when I run that command, I get: > % git clone --branch commons-io-2.6 > http://git-wip-us.apache.org/repos/asf/commons-io.git > Cloning into 'commons-io'... > warning: redirecting to > https://git1-us-west.apache.org/repos/asf/commons-io.git/ > fatal: Remote branch commons-io-2.6 not found in upstream origin > The tags include these: > commons-io-2.5 > commons-io-2.5-RC1 > commons-io-2.5-RC2 > commons-io-2.5-RC3 > commons-io-2.5-RC4 > commons-io-2.6-RC1 > commons-io-2.6-RC2 > commons-io-2.6-RC3 > but there is no tag for commons-io-2.6. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (IO-599) RFE: FileUtils.glob[One]([File rootSearchDir, ] String antFileExpr)
[
https://issues.apache.org/jira/browse/IO-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-599.
--
Resolution: Information Provided
> RFE: FileUtils.glob[One]([File rootSearchDir, ] String antFileExpr)
> ---
>
> Key: IO-599
> URL: https://issues.apache.org/jira/browse/IO-599
> Project: Commons IO
> Issue Type: Improvement
>Reporter: Mark
>Priority: Minor
>
> Can we please introduce a simpler file search method than the existing ones
> that are using filters?
> Currently I'm using the ant lib's DirectoryScanner for that purpose. However,
> ant comes with quite a few dependencies, introducing unnecessary overhead and
> bloat.
> Examples:
> {code:java}
> // select all sub directories (final slash) of cwd
> File[] f = FileUtils.glob("**/");
> // select first sub dir, null if there is none
> File f = FileUtils.globFirst("**/");
> // exception if there is none
> File f = FileUtils.globFirstE("**/");
> // select exactly one sub dir, return null if there are more or less
> File f = FileUtils.globOne("**/");
> // select exactly one sub dir, throw exception if there are more or less
> File f = FileUtils.globOneE("**/");
> // two parameter version allows to start recursive search in specified dir
> File f = FileUtils.globOneE(new File("."), "**/");
> {code}
> "\*\*" matches anything including file separators, "\*" matches anything
> excluding file separators, a final "/" indicates directory matching, a
> missing final slash indicates file matching. The function always traverses
> the entire directory hierarchy, starting at cwd by default (not counting
> optimizations). The search pattern is standardized, ie. "/" on all platforms,
> ie. "/" is not the platform file separator.
> Here is an example implementation:
> https://github.com/jjYBdx4IL/misc/blob/df9c239c56640f0d3e27d1b5d510b62f5726253f/io-utils/src/test/java/com/github/jjYBdx4IL/utils/io/FindUtilsTest.java#L105
> https://github.com/jjYBdx4IL/misc/blob/df9c239c56640f0d3e27d1b5d510b62f5726253f/io-utils/src/main/java/com/github/jjYBdx4IL/utils/io/FindUtils.java
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IO-599) RFE: FileUtils.glob[One]([File rootSearchDir, ] String antFileExpr)
[
https://issues.apache.org/jira/browse/IO-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17558068#comment-17558068
]
Gary D. Gregory commented on IO-599:
This is already in the JRE, see {{java.nio.file.Files.newDirectoryStream(Path,
String)}}
> RFE: FileUtils.glob[One]([File rootSearchDir, ] String antFileExpr)
> ---
>
> Key: IO-599
> URL: https://issues.apache.org/jira/browse/IO-599
> Project: Commons IO
> Issue Type: Improvement
>Reporter: Mark
>Priority: Minor
>
> Can we please introduce a simpler file search method than the existing ones
> that are using filters?
> Currently I'm using the ant lib's DirectoryScanner for that purpose. However,
> ant comes with quite a few dependencies, introducing unnecessary overhead and
> bloat.
> Examples:
> {code:java}
> // select all sub directories (final slash) of cwd
> File[] f = FileUtils.glob("**/");
> // select first sub dir, null if there is none
> File f = FileUtils.globFirst("**/");
> // exception if there is none
> File f = FileUtils.globFirstE("**/");
> // select exactly one sub dir, return null if there are more or less
> File f = FileUtils.globOne("**/");
> // select exactly one sub dir, throw exception if there are more or less
> File f = FileUtils.globOneE("**/");
> // two parameter version allows to start recursive search in specified dir
> File f = FileUtils.globOneE(new File("."), "**/");
> {code}
> "\*\*" matches anything including file separators, "\*" matches anything
> excluding file separators, a final "/" indicates directory matching, a
> missing final slash indicates file matching. The function always traverses
> the entire directory hierarchy, starting at cwd by default (not counting
> optimizations). The search pattern is standardized, ie. "/" on all platforms,
> ie. "/" is not the platform file separator.
> Here is an example implementation:
> https://github.com/jjYBdx4IL/misc/blob/df9c239c56640f0d3e27d1b5d510b62f5726253f/io-utils/src/test/java/com/github/jjYBdx4IL/utils/io/FindUtilsTest.java#L105
> https://github.com/jjYBdx4IL/misc/blob/df9c239c56640f0d3e27d1b5d510b62f5726253f/io-utils/src/main/java/com/github/jjYBdx4IL/utils/io/FindUtils.java
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (IO-606) FilenameUtils.concat fails with relative path
[
https://issues.apache.org/jira/browse/IO-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-606.
--
Resolution: Information Provided
> FilenameUtils.concat fails with relative path
> -
>
> Key: IO-606
> URL: https://issues.apache.org/jira/browse/IO-606
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.6
>Reporter: Matthias Ronge
>Priority: Major
>
> {{FilenameUtils.concat("../../../../src/test/resources/", "filename.xml")}}
> returns {{null}}, where expected result should be like
> {{../../../../src/test/resources/filename.xml}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (IO-609) FileUtils.copyToFile backward incompatibility bug
[
https://issues.apache.org/jira/browse/IO-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-609.
--
Resolution: Cannot Reproduce
> FileUtils.copyToFile backward incompatibility bug
> -
>
> Key: IO-609
> URL: https://issues.apache.org/jira/browse/IO-609
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: xia0c
>Priority: Major
>
> Hi,
> The following code snippets throw an IOException: Stream closed. It works
> well before commons-io 2.6. When I update commons-io to 2.6, it failed. There
> is a backward incompatibility bug behind it.
> The function code:
> {code:java}
> public class Demo {
> private void backupFile(String srcPath, String entryPath,
> ZipOutputStream stream) throws IOException {
> ZipEntry zipEntry = new ZipEntry(entryPath);
> stream.putNextEntry(zipEntry);
> Files.copy(Paths.get(srcPath), stream);
> }
> private void backupDir(String srcDir, String dstDir, ZipOutputStream
> stream) throws IOException {
> File dir = new File(srcDir);
> for (String path : dir.list()) {
> System.out.println(path);
> backupFile(dir.getAbsolutePath() + File.separator + path,
> dstDir + File.separator + path, stream);
> }
> }
> public void backup(String name) throws IOException {
>
> Files.createDirectories(Paths.get("/Users/chenlingchao/eclipse_projects/workspace/BBI.BugDetection"));
> ZipOutputStream stream = new ZipOutputStream(
>
> Files.newOutputStream(Paths.get("/Users/chenlingchao/eclipse_projects/workspace/BBI.BugDetection/tmp"
> + File.separator + name)));
> try {
>
> backupDir("/Users/chenlingchao/eclipse_projects/workspace/BBI.BugDetection/tmp",
> "meta" + File.separator + "tables", stream);
> stream.closeEntry();
> } finally {
> stream.close();
> }
> }
>
> public void restore(String name) throws IOException {
> ZipInputStream stream = new ZipInputStream(
>
> Files.newInputStream(Paths.get("/Users/chenlingchao/eclipse_projects/workspace/BBI.BugDetection/tmp"
> + File.separator + name)));
> try {
> ZipEntry entry;
> while ((entry = stream.getNextEntry()) != null) {
> FileUtils.copyToFile(stream, new
> File("/Users/chenlingchao/eclipse_projects/workspace/BBI.BugDetection/tmp" +
> File.separator + entry.getName()));
> }
> } finally {
> stream.close();
> }
> }
> }
> {code}
> The test code:
> {code:java}
> @Test
> public void TestDemo() throws IOException{
> Demo test = new Demo();
> test.backup("test.zip");
> test.restore("test.zip");
> }
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IO-754) WildcardFileFilter should not ignore override accept-method
[
https://issues.apache.org/jira/browse/IO-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17558055#comment-17558055
]
Sita Geßner commented on IO-754:
[~ggregory]
I've implemented the workaround so far. I think it's ok to deprecate the method
at least.
> WildcardFileFilter should not ignore override accept-method
> ---
>
> Key: IO-754
> URL: https://issues.apache.org/jira/browse/IO-754
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.9.0, 2.10.0, 2.11.0
>Reporter: Sita Geßner
>Priority: Major
>
> I have a method to filter files with different extensions in a directory.
> I did override the accept method for WildcardFileFilter because I want to
> check the filename in lowercase, to find files with different spellings of
> the fileextension.
> After updating commons-io from 2.8.0 to 2.11.0 the accept-method is ignored.
> The breakpoint won't stop in the accept-method.
> Here is my codeexample:
> {code:java}
> public static void main(final String[] args) throws Exception {
> final File directory = new File(FileUtils.getTempDirectory(), "TEST");
> directory.mkdir();
> new File(directory, "TEST").mkdir();
> new File(directory, "test1.pdf").createNewFile();
> new File(directory, "test1.txt").createNewFile();
> new File(directory, "test2.PDF").createNewFile();
> new File(directory, "test2.TXT").createNewFile();
> final IOFileFilter filter = new WildcardFileFilter("*.pdf", "*.txt") {
> private static final long serialVersionUID = 1L;
> @Override
> public boolean accept(final File file) {
> return super.accept(file, file.getName().toLowerCase());
> }
> };
> for (final Iterator itFiles = FileUtils.iterateFiles(directory,
> filter, null); itFiles
> .hasNext();) {
> final File file = itFiles.next();
> System.out.println(file.getAbsolutePath());
> }
> }
> {code}
> output in version 2.8.0:
> {noformat}
> /tmp/TEST/test2.PDF
> /tmp/TEST/test1.txt
> /tmp/TEST/test1.pdf
> /tmp/TEST/test2.TXT
> {noformat}
> output in version 2.9.0 or higher:
> {noformat}
> /tmp/TEST/test1.txt
> /tmp/TEST/test1.pdf
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IO-754) WildcardFileFilter should not ignore override accept-method
[
https://issues.apache.org/jira/browse/IO-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17558048#comment-17558048
]
Gary D. Gregory commented on IO-754:
[~sgessner]
ping?
> WildcardFileFilter should not ignore override accept-method
> ---
>
> Key: IO-754
> URL: https://issues.apache.org/jira/browse/IO-754
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.9.0, 2.10.0, 2.11.0
>Reporter: Sita Geßner
>Priority: Major
>
> I have a method to filter files with different extensions in a directory.
> I did override the accept method for WildcardFileFilter because I want to
> check the filename in lowercase, to find files with different spellings of
> the fileextension.
> After updating commons-io from 2.8.0 to 2.11.0 the accept-method is ignored.
> The breakpoint won't stop in the accept-method.
> Here is my codeexample:
> {code:java}
> public static void main(final String[] args) throws Exception {
> final File directory = new File(FileUtils.getTempDirectory(), "TEST");
> directory.mkdir();
> new File(directory, "TEST").mkdir();
> new File(directory, "test1.pdf").createNewFile();
> new File(directory, "test1.txt").createNewFile();
> new File(directory, "test2.PDF").createNewFile();
> new File(directory, "test2.TXT").createNewFile();
> final IOFileFilter filter = new WildcardFileFilter("*.pdf", "*.txt") {
> private static final long serialVersionUID = 1L;
> @Override
> public boolean accept(final File file) {
> return super.accept(file, file.getName().toLowerCase());
> }
> };
> for (final Iterator itFiles = FileUtils.iterateFiles(directory,
> filter, null); itFiles
> .hasNext();) {
> final File file = itFiles.next();
> System.out.println(file.getAbsolutePath());
> }
> }
> {code}
> output in version 2.8.0:
> {noformat}
> /tmp/TEST/test2.PDF
> /tmp/TEST/test1.txt
> /tmp/TEST/test1.pdf
> /tmp/TEST/test2.TXT
> {noformat}
> output in version 2.9.0 or higher:
> {noformat}
> /tmp/TEST/test1.txt
> /tmp/TEST/test1.pdf
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IO-757) listFilesAndDirs doesn't list symbolicLinks when the original file has been deleted. The link does exist on OS
[
https://issues.apache.org/jira/browse/IO-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17558046#comment-17558046
]
Gary D. Gregory commented on IO-757:
[~wma] ping?
> listFilesAndDirs doesn't list symbolicLinks when the original file has been
> deleted. The link does exist on OS
> --
>
> Key: IO-757
> URL: https://issues.apache.org/jira/browse/IO-757
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.9.0
> Environment: Discovered on macOS Monterey 12.0.1 on Apple M1 Max
> openjdk version "11.0.13" 2021-10-19 LTS
> OpenJDK Runtime Environment Zulu11.52+13-CA (build 11.0.13+8-LTS)
> OpenJDK 64-Bit Server VM Zulu11.52+13-CA (build 11.0.13+8-LTS, mixed mode)
>Reporter: wma
>Priority: Major
> Attachments: commons-io-bug.zip
>
>
> When upgrading from version 2.8.0 to 2.11.0 i found out a difference in
> behaviour in the FileUtils.listFilesAndDirs method concerning symbolic links.
> I tracked it back to version 2.9.0 that introduced it. On the changelist of
> that release I found following that might be related/caused it:
> {quote}FileUtils.iterateFiles runs out of memory when executed for a
> directory with large number of files. Re-implement FileUtils' iterateFiles(),
> iterateFilesAndDirs(), listFiles(), listFilesAndDirs() to use NIO file tree
> walking instead of IO file listings to avoid memory consumption issues on
> large file trees. Fixes IO-597. Thanks to Gary Gregory, Arvind, Rob Spoor.
> {quote}
> The testcase is following:
> 1. create a file F in a directory D
> 2. create a symbolic link S to F in D
> 3. call FileUtils.listFilesAndDirs for D to verify setup is ok
> -> The results is 3 items, D, F and S
> 4. delete file F
> 5. call FileUtils.listFilesAndDirs for D
> -> Before release 2.9.0 the result here is 2 items. D and S, from release
> 2.9.0 on, the result is 1 item, only D. The symbolic link is not listed
> anymore while it does exist on disk still.
> I call this a bug as the result does not reflect the situation on disk and
> Files.list does show the symbolic link
> Included unit test project, succeeds when using version 2.8.0, fails when
> using 2.9.0
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (IO-759) behavior change of org.apache.commons.io.output.FileWriterWithEncoding
[
https://issues.apache.org/jira/browse/IO-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-759.
--
Resolution: Cannot Reproduce
Closing as CR, no test.
> behavior change of org.apache.commons.io.output.FileWriterWithEncoding
> --
>
> Key: IO-759
> URL: https://issues.apache.org/jira/browse/IO-759
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: Christoph Hart
>Priority: Major
>
> *behavior change* of
> {*}org.apache.commons.io.output.FileWriterWithEncoding{*}!
> - Using commons-io-2.10.0.jar overwritting a file just creates a new file
> with the new content.
> - Using commons-io-2.11.0.jar overwrites just the existing file with new
> content, but leaves the rest of previous biger content in the file.
> Code example:
> try (BufferedWriter fkfwr = new BufferedWriter(new
> FileWriterWithEncoding(ftokeyfile,"UTF-8"))) { ...
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (IO-773) RegexFileFilter is no longer Serializable
[ https://issues.apache.org/jira/browse/IO-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved IO-773. Resolution: Fixed > RegexFileFilter is no longer Serializable > - > > Key: IO-773 > URL: https://issues.apache.org/jira/browse/IO-773 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.10.0, 2.11.0 >Reporter: Dominik Reinarz >Priority: Major > Fix For: 2.12.0 > > > org.apache.commons.io.filefilter.RegexFileFilter cannot be serialized b/c > org.apache.commons.io.filefilter.RegexFileFilter.pathToString Function -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (CSV-298) Support Header in second Row
[ https://issues.apache.org/jira/browse/CSV-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed CSV-298. --- Resolution: Information Provided > Support Header in second Row > - > > Key: CSV-298 > URL: https://issues.apache.org/jira/browse/CSV-298 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Reporter: Stephen More >Priority: Minor > > I have to parse files where the first rows contains a timestamp and header > row is in the second row. > It would be great to code: > > Iterable records = > CSVFormat.RFC4180.withSecondRecordAsHeader().parse(in); -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (CSV-298) Support Header in second Row
[ https://issues.apache.org/jira/browse/CSV-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17557859#comment-17557859 ] Michael Osipov edited comment on CSV-298 at 6/23/22 7:14 AM: - Tomorrow I want to skip n lines and then read the header was (Author: michael-o): Tomorrow I want to skin n lines and then read the header > Support Header in second Row > - > > Key: CSV-298 > URL: https://issues.apache.org/jira/browse/CSV-298 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Reporter: Stephen More >Priority: Minor > > I have to parse files where the first rows contains a timestamp and header > row is in the second row. > It would be great to code: > > Iterable records = > CSVFormat.RFC4180.withSecondRecordAsHeader().parse(in); -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (CSV-298) Support Header in second Row
[ https://issues.apache.org/jira/browse/CSV-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17557859#comment-17557859 ] Michael Osipov commented on CSV-298: Tomorrow I want to skin n lines and then read the header > Support Header in second Row > - > > Key: CSV-298 > URL: https://issues.apache.org/jira/browse/CSV-298 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Reporter: Stephen More >Priority: Minor > > I have to parse files where the first rows contains a timestamp and header > row is in the second row. > It would be great to code: > > Iterable records = > CSVFormat.RFC4180.withSecondRecordAsHeader().parse(in); -- This message was sent by Atlassian Jira (v8.20.7#820007)
