[jira] [Created] (IO-773) RegexFileFilter is no longer Serializable
Dominik Reinarz created IO-773: -- Summary: 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.11.0 Reporter: Dominik Reinarz 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)
[GitHub] [commons-crypto] wenwj0 commented on pull request #164: CRYPTO-162 openSslCipher support engine
wenwj0 commented on PR #164: URL: https://github.com/apache/commons-crypto/pull/164#issuecomment-1154827771 Thanks for replying. I know that it's diffcult to maintain the native parts, I understand your choice. Besides, if you need any help, i can do it :) -- 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=781011=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-781011
]
ASF GitHub Bot logged work on CRYPTO-162:
-
Author: ASF GitHub Bot
Created on: 14/Jun/22 07:38
Start Date: 14/Jun/22 07:38
Worklog Time Spent: 10m
Work Description: wenwj0 commented on PR #164:
URL: https://github.com/apache/commons-crypto/pull/164#issuecomment-1154827771
Thanks for replying.
I know that it's diffcult to maintain the native parts, I understand your
choice.
Besides, if you need any help, i can do it :)
Issue Time Tracking
---
Worklog Id: (was: 781011)
Time Spent: 50m (was: 40m)
> 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: 50m
> 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] garydgregory commented on a diff in pull request #165: CRYPTO-162 openSslCipher support engine.
garydgregory commented on code in PR #165:
URL: https://github.com/apache/commons-crypto/pull/165#discussion_r896652302
##
src/main/java/org/apache/commons/crypto/cipher/OpenSsl.java:
##
@@ -378,4 +378,7 @@ protected void finalize() throws Throwable {
clean();
}
+public void engineSetDefaultCiphers(String engineId){
Review Comment:
Missing Javadoc, fix formatting.
##
src/main/java/org/apache/commons/crypto/cipher/OpenSslCipher.java:
##
@@ -60,6 +60,11 @@ public OpenSslCipher(final Properties props, final String
transformation) // NOP
}
openSslEngine = OpenSsl.getInstance(transformation);
+
+String engineId =
props.getProperty(CryptoCipherFactory.CIPHER_ENGINE_KEY);
+if(engineId != null && !engineId.isEmpty()) {
Review Comment:
Fix formatting.
##
src/main/java/org/apache/commons/crypto/cipher/OpenSslNative.java:
##
@@ -159,4 +159,6 @@ public native static int doFinalByteArray(long context,
byte[] output,
* @param context The cipher context address
*/
public native static void clean(long context);
+
Review Comment:
Missing Javadoc.
--
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=781075=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-781075
]
ASF GitHub Bot logged work on CRYPTO-162:
-
Author: ASF GitHub Bot
Created on: 14/Jun/22 10:34
Start Date: 14/Jun/22 10:34
Worklog Time Spent: 10m
Work Description: garydgregory commented on code in PR #165:
URL: https://github.com/apache/commons-crypto/pull/165#discussion_r896652302
##
src/main/java/org/apache/commons/crypto/cipher/OpenSsl.java:
##
@@ -378,4 +378,7 @@ protected void finalize() throws Throwable {
clean();
}
+public void engineSetDefaultCiphers(String engineId){
Review Comment:
Missing Javadoc, fix formatting.
##
src/main/java/org/apache/commons/crypto/cipher/OpenSslCipher.java:
##
@@ -60,6 +60,11 @@ public OpenSslCipher(final Properties props, final String
transformation) // NOP
}
openSslEngine = OpenSsl.getInstance(transformation);
+
+String engineId =
props.getProperty(CryptoCipherFactory.CIPHER_ENGINE_KEY);
+if(engineId != null && !engineId.isEmpty()) {
Review Comment:
Fix formatting.
##
src/main/java/org/apache/commons/crypto/cipher/OpenSslNative.java:
##
@@ -159,4 +159,6 @@ public native static int doFinalByteArray(long context,
byte[] output,
* @param context The cipher context address
*/
public native static void clean(long context);
+
Review Comment:
Missing Javadoc.
Issue Time Tracking
---
Worklog Id: (was: 781075)
Time Spent: 1h (was: 50m)
> 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
> 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)
[jira] [Work logged] (CRYPTO-162) openSslCipher support engine
[
https://issues.apache.org/jira/browse/CRYPTO-162?focusedWorklogId=781003=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-781003
]
ASF GitHub Bot logged work on CRYPTO-162:
-
Author: ASF GitHub Bot
Created on: 14/Jun/22 07:02
Start Date: 14/Jun/22 07:02
Worklog Time Spent: 10m
Work Description: jochenw commented on PR #164:
URL: https://github.com/apache/commons-crypto/pull/164#issuecomment-1154795891
My impression is, that you wish to extend Crypto from a pure random
generator towards a decoding/encoding engine.
While this seems interesting, I am nevertheless opposed to it: The native
parts of Crypto are already a heavy maintenance burden, as they are. Mostly,
due to the need to support multiple binary platforms. (Most of us have
typically a single one, or two at the most.)
So, sorry!
Issue Time Tracking
---
Worklog Id: (was: 781003)
Time Spent: 40m (was: 0.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: 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] jochenw commented on pull request #164: CRYPTO-162 openSslCipher support engine
jochenw commented on PR #164: URL: https://github.com/apache/commons-crypto/pull/164#issuecomment-1154795891 My impression is, that you wish to extend Crypto from a pure random generator towards a decoding/encoding engine. While this seems interesting, I am nevertheless opposed to it: The native parts of Crypto are already a heavy maintenance burden, as they are. Mostly, due to the need to support multiple binary platforms. (Most of us have typically a single one, or two at the most.) So, sorry! -- 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] (IO-773) RegexFileFilter is no longer Serializable
[ https://issues.apache.org/jira/browse/IO-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553997#comment-17553997 ] Dominik Reinarz commented on IO-773: java.io.NotSerializableException: org.apache.commons.io.filefilter.RegexFileFilter$$Lambda$2302/0x0008021533e8 at java.base/java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1197) > 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.11.0 >Reporter: Dominik Reinarz >Priority: Major > > 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] [Updated] (IO-773) RegexFileFilter is no longer Serializable
[ https://issues.apache.org/jira/browse/IO-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominik Reinarz updated IO-773: --- Affects Version/s: 2.10.0 > 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 > > 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)
[GitHub] [commons-collections] aherbert commented on pull request #258: Simplify bloom filters
aherbert commented on PR #258: URL: https://github.com/apache/commons-collections/pull/258#issuecomment-1154993294 Some of the issues are simple to fix here. But if all comments have been captured then a merge will at least bring in the large improvements in this update and finer details can be worked on after. Also note that when reviewing I stopped commenting on trivial javadoc issues to reduce noise so there will be some work to clean up this aspect too. -- 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] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?focusedWorklogId=781156=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-781156
]
ASF GitHub Bot logged work on VFS-683:
--
Author: ASF GitHub Bot
Created on: 14/Jun/22 12:46
Start Date: 14/Jun/22 12:46
Worklog Time Spent: 10m
Work Description: milleruntime commented on issue #2775:
URL: https://github.com/apache/accumulo/issues/2775#issuecomment-1155139000
So can we do a 1.10.3 release with the good commons-vfs 2.1 jar? This bug
seems nasty enough that we don't want users to have to rebuild Accumulo on
their own.
Issue Time Tracking
---
Worklog Id: (was: 781156)
Time Spent: 20m (was: 10m)
> 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: 20m
> 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] [Commented] (IO-771) FilenameUtils#getFullPathNoEndSeparator - Different behaviour between windows and linux
[
https://issues.apache.org/jira/browse/IO-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554118#comment-17554118
]
Sita Geßner commented on IO-771:
[~ggregory] No, unfortunatly I don't know where and how to resolve this issue.
> FilenameUtils#getFullPathNoEndSeparator - Different behaviour between windows
> and linux
> ---
>
> Key: IO-771
> URL: https://issues.apache.org/jira/browse/IO-771
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.6
>Reporter: Sita Geßner
>Priority: Minor
>
> When using FilenameUtils#getFullPathNoEndSeparator with directories, windows
> and linux are returning different results.
> Linux returns ".../subfolder" and windows returns "...\path".
> {code:java}
> private static void commonsIo() {
> String result = getSubFolderFromFile(new
> File("C:\\path\\subfolder\\"));
> // Fails in common-io:2.11.0 b/c result is "path" instead of
> "subfolder".
> System.out.println("result should be \"subfolder\", but it is: " +
> result);
> }
> private static String getSubFolderFromFile(final File file) {
> return
> FilenameUtils.getBaseName(FilenameUtils.getFullPathNoEndSeparator(file.getAbsolutePath()));
> }
> {code}
> The result should be equal when using both OS.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (IO-773) RegexFileFilter is no longer Serializable
[ https://issues.apache.org/jira/browse/IO-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554130#comment-17554130 ] Dominik Reinarz edited comment on IO-773 at 6/14/22 5:09 PM: - 2.12.0-SNAPSHOT build works! Thanks for the quick fix! was (Author: dr.z): 2.12.0-SNAPSHOT build works! > 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] [Commented] (IO-773) RegexFileFilter is no longer Serializable
[ https://issues.apache.org/jira/browse/IO-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554163#comment-17554163 ] Gary D. Gregory commented on IO-773: [~dr.z] Good news, thank you for testing your use case. > 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] [Resolved] (IO-762) FileSystem.WINDOWS.isReservedFileName doesn't check for file extension
[
https://issues.apache.org/jira/browse/IO-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved IO-762.
Fix Version/s: 2.12.0
Assignee: Gary D. Gregory
Resolution: Fixed
[~leonidas_chiron]
In git master. Please verify and close.
Also available as a 2.12.0-SNAPSHOT build from
https://repository.apache.org/content/repositories/snapshots/commons-io/commons-io/2.12.0-SNAPSHOT/
> FileSystem.WINDOWS.isReservedFileName doesn't check for file extension
> --
>
> Key: IO-762
> URL: https://issues.apache.org/jira/browse/IO-762
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.11.0
> Environment: Java 8 (AdoptOpenjdk), tested on both linux (debian 10)
> and windows (2008 R2)
>Reporter: Leonidas Chiron
>Assignee: Gary D. Gregory
>Priority: Minor
> Fix For: 2.12.0
>
>
> FileSystem.WINDOWS.isReservedFileName() doesn't check file names without
> extension, for instance FileSystem.WINDOWS.isReservedFileName("COM1.txt")
> returns false but the creation of the latter file on a Windows platform will
> fail.
> Also the method should be case-insensitive, eg
> FileSystem.WINDOWS.isReservedFileName("com1") should return true
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [commons-ognl] dependabot[bot] opened a new pull request, #75: Bump h2 from 2.1.210 to 2.1.214
dependabot[bot] opened a new pull request, #75: URL: https://github.com/apache/commons-ognl/pull/75 Bumps [h2](https://github.com/h2database/h2database) from 2.1.210 to 2.1.214. Release notes Sourced from https://github.com/h2database/h2database/releases;>h2's releases. version-2.1.214 Important bugs and regression fixes discovered after 2.1.210 release: Version 2.1.212 Numerous bugs and regression fixes discovered after 2.1.210 release: ... (truncated) Commits https://github.com/h2database/h2database/commit/1ba3590b5d29581a14b018b966e5da0a8ff2994c;>1ba3590 release preparation - another minor adjustment https://github.com/h2database/h2database/commit/bbb5a590b91597649b19f81a5f89ecb4bf44d33d;>bbb5a59 release preparation - minor version https://github.com/h2database/h2database/commit/01ad7fbdf8454de4023233b736785b59a326f1a6;>01ad7fb release preparation https://github.com/h2database/h2database/commit/48e5d1000a2ec65a91e92f1a70d40bbcade76e09;>48e5d10 Merge pull request https://github-redirect.dependabot.com/h2database/h2database/issues/3540;>#3540 from katzyn/compatibility https://github.com/h2database/h2database/commit/1fbdd510301a0f4b86d9079a7b2d006481302689;>1fbdd51 Update PgJDBC to version 42.4.0 https://github.com/h2database/h2database/commit/c0d989e43f73cb90d01948009705301423712f5d;>c0d989e Use DECFLOAT for NUMERIC without parameters in PostgreSQL compatibility mode https://github.com/h2database/h2database/commit/726bc266a1d1863df6cf41236a31b85f76820aa1;>726bc26 Merge pull request https://github-redirect.dependabot.com/h2database/h2database/issues/3539;>#3539 from katzyn/parameters https://github.com/h2database/h2database/commit/90caa1d36a21fc0b0b58e2fbefd83e46acff9bd0;>90caa1d Fix missing parameters in some subqueries https://github.com/h2database/h2database/commit/28eec321385687e0133e4867a71db8db940a23aa;>28eec32 Merge pull request https://github-redirect.dependabot.com/h2database/h2database/issues/3532;>#3532 from katzyn/misc https://github.com/h2database/h2database/commit/05d5999c0a065b9974c1698cfb494a69fd06a4ef;>05d5999 Add more helper methods Additional commits viewable in https://github.com/h2database/h2database/compare/version-2.1.210...version-2.1.214;>compare view [](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
[GitHub] [commons-ognl] dependabot[bot] commented on pull request #71: Bump h2 from 2.1.210 to 2.1.212
dependabot[bot] commented on PR #71: URL: https://github.com/apache/commons-ognl/pull/71#issuecomment-1155609893 Superseded by #75. -- 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-ognl] dependabot[bot] closed pull request #71: Bump h2 from 2.1.210 to 2.1.212
dependabot[bot] closed pull request #71: Bump h2 from 2.1.210 to 2.1.212 URL: https://github.com/apache/commons-ognl/pull/71 -- 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] [Updated] (IO-763) [Javadoc] FileFilterUtils doc does not match impl: missing some file filters
[
https://issues.apache.org/jira/browse/IO-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-763:
---
Summary: [Javadoc] FileFilterUtils doc does not match impl: missing some
file filters (was: [Javadoc] o.a.c.i.filefilter.FileFilterUtils doc does not
match impl: missing some file filters)
> [Javadoc] FileFilterUtils doc does not match impl: missing some file filters
>
>
> Key: IO-763
> URL: https://issues.apache.org/jira/browse/IO-763
> Project: Commons IO
> Issue Type: Improvement
> Components: Filters
>Affects Versions: 2.11.0
> Environment: Any
>Reporter: Richard Adams
>Priority: Minor
> Fix For: 2.12.0
>
>
> In the documentation for {{org.apache.commons.io.filefilter.FileFilterUtils}}
> {code:java}
> Useful utilities for working with file filters. It provides access to all *
> file filter implementations in this package so you don't have to import *
> every class you use. {code}
> it says it provides access to *all* FileFilter implementations.
> But, it doesn't provide access to RegexFileFilter, SymbolicLinkFileFilter, or
> HiddenFileFilter .
> Is this
> 1) Incorrect Javadoc - only _some_ implementations should be available from
> {{FileFilterUtils.}}
> or
> 2) FileFilterUtils is incomplete and missing these implementations.
> If this is a valid issue I'd be happy to submit a PR fixing this either way.
> Richard
--
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=781178=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-781178
]
ASF GitHub Bot logged work on VFS-683:
--
Author: ASF GitHub Bot
Created on: 14/Jun/22 13:21
Start Date: 14/Jun/22 13:21
Worklog Time Spent: 10m
Work Description: ctubbsii commented on issue #2775:
URL: https://github.com/apache/accumulo/issues/2775#issuecomment-1155180247
We don't need to do a release for this. It's just a drop-in replacement on
their class path. No need to rebuild Accumulo at all. I'd wait for a resolution
upstream, bump to that version, then just include it in the next release. In
the meantime, can update the release notes for the current version to add a
"Known issues" section and link them to the VFS issue for a workaround/solution
that works for them.
Issue Time Tracking
---
Worklog Id: (was: 781178)
Time Spent: 0.5h (was: 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: 0.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] [Comment Edited] (IO-773) RegexFileFilter is no longer Serializable
[
https://issues.apache.org/jira/browse/IO-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554103#comment-17554103
]
Gary D. Gregory edited comment on IO-773 at 6/14/22 1:47 PM:
-
Hi [~dr.z]
Thank you for your report.
Please try with git master or a 2.12.0-SNAPSHOT build from
https://repository.apache.org/content/repositories/snapshots/commons-io/commons-io/2.12.0-SNAPSHOT/
{{RegexFileFilter#RegexFileFilter(Pattern)}} now creates a serializable lambda,
so other constructors that call it will create a serializable instance.
If you call {{{}RegexFileFilter#RegexFileFilter(Pattern, Function){}}}, you'll have to make the lambda serializable before passing it in.
was (Author: garydgregory):
Hi [~dr.z]
Thank you for your report.
Please try with git master or a 2.12.0-SNAPSHOT build from
[https://repository.apache.org/content/repositories/snapshots/|https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-lang3/]
{{RegexFileFilter#RegexFileFilter(Pattern)}} now creates a serializable lambda,
so other constructors that call it will create a serializable instance.
If you call {{{}RegexFileFilter#RegexFileFilter(Pattern, Function){}}}, you'll have to make the lambda serializable before passing it in.
> 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] [Work logged] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?focusedWorklogId=781241=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-781241
]
ASF GitHub Bot logged work on VFS-683:
--
Author: ASF GitHub Bot
Created on: 14/Jun/22 14:19
Start Date: 14/Jun/22 14:19
Worklog Time Spent: 10m
Work Description: dlmarion commented on issue #2775:
URL: https://github.com/apache/accumulo/issues/2775#issuecomment-1155258470
The AccumuloVFSClassLoader class in `1.10` has not substantively changed
since 2014 according to the git log. My guess is that AccumuloVFSClassLoader is
susceptible to the issue in VFS-683, but more recent versions of commons-vfs
have increased the probability of it occurring.
Issue Time Tracking
---
Worklog Id: (was: 781241)
Time Spent: 40m (was: 0.5h)
> 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: 40m
> 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] [Work logged] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?focusedWorklogId=781286=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-781286
]
ASF GitHub Bot logged work on VFS-683:
--
Author: ASF GitHub Bot
Created on: 14/Jun/22 15:11
Start Date: 14/Jun/22 15:11
Worklog Time Spent: 10m
Work Description: dlmarion commented on issue #2775:
URL: https://github.com/apache/accumulo/issues/2775#issuecomment-1155334357
I'm thinking we should move the commons-vfs version back to 2.1 in `main`
and https://github.com/apache/accumulo-classloaders. We can move the version
back to 2.1 for any future 1.x and 2.0.x releases. Thoughts?
Issue Time Tracking
---
Worklog Id: (was: 781286)
Time Spent: 50m (was: 40m)
> 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: 50m
> 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] [Work logged] (CRYPTO-162) openSslCipher support engine
[
https://issues.apache.org/jira/browse/CRYPTO-162?focusedWorklogId=781121=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-781121
]
ASF GitHub Bot logged work on CRYPTO-162:
-
Author: ASF GitHub Bot
Created on: 14/Jun/22 11:56
Start Date: 14/Jun/22 11:56
Worklog Time Spent: 10m
Work Description: garydgregory commented on PR #164:
URL: https://github.com/apache/commons-crypto/pull/164#issuecomment-1155085762
Since Crypto is a thin wrapper over OpenSSL, I don't see why we would not
wrap more of its APIs, so this seems ok to me, if there were suitable tests.
Issue Time Tracking
---
Worklog Id: (was: 781121)
Time Spent: 1h 10m (was: 1h)
> 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 10m
> 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] garydgregory commented on pull request #164: CRYPTO-162 openSslCipher support engine
garydgregory commented on PR #164: URL: https://github.com/apache/commons-crypto/pull/164#issuecomment-1155085762 Since Crypto is a thin wrapper over OpenSSL, I don't see why we would not wrap more of its APIs, so this seems ok to me, if there were suitable tests. -- 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] [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. Fix Version/s: 2.12.0 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] [Updated] (IO-763) [Javadoc] o.a.c.i.filefilter.FileFilterUtils doc does not match impl: missing some file filters
[
https://issues.apache.org/jira/browse/IO-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-763:
---
Summary: [Javadoc] o.a.c.i.filefilter.FileFilterUtils doc does not match
impl: missing some file filters (was: [Javadoc]
o.a.c.i.filefilter.FileFilterUtils is missing implementations of some file
filters.)
> [Javadoc] o.a.c.i.filefilter.FileFilterUtils doc does not match impl: missing
> some file filters
> ---
>
> Key: IO-763
> URL: https://issues.apache.org/jira/browse/IO-763
> Project: Commons IO
> Issue Type: Improvement
> Components: Filters
>Affects Versions: 2.11.0
> Environment: Any
>Reporter: Richard Adams
>Priority: Minor
>
> In the documentation for {{org.apache.commons.io.filefilter.FileFilterUtils}}
> {code:java}
> Useful utilities for working with file filters. It provides access to all *
> file filter implementations in this package so you don't have to import *
> every class you use. {code}
> it says it provides access to *all* FileFilter implementations.
> But, it doesn't provide access to RegexFileFilter, SymbolicLinkFileFilter, or
> HiddenFileFilter .
> Is this
> 1) Incorrect Javadoc - only _some_ implementations should be available from
> {{FileFilterUtils.}}
> or
> 2) FileFilterUtils is incomplete and missing these implementations.
> If this is a valid issue I'd be happy to submit a PR fixing this either way.
> Richard
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IO-773) RegexFileFilter is no longer Serializable
[ https://issues.apache.org/jira/browse/IO-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554130#comment-17554130 ] Dominik Reinarz commented on IO-773: 2.12.0-SNAPSHOT build works! > 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] [Work logged] (CRYPTO-162) openSslCipher support engine
[
https://issues.apache.org/jira/browse/CRYPTO-162?focusedWorklogId=781132=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-781132
]
ASF GitHub Bot logged work on CRYPTO-162:
-
Author: ASF GitHub Bot
Created on: 14/Jun/22 12:10
Start Date: 14/Jun/22 12:10
Worklog Time Spent: 10m
Work Description: wenwj0 commented on code in PR #165:
URL: https://github.com/apache/commons-crypto/pull/165#discussion_r896736733
##
src/main/java/org/apache/commons/crypto/cipher/OpenSslNative.java:
##
@@ -159,4 +159,6 @@ public native static int doFinalByteArray(long context,
byte[] output,
* @param context The cipher context address
*/
public native static void clean(long context);
+
Review Comment:
ok
Issue Time Tracking
---
Worklog Id: (was: 781132)
Time Spent: 1h 20m (was: 1h 10m)
> 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 20m
> 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 a diff in pull request #165: CRYPTO-162 openSslCipher support engine.
wenwj0 commented on code in PR #165: URL: https://github.com/apache/commons-crypto/pull/165#discussion_r896736733 ## src/main/java/org/apache/commons/crypto/cipher/OpenSslNative.java: ## @@ -159,4 +159,6 @@ public native static int doFinalByteArray(long context, byte[] output, * @param context The cipher context address */ public native static void clean(long context); + Review Comment: ok -- 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] (IO-772) Confusing doc on IOUtils::resourceToURL
[
https://issues.apache.org/jira/browse/IO-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554108#comment-17554108
]
Gary D. Gregory commented on IO-772:
[~zman0900]
Do you plan on creating a PR?
> Confusing doc on IOUtils::resourceToURL
> ---
>
> Key: IO-772
> URL: https://issues.apache.org/jira/browse/IO-772
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.11.0
>Reporter: Dan Ziemba
>Priority: Trivial
>
> The Javadoc for IOUtils::resourceToURL (and the String and byte[] variants)
> says that the "name" parameter is expected to be absolute and is not well
> defined otherwise. When this is called without a ClassLoader, using an
> absolute path makes sense as Class::getResource is called against a class
> that is not the caller's, so a non-absolute path would be looking inside the
> commons-io package. But when called with a ClassLoader, instead the
> ClassLoader::getResource method is called, and using an absolute path with
> that does not work the same way.
> For example, both of these work the same for a file sitting at the root of
> the classpath (src/main/resources in typical Maven/Gradle build):
> * {{IOUtils.resourceToString("/file.txt");}}
> * {{IOUtils.resourceToString("file.txt", getClass().getClassLoader());}}
> But this does not work:
> * {{IOUtils.resourceToString("/file.txt", getClass().getClassLoader());}}
> That behavior is consistent with the explanation in this [accepted
> StackOverflow answer|[https://stackoverflow.com/a/51645482/1270447].]
> I believe the doc on the method variants that take a ClassLoader should call
> this out.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (IO-767) FileUtils will become unextendable in future according to @deprecated comment
[
https://issues.apache.org/jira/browse/IO-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed IO-767.
--
Resolution: Not A Problem
Closing: Information is given and no feedback from the reporter.
> FileUtils will become unextendable in future according to @deprecated comment
> -
>
> Key: IO-767
> URL: https://issues.apache.org/jira/browse/IO-767
> Project: Commons IO
> Issue Type: Wish
> Components: Utilities
>Affects Versions: 2.11.0
>Reporter: Paul Pogonyshev
>Priority: Major
>
> Source code of FileUtils currently has this in the doccomment before the
> constructor: "@deprecated Will be private in 3.0.". This will make FileUtils
> unextendable, breaking existing code (e.g. that of our application).
> Our usecase: we extend several *Utils classes from Apache Commons libraries
> to add our own utility methods, yet still avoid caring if they are "from a
> standard library" or our extension. E.g. we can use code like 'import
> our.application.FileUtils;' and then 'FileUtils.copyDirectory(...)' (using
> Apache-provided method) and 'FileUtils.doSomeFunnyStuff(...)' (using our
> internal utility function). Thus we don't clutter 'import' block and avoid
> either 1) specifying fully-qualified class name if we had to use two
> different 'FileUtils' classes; or 2) renaming our class into something ugly
> like 'OurAppFileUtils'.
> If Apache Commons makes their utility classes unextendable, we will no longer
> be able to do this. This is the disadvantage for us and anyone else using
> similar class layout. I don't see any advantages in making utility classes
> unextendable other than having compiler bark at 'new FileUtils()' code some
> newcomers would try once in lifetime.
> Proposal: make utility classes abstract instead, so that they can be
> extended, but not instantiated. If you absolutely want to prohibit
> instantiation even of subclasses (also anonymous), add a protected
> constructor like this:
> {{ public FileUtils() {}}
> {{ throw new UnsupportedOperationException("FileUtils may not be
> instantiated");}}
> {{ }}}
> Yes, this would at runtime instead of at compilation time, but I'd say that's
> worth it for something that should practically never be atempted anyway.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IO-765) Integrating commons-io into oss-fuzz
[ https://issues.apache.org/jira/browse/IO-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554126#comment-17554126 ] Gary D. Gregory commented on IO-765: You can use me as a contact. > Integrating commons-io into oss-fuzz > > > Key: IO-765 > URL: https://issues.apache.org/jira/browse/IO-765 > Project: Commons IO > Issue Type: Improvement >Reporter: Dae Glendowne >Priority: Minor > > Hi all, > I have prepared the [initial > integration|https://github.com/CodeIntelligenceTesting/oss-fuzz/commit/69da3f46605253cfe14258d10702b4d3fdc81aff] > of commons-io into [google oss-fuzz|https://github.com/google/oss-fuzz]. > This will enable continuous fuzzing of this project, which will be conducted > by Google. Bugs that will be found by fuzzing will be reported to you. After > the initial integration of this project into oss-fuzz, I will continue to add > additional fuzz tests to improve the code coverage over time. > The integration requires a primary contact, someone to deal with the bug > reports submitted by oss-fuzz. The email address needs to belong to an > established project committer and be associated with a Google account as per > [here|https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/]. > When a bug is found, you will receive an email that will provide you with > access to ClusterFuzz, crash reports, and fuzzer statistics. More than 1 > person can be included. Please let me know who I should include, if anyone. > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer] is used for > fuzzing Java applications. Jazzer is a coverage-guided, in-process fuzzer for > the JVM platform developed by Code Intelligence. It is based on libFuzzer and > brings many of its instrumentation-powered mutation features to the JVM. > Jazzer has already found several bugs in JVM applications: [Jazzer > Findings|https://github.com/CodeIntelligenceTesting/jazzer#findings] > Please let me know if you have any questions regarding fuzzing or the > oss-fuzz integration. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IO-763) [Javadoc] o.a.c.i.filefilter.FileFilterUtils is missing implementations of some file filters.
[
https://issues.apache.org/jira/browse/IO-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated IO-763:
---
Summary: [Javadoc] o.a.c.i.filefilter.FileFilterUtils is missing
implementations of some file filters. (was: o.a.c.i.filefilter.FileFilterUtils
is missing implementations of some file filters.)
> [Javadoc] o.a.c.i.filefilter.FileFilterUtils is missing implementations of
> some file filters.
> -
>
> Key: IO-763
> URL: https://issues.apache.org/jira/browse/IO-763
> Project: Commons IO
> Issue Type: Improvement
> Components: Filters
>Affects Versions: 2.11.0
> Environment: Any
>Reporter: Richard Adams
>Priority: Minor
>
> In the documentation for {{org.apache.commons.io.filefilter.FileFilterUtils}}
> {code:java}
> Useful utilities for working with file filters. It provides access to all *
> file filter implementations in this package so you don't have to import *
> every class you use. {code}
> it says it provides access to *all* FileFilter implementations.
> But, it doesn't provide access to RegexFileFilter, SymbolicLinkFileFilter, or
> HiddenFileFilter .
> Is this
> 1) Incorrect Javadoc - only _some_ implementations should be available from
> {{FileFilterUtils.}}
> or
> 2) FileFilterUtils is incomplete and missing these implementations.
> If this is a valid issue I'd be happy to submit a PR fixing this either way.
> Richard
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (IO-763) [Javadoc] o.a.c.i.filefilter.FileFilterUtils doc does not match impl: missing some file filters
[
https://issues.apache.org/jira/browse/IO-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved IO-763.
Fix Version/s: 2.12.0
Resolution: Fixed
Since there is no PR since this issue was created, I took the simplest approach
and updated the Java from "all" to "most".
> [Javadoc] o.a.c.i.filefilter.FileFilterUtils doc does not match impl: missing
> some file filters
> ---
>
> Key: IO-763
> URL: https://issues.apache.org/jira/browse/IO-763
> Project: Commons IO
> Issue Type: Improvement
> Components: Filters
>Affects Versions: 2.11.0
> Environment: Any
>Reporter: Richard Adams
>Priority: Minor
> Fix For: 2.12.0
>
>
> In the documentation for {{org.apache.commons.io.filefilter.FileFilterUtils}}
> {code:java}
> Useful utilities for working with file filters. It provides access to all *
> file filter implementations in this package so you don't have to import *
> every class you use. {code}
> it says it provides access to *all* FileFilter implementations.
> But, it doesn't provide access to RegexFileFilter, SymbolicLinkFileFilter, or
> HiddenFileFilter .
> Is this
> 1) Incorrect Javadoc - only _some_ implementations should be available from
> {{FileFilterUtils.}}
> or
> 2) FileFilterUtils is incomplete and missing these implementations.
> If this is a valid issue I'd be happy to submit a PR fixing this either way.
> Richard
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [commons-configuration] garydgregory commented on a diff in pull request #186: [CONFIGURATION-813]: Support both javax and jakarta namespace in mailapi
garydgregory commented on code in PR #186:
URL:
https://github.com/apache/commons-configuration/pull/186#discussion_r896730985
##
src/main/java/org/apache/commons/configuration2/convert/PropertyConverter.java:
##
@@ -70,6 +70,9 @@ public final class PropertyConverter {
/** The fully qualified name of {@code
javax.mail.internet.InternetAddress} */
private static final String INTERNET_ADDRESS_CLASSNAME =
"javax.mail.internet.InternetAddress";
+/** The fully qualified name of {@code
jakarta.mail.internet.InternetAddress} */
Review Comment:
Maybe rename the other constant to have a JAVAX postfix?
--
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-configuration] garydgregory commented on a diff in pull request #186: [CONFIGURATION-813]: Support both javax and jakarta namespace in mailapi
garydgregory commented on code in PR #186:
URL:
https://github.com/apache/commons-configuration/pull/186#discussion_r896731746
##
src/test/java/org/apache/commons/configuration2/TestDataConfiguration.java:
##
@@ -73,10 +73,13 @@ private static Date expectedDate() throws ParseException {
/**
* Create an instance of InternetAddress. This trick is necessary to
compile and run the test with Java 1.3 and the
- * javamail-1.4 which is not compatible with Java 1.3
+ * javamail-1.4 which is not compatible with Java 1.3.
+ *
+ * javamail-2.0 had a namespace change, moving javax.mail.* to
jakarta.mail.*. This test verifies if we have
+ * javax.mail.* in the classpath before trying the Jakarta classes.
*/
private Object createInternetAddress(final String email) throws Exception {
-final Class cls =
Class.forName("javax.mail.internet.InternetAddress");
+final Class cls =
Class.forName("jakarta.mail.internet.InternetAddress");
Review Comment:
Reuse the constant you created above.
--
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-crypto] wenwj0 commented on a diff in pull request #165: CRYPTO-162 openSslCipher support engine.
wenwj0 commented on code in PR #165:
URL: https://github.com/apache/commons-crypto/pull/165#discussion_r896736961
##
src/main/java/org/apache/commons/crypto/cipher/OpenSslCipher.java:
##
@@ -60,6 +60,11 @@ public OpenSslCipher(final Properties props, final String
transformation) // NOP
}
openSslEngine = OpenSsl.getInstance(transformation);
+
+String engineId =
props.getProperty(CryptoCipherFactory.CIPHER_ENGINE_KEY);
+if(engineId != null && !engineId.isEmpty()) {
Review Comment:
ok
##
src/main/java/org/apache/commons/crypto/cipher/OpenSsl.java:
##
@@ -378,4 +378,7 @@ protected void finalize() throws Throwable {
clean();
}
+public void engineSetDefaultCiphers(String engineId){
Review Comment:
ok
--
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=781134=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-781134
]
ASF GitHub Bot logged work on CRYPTO-162:
-
Author: ASF GitHub Bot
Created on: 14/Jun/22 12:11
Start Date: 14/Jun/22 12:11
Worklog Time Spent: 10m
Work Description: wenwj0 commented on code in PR #165:
URL: https://github.com/apache/commons-crypto/pull/165#discussion_r896736961
##
src/main/java/org/apache/commons/crypto/cipher/OpenSslCipher.java:
##
@@ -60,6 +60,11 @@ public OpenSslCipher(final Properties props, final String
transformation) // NOP
}
openSslEngine = OpenSsl.getInstance(transformation);
+
+String engineId =
props.getProperty(CryptoCipherFactory.CIPHER_ENGINE_KEY);
+if(engineId != null && !engineId.isEmpty()) {
Review Comment:
ok
##
src/main/java/org/apache/commons/crypto/cipher/OpenSsl.java:
##
@@ -378,4 +378,7 @@ protected void finalize() throws Throwable {
clean();
}
+public void engineSetDefaultCiphers(String engineId){
Review Comment:
ok
Issue Time Tracking
---
Worklog Id: (was: 781134)
Time Spent: 1.5h (was: 1h 20m)
> 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: 1.5h
> 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)
[jira] [Work logged] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?focusedWorklogId=781139=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-781139
]
ASF GitHub Bot logged work on VFS-683:
--
Author: ASF GitHub Bot
Created on: 14/Jun/22 12:27
Start Date: 14/Jun/22 12:27
Worklog Time Spent: 10m
Work Description: dlmarion opened a new issue, #2775:
URL: https://github.com/apache/accumulo/issues/2775
**Describe the bug**
The commons-vfs dependency was bumped from 2.1 to 2.3 as part of
https://github.com/apache/accumulo/pull/1295. User is reporting running into
issue [VFS-683](https://issues.apache.org/jira/projects/VFS/issues/VFS-683)
with this updated commons-vfs dependency and rolling back the deployed
commons-vfs jar to 2.1 resolves the issue.
**Versions (OS, Maven, Java, and others, as appropriate):**
rel/1.10.0
rel/1.10.1
rel/1.10.2
rel/2.0.0
rel/2.0.1
The version of commons-vfs in `main` is 2.9.0, not sure if that version
presents the same issue. Based on the comments in VFS-683, my guess is that it
does still have the issue.
Issue Time Tracking
---
Worklog Id: (was: 781139)
Remaining Estimate: 0h
Time Spent: 10m
> 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: 10m
> 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)
[GitHub] [commons-configuration] garydgregory commented on a diff in pull request #186: [CONFIGURATION-813]: Support both javax and jakarta namespace in mailapi
garydgregory commented on code in PR #186:
URL:
https://github.com/apache/commons-configuration/pull/186#discussion_r896733283
##
src/main/java/org/apache/commons/configuration2/convert/PropertyConverter.java:
##
@@ -607,12 +612,22 @@ static Object toInternetAddress(final Object value)
throws ConversionException {
if (value.getClass().getName().equals(INTERNET_ADDRESS_CLASSNAME)) {
return value;
}
+if
(value.getClass().getName().equals(INTERNET_ADDRESS_CLASSNAME_JAKARTA)) {
+return value;
+}
if (!(value instanceof String)) {
throw new ConversionException("The value " + value + " can't be
converted to a InternetAddress");
}
try {
-final Constructor ctor =
Class.forName(INTERNET_ADDRESS_CLASSNAME).getConstructor(String.class);
-return ctor.newInstance(value);
+try {
Review Comment:
So this WILL cause a class cast exception? How is that ok?
--
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-configuration] garydgregory commented on a diff in pull request #186: [CONFIGURATION-813]: Support both javax and jakarta namespace in mailapi
garydgregory commented on code in PR #186:
URL:
https://github.com/apache/commons-configuration/pull/186#discussion_r896732187
##
src/test/java/org/apache/commons/configuration2/TestDataConfiguration.java:
##
@@ -839,7 +842,7 @@ public void testConversionException() throws Exception {
}
try {
-conf.get(Class.forName("javax.mail.internet.InternetAddress"),
"key1");
+conf.get(Class.forName("jakarta.mail.internet.InternetAddress"),
"key1");
Review Comment:
Another magic string, reuse the constant...
--
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] (IO-773) RegexFileFilter is no longer Serializable
[
https://issues.apache.org/jira/browse/IO-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554103#comment-17554103
]
Gary D. Gregory commented on IO-773:
Hi [~dr.z]
Thank you for your report.
Please try with git master or a 3.13.0-SNAPSHOT build from
[https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-lang3/]
{{RegexFileFilter#RegexFileFilter(Pattern)}} now creates a serializable lambda,
so other constructors that call it will create a serializable instance.
If you call {{{}RegexFileFilter#RegexFileFilter(Pattern, Function){}}}, you'll have to make the lambda serializable before passing it in.
> 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
>
> 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] [Comment Edited] (IO-773) RegexFileFilter is no longer Serializable
[
https://issues.apache.org/jira/browse/IO-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554103#comment-17554103
]
Gary D. Gregory edited comment on IO-773 at 6/14/22 1:43 PM:
-
Hi [~dr.z]
Thank you for your report.
Please try with git master or a 2.12.0-SNAPSHOT build from
[https://repository.apache.org/content/repositories/snapshots/|https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-lang3/]
{{RegexFileFilter#RegexFileFilter(Pattern)}} now creates a serializable lambda,
so other constructors that call it will create a serializable instance.
If you call {{{}RegexFileFilter#RegexFileFilter(Pattern, Function){}}}, you'll have to make the lambda serializable before passing it in.
was (Author: garydgregory):
Hi [~dr.z]
Thank you for your report.
Please try with git master or a 3.13.0-SNAPSHOT build from
[https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-lang3/]
{{RegexFileFilter#RegexFileFilter(Pattern)}} now creates a serializable lambda,
so other constructors that call it will create a serializable instance.
If you call {{{}RegexFileFilter#RegexFileFilter(Pattern, Function){}}}, you'll have to make the lambda serializable before passing it in.
> 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] [Commented] (IO-771) FilenameUtils#getFullPathNoEndSeparator - Different behaviour between windows and linux
[
https://issues.apache.org/jira/browse/IO-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554109#comment-17554109
]
Gary D. Gregory commented on IO-771:
[~sgessner]
Do you plan on creating a PR?
> FilenameUtils#getFullPathNoEndSeparator - Different behaviour between windows
> and linux
> ---
>
> Key: IO-771
> URL: https://issues.apache.org/jira/browse/IO-771
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.6
>Reporter: Sita Geßner
>Priority: Minor
>
> When using FilenameUtils#getFullPathNoEndSeparator with directories, windows
> and linux are returning different results.
> Linux returns ".../subfolder" and windows returns "...\path".
> {code:java}
> private static void commonsIo() {
> String result = getSubFolderFromFile(new
> File("C:\\path\\subfolder\\"));
> // Fails in common-io:2.11.0 b/c result is "path" instead of
> "subfolder".
> System.out.println("result should be \"subfolder\", but it is: " +
> result);
> }
> private static String getSubFolderFromFile(final File file) {
> return
> FilenameUtils.getBaseName(FilenameUtils.getFullPathNoEndSeparator(file.getAbsolutePath()));
> }
> {code}
> The result should be equal when using both OS.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IO-769) FileUtils.copyFileToDirectory can lead to not accessible file when preserving the file date
[ https://issues.apache.org/jira/browse/IO-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-769: --- Summary: FileUtils.copyFileToDirectory can lead to not accessible file when preserving the file date (was: FileUtils.copyFileToDirectory can lead to not accessible file when preserving the filedate) > FileUtils.copyFileToDirectory can lead to not accessible file when preserving > the file date > --- > > Key: IO-769 > URL: https://issues.apache.org/jira/browse/IO-769 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.11.0 >Reporter: Jérémy Carnus >Priority: Major > > Hi, > The current implementation for copyFileToDirectory by default preserve the > file. > There 2 issues regarding this: > * the javadoc mentions this is done by File.setLastModified by in fact this > is done by the COPY_ATTRIBUTES options > * Under Windows, the COPY_ATTRIBUTES also copies the security attributes > (SID and permissions) and can lead to a file not beeing readable after copy > (if for example, you copie from a mount under docker or a shared folder) > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (IO-722) Improve FileUtils.touch() Javadoc to clarify it does not behave like GNU touch
[ https://issues.apache.org/jira/browse/IO-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved IO-722. Fix Version/s: 2.12.0 Resolution: Fixed Javadoc updated. > Improve FileUtils.touch() Javadoc to clarify it does not behave like GNU touch > -- > > Key: IO-722 > URL: https://issues.apache.org/jira/browse/IO-722 > Project: Commons IO > Issue Type: Improvement >Reporter: Thib Guicherd-Callin >Priority: Minor > Fix For: 2.12.0 > > > The Javadoc of FileUtils.touch() says it behaves like the Unix touch utility. > I'm not sure about the Unix one, but the GNU one does not create intermediate > directories (e.g. touch /tmp/foo/bar/baz does not succeed if /tmp/foo/bar/ > does not already exist). Currently there is a paragraph further down in the > Javadoc that says 'Also, as from v1.3 this method creates parent directories > if they do not exist', but the implication in the leading sentence that it > behaves like Unix touch is misleading. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (IO-652) Spring Clean .gitignore
[ https://issues.apache.org/jira/browse/IO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed IO-652. -- Resolution: Not A Problem Closing ticket: PR is closed. > 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: 50m > 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.20.7#820007)
[jira] [Commented] (IO-707) Add optional early error detection as postcondition check
[ https://issues.apache.org/jira/browse/IO-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554302#comment-17554302 ] Gary D. Gregory commented on IO-707: [~beAshish] Anyone can create a PR on GitHub. > Add optional early error detection as postcondition check > - > > Key: IO-707 > URL: https://issues.apache.org/jira/browse/IO-707 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.8.0 >Reporter: Boris Unckel >Priority: Major > Time Spent: 2h 20m > Remaining Estimate: 0h > > The current version does not include an optional way to detect errors with > the underlying filesystem and/or logic early. > Due to performance reason and/or design decision, the result of delete or > create directories/files does not include a check wheter the delete or create > was successful. It "only" relies on trust to the underlying operations of the > JDK and/or the completeness of own unit tests. > To have the option to check things, without having additional commons-io > proprietary options and without a performance impact for regular operations > the Java 1.4 keyword "assert" should be used. > Current project profits in case of detail analysis. Downstream projects > having own unit tests for IO will profit. > PR with proposal will follow. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [commons-configuration] darkma773r opened a new pull request, #187: Make default interpolation prefix lookups configurable
darkma773r opened a new pull request, #187: URL: https://github.com/apache/commons-configuration/pull/187 - Make default interpolation prefix lookups configurable via system property. - Remove dns, url, and script lookups from defaults. -- 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-configuration] darkma773r commented on a diff in pull request #186: [CONFIGURATION-813]: Support both javax and jakarta namespace in mailapi
darkma773r commented on code in PR #186:
URL:
https://github.com/apache/commons-configuration/pull/186#discussion_r897504090
##
src/main/java/org/apache/commons/configuration2/convert/PropertyConverter.java:
##
@@ -70,6 +70,9 @@ public final class PropertyConverter {
/** The fully qualified name of {@code
javax.mail.internet.InternetAddress} */
private static final String INTERNET_ADDRESS_CLASSNAME =
"javax.mail.internet.InternetAddress";
+/** The fully qualified name of {@code
jakarta.mail.internet.InternetAddress} */
Review Comment:
Good idea. See #188
--
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-configuration] darkma773r commented on a diff in pull request #186: [CONFIGURATION-813]: Support both javax and jakarta namespace in mailapi
darkma773r commented on code in PR #186:
URL:
https://github.com/apache/commons-configuration/pull/186#discussion_r897504422
##
src/test/java/org/apache/commons/configuration2/TestDataConfiguration.java:
##
@@ -73,10 +73,13 @@ private static Date expectedDate() throws ParseException {
/**
* Create an instance of InternetAddress. This trick is necessary to
compile and run the test with Java 1.3 and the
- * javamail-1.4 which is not compatible with Java 1.3
+ * javamail-1.4 which is not compatible with Java 1.3.
+ *
+ * javamail-2.0 had a namespace change, moving javax.mail.* to
jakarta.mail.*. This test verifies if we have
+ * javax.mail.* in the classpath before trying the Jakarta classes.
*/
private Object createInternetAddress(final String email) throws Exception {
-final Class cls =
Class.forName("javax.mail.internet.InternetAddress");
+final Class cls =
Class.forName("jakarta.mail.internet.InternetAddress");
Review Comment:
This entire method was actually not needed anymore. There is no longer any
reason to not instantiate `InternetAddress` directly.
--
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] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?focusedWorklogId=781455=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-781455
]
ASF GitHub Bot logged work on VFS-683:
--
Author: ASF GitHub Bot
Created on: 15/Jun/22 03:18
Start Date: 15/Jun/22 03:18
Worklog Time Spent: 10m
Work Description: ctubbsii commented on issue #2775:
URL: https://github.com/apache/accumulo/issues/2775#issuecomment-1155938228
> I'm thinking we should move the commons-vfs version back to 2.1 in `main`
and https://github.com/apache/accumulo-classloaders. We can move the version
back to 2.1 for any future 1.x and 2.0.x releases. Thoughts?
2.1 isn't bug free... every version of VFS has had some kind of seriously
annoying bug. I think us chasing the *right* version of VFS to have on the
class path is a lost cause. Why not just wait for upstream to patch and release
a fixed version we can bump to? If users want a specific VFS version to avoid
specific bugs and to tolerate other specific bugs in VFS, they can take some
responsibility to manage their own class path to get their preferred bugset.
Issue Time Tracking
---
Worklog Id: (was: 781455)
Time Spent: 1h (was: 50m)
> 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: 1h
> 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)
[GitHub] [commons-configuration] darkma773r opened a new pull request, #188: CONFIGURATION-813: mailapi follow up
darkma773r opened a new pull request, #188: URL: https://github.com/apache/commons-configuration/pull/188 - simplify mailapi type conversions -- 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-configuration] darkma773r commented on a diff in pull request #186: [CONFIGURATION-813]: Support both javax and jakarta namespace in mailapi
darkma773r commented on code in PR #186:
URL:
https://github.com/apache/commons-configuration/pull/186#discussion_r897508540
##
src/main/java/org/apache/commons/configuration2/convert/PropertyConverter.java:
##
@@ -607,12 +612,22 @@ static Object toInternetAddress(final Object value)
throws ConversionException {
if (value.getClass().getName().equals(INTERNET_ADDRESS_CLASSNAME)) {
return value;
}
+if
(value.getClass().getName().equals(INTERNET_ADDRESS_CLASSNAME_JAKARTA)) {
+return value;
+}
if (!(value instanceof String)) {
throw new ConversionException("The value " + value + " can't be
converted to a InternetAddress");
}
try {
-final Constructor ctor =
Class.forName(INTERNET_ADDRESS_CLASSNAME).getConstructor(String.class);
-return ctor.newInstance(value);
+try {
Review Comment:
Good point. I suppose the scenario might be like this:
- A user has both mailapi version on the classpath.
- They call `convert` passing in the javax InternetAddress class.
- The converter sees that some type of InternetAddress has been requested
and attempts to load the jakarta version, which is found.
- A new jakarta InternetAddress is returned, which causes a class cast
exception when being assigned to the javax InternetAddress variable.
I've provided a fix for this in #188, where we only attempt to load and cast
to the actual type given. Let me know what you think.
--
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-configuration] darkma773r commented on pull request #186: [CONFIGURATION-813]: Support both javax and jakarta namespace in mailapi
darkma773r commented on PR #186: URL: https://github.com/apache/commons-configuration/pull/186#issuecomment-1155952801 @garydgregory, thanks for the feedback! Please take a look at #188 and let me know what you think. -- 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-configuration] asfgit merged pull request #187: Make default interpolation prefix lookups configurable
asfgit merged PR #187: URL: https://github.com/apache/commons-configuration/pull/187 -- 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-configuration] darkma773r commented on a diff in pull request #186: [CONFIGURATION-813]: Support both javax and jakarta namespace in mailapi
darkma773r commented on code in PR #186:
URL:
https://github.com/apache/commons-configuration/pull/186#discussion_r897506536
##
src/test/java/org/apache/commons/configuration2/TestDataConfiguration.java:
##
@@ -839,7 +842,7 @@ public void testConversionException() throws Exception {
}
try {
-conf.get(Class.forName("javax.mail.internet.InternetAddress"),
"key1");
+conf.get(Class.forName("jakarta.mail.internet.InternetAddress"),
"key1");
Review Comment:
This can simply be a direct class reference.
--
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
