[jira] [Created] (IO-823) The response time of some interfaces is inconsistent with the expected time.
Radar wen created IO-823: Summary: The response time of some interfaces is inconsistent with the expected time. Key: IO-823 URL: https://issues.apache.org/jira/browse/IO-823 Project: Commons IO Issue Type: Bug Reporter: Radar wen Scenario: Changing the System Time Zone Response Time of Some Interfaces Using Apache Commons I/O Is Inconsistent with the Expected Time Root cause: The internal waiting function is switched to ThreadUtil from 2.12.0 to 2.15.0 (the latest version is 2.15.0). The waiting implementation logic is as follows: !https://open.codehub.huawei.com/api/codehub/v1/projects/7676/uploads/4d562582-379f-4198-9f40-d64a717fc344/1700878640685.png! The internal ThreadUtil class determines whether to continue to wait based on the difference between the interface invoking time and the current time. When the system time and time zone are changed, the waiting time of ThreadUtil is inaccurate. Check affected functions. Class Method ThreadMonitor start FileSystemUtils performCommand FileSystemUtils freeSpace FileSystemUtils freeSpaceKb PathUtils waitFor FileUtils waitFor Tailer run FileAlterationMonitor start -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] Refactoring [commons-text]
shubham-1503 opened a new pull request, #478: URL: https://github.com/apache/commons-text/pull/478 (no comment) -- 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
Re: [PR] COMPRESS-632: Fixes for dump file parsing [commons-compress]
yakovsh commented on code in PR #442:
URL: https://github.com/apache/commons-compress/pull/442#discussion_r1406841978
##
src/main/java/org/apache/commons/compress/archivers/dump/DumpArchiveConstants.java:
##
@@ -26,7 +26,7 @@ public final class DumpArchiveConstants {
* The type of compression.
*/
public enum COMPRESSION_TYPE {
-ZLIB(0), BZLIB(1), LZO(2);
+UNKNOWN(-1), ZLIB(0), BZLIB(1), LZO(2);
Review Comment:
This prevents the NPE on line 208 of TapeInputStream:
https://github.com/apache/commons-compress/blob/master/src/main/java/org/apache/commons/compress/archivers/dump/TapeInputStream.java#L208
This is also what the "invalid_compression_type.dump" file is testing
--
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
Re: [PR] COMPRESS-632: Fixes for CPIO bugs [commons-compress]
yakovsh commented on code in PR #441:
URL: https://github.com/apache/commons-compress/pull/441#discussion_r1406805346
##
src/main/java/org/apache/commons/compress/archivers/cpio/CpioArchiveInputStream.java:
##
@@ -362,7 +362,11 @@ public int read(final byte[] b, final int off, final int
len) throws IOException
private long readAsciiLong(final int length, final int radix) throws
IOException {
final byte[] tmpBuffer = readRange(length);
-return Long.parseLong(ArchiveUtils.toAsciiString(tmpBuffer), radix);
+try {
Review Comment:
I created a new utils class ("ParsingUtils") and moved both Long and Integer
parsing from strings to that class + a unit test.
--
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-632) Improve fuzzing coverage in oss-fuzz
[ https://issues.apache.org/jira/browse/COMPRESS-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790278#comment-17790278 ] Yakov Shafranovich commented on COMPRESS-632: - The oss-fuzz PR has been merged in, please keep this issue open since I'm still working on the remaining fuzzers > Improve fuzzing coverage in oss-fuzz > > > Key: COMPRESS-632 > URL: https://issues.apache.org/jira/browse/COMPRESS-632 > Project: Commons Compress > Issue Type: Improvement >Reporter: Robin Schimpf >Priority: Major > > Fuzzing the library brought great stability improvements in the last couple > releases. But the current integration in oss-fuzz has only a limited scope. > Fuzzing is only done on the following classes: > * SevenZFile > * TarFile > * ZipFile > Additionally those fuzzing tests only open the file and are not reading the > file content. > IMHO the tests should be expanded to cover the following: > * Fuzz all supported formats (stream based and file based) > * Read the whole fuzzed file > I don't know if it makes sense to also fuzz archive creation. The only thing > which might be worth there would be the ArchiveEntries since fuzzing the file > content seems useless. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CRYPTO-136) Expose FIPS_mode_set() and FIPS_selftest() API
[ https://issues.apache.org/jira/browse/CRYPTO-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790274#comment-17790274 ] Sebb commented on CRYPTO-136: - FIPS_mode was not enabled in 1.1, and has been removed in 3.x See [https://www.openssl.org/docs/man3.0/man3/EVP_default_properties_is_fips_enabled.html] for info > Expose FIPS_mode_set() and FIPS_selftest() API > -- > > Key: CRYPTO-136 > URL: https://issues.apache.org/jira/browse/CRYPTO-136 > Project: Commons Crypto > Issue Type: Improvement > Components: Native >Reporter: Xiaodong Wang >Priority: Major > > Expose FIPS_mode_set() and FIPS_selftest() API > https://wiki.openssl.org/index.php/FIPS_mode_set() would allow applications > require FIPS compliance enter FIPS only mode, and run seft test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] LANG-1720: Fix Javadoc description of exceptions thrown for Conversion class [commons-lang]
arthurscchan opened a new pull request, #1139: URL: https://github.com/apache/commons-lang/pull/1139 The Javadoc description comments for most methods of the Conversion class, it contains a detailed description of the reason for some expected exceptions thrown by each method. These exceptions include but are not limited to different `IndexOutOfBoundsException` or `NullPointerException`. It is found that all variants of the `hexTo*()` method will throw `StringIndexOutOfBoundsException` if `srcPos + nHex > src.length` but this is not documented. Thus this PR provides an improvement of the relative Javadoc, mentioning that these methods could throw `StringIndexOutOfBoundsException`. -- 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] (CRYPTO-180) Need instructions for building distributions
[ https://issues.apache.org/jira/browse/CRYPTO-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-180. - Resolution: Fixed > Need instructions for building distributions > > > Key: CRYPTO-180 > URL: https://issues.apache.org/jira/browse/CRYPTO-180 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Priority: Major > > Crypto includes some native code that needs to be built for multiple > different environments. > This needs to be documented -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LANG-1720) Add better description of possible exception thrown by methods in the Javadoc
[ https://issues.apache.org/jira/browse/LANG-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17790263#comment-17790263 ] Bernd Eckenfels commented on LANG-1720: --- Good point, can you tell us which ones you missed the doc? > Add better description of possible exception thrown by methods in the Javadoc > - > > Key: LANG-1720 > URL: https://issues.apache.org/jira/browse/LANG-1720 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Sheung Chi Chan >Priority: Trivial > > Some static methods in the Conversion class do document that > IndexOutOfBoundsException or NullPointerException will be thrown from the > method in some cases. But there are some methods missing those documentation > in the Javadoc comments which could result in unexpected exceptions thrown. > It is suggested to have better description of what known exception could be > thrown from the methods. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] refactor: use ReentrantLock in PoolableConnection.close (#DBCP-591) [commons-dbcp]
cortlepp-intershop commented on PR #322: URL: https://github.com/apache/commons-dbcp/pull/322#issuecomment-1828575790 Hey @garydgregory @psteitz, just checking in: did you have a chance to think about this some more and how we could proceed here? -- 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] [Created] (LANG-1720) Add better description of possible exception thrown by methods in the Javadoc
Sheung Chi Chan created LANG-1720: - Summary: Add better description of possible exception thrown by methods in the Javadoc Key: LANG-1720 URL: https://issues.apache.org/jira/browse/LANG-1720 Project: Commons Lang Issue Type: Improvement Components: lang.* Reporter: Sheung Chi Chan Some static methods in the Conversion class do document that IndexOutOfBoundsException or NullPointerException will be thrown from the method in some cases. But there are some methods missing those documentation in the Javadoc comments which could result in unexpected exceptions thrown. It is suggested to have better description of what known exception could be thrown from the methods. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-179) Crash on macOS with default crypto library
[ https://issues.apache.org/jira/browse/CRYPTO-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-179. - Resolution: Fixed > Crash on macOS with default crypto library > -- > > Key: CRYPTO-179 > URL: https://issues.apache.org/jira/browse/CRYPTO-179 > Project: Commons Crypto > Issue Type: Bug >Reporter: Sebb >Priority: Major > > Attempts to use the default crypto library on macOS crash with a message of > the form: > ".../bin/java is loading libcrypto in an unsafe way" > It is not possible to catch this error as the application is aborted. > It would be useful to be able to detect this in advance. > The method dlopen_preflight() performs the same checks as dlopen(), and > returns "no such file" for the default library (presumably it is in the > system cache). > To avoid unnecessary checks, we can assume that a non-default library does > not need to be checked. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] COLLECTIONS-843: Implement Layered Bloom filter [commons-collections]
Claudenw commented on code in PR #402:
URL:
https://github.com/apache/commons-collections/pull/402#discussion_r1406448257
##
src/test/java/org/apache/commons/collections4/bloomfilter/CountingPredicateTest.java:
##
@@ -16,31 +16,103 @@
*/
package org.apache.commons.collections4.bloomfilter;
+import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertFalse;
import static org.junit.jupiter.api.Assertions.assertTrue;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.function.BiPredicate;
+
+import org.apache.commons.lang3.tuple.Pair;
import org.junit.jupiter.api.Test;
public class CountingPredicateTest {
+private List> expected = new ArrayList<>();
+private List> result = new ArrayList<>();
Review Comment:
@aherbert, thanks for the suggestion. I made the changes.
--
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
Re: [PR] CODEC-314: Fix possible IndexOutOfBoundsException thrown by PercentCodec.insertAlwaysEncodeChars() method [commons-codec]
arthurscchan commented on PR #222: URL: https://github.com/apache/commons-codec/pull/222#issuecomment-1828039723 Hi @garydgregory, thanks for your comments and suggestions. I will surely keep that in mind. -- 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
Re: [PR] CODEC-314: Fix possible IndexOutOfBoundsException thrown by PercentCodec.insertAlwaysEncodeChars() method [commons-codec]
garydgregory commented on PR #222: URL: https://github.com/apache/commons-codec/pull/222#issuecomment-1827859750 TY @arthurscchan Let's keep in mind that this is a library that needs to make sense (or try to) for users. As opposed to just addressing fuzzing issues in the most expedient manner ;-) TY again for your work :-) -- 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
Re: [PR] CODEC-314: Fix possible IndexOutOfBoundsException thrown by PercentCodec.insertAlwaysEncodeChars() method [commons-codec]
arthurscchan commented on PR #222: URL: https://github.com/apache/commons-codec/pull/222#issuecomment-1827848126 Hi @garydgregory, OK. Sorry for not considering in that direction. I will change the code in this PR to wrap around the possible IndexOutOfBoundException in an EncoderException, to at least decrease the change of "unpexected" input thrown directly from the constructor. That maybe a better approach. Thanks for your comments. -- 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
Re: [PR] CODEC-314: Fix possible IndexOutOfBoundsException thrown by PercentCodec.insertAlwaysEncodeChars() method [commons-codec]
garydgregory commented on PR #222: URL: https://github.com/apache/commons-codec/pull/222#issuecomment-1827843610 Hi @arthurscchan I'm not a fan of making the ctor overly clever in a way that was never documented and is not expected or obvious (IMO). This violates the principle of least surprise (IMO). We then risk some feature-creep, and setting expectations that other constructors should somehow sanitize their inputs. That is not the best approach for a lower-level library like Commons Codec I would offer. I'd rather the ctor throws an exception on garbage input. -- 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
Re: [PR] CODEC-314: Fix possible IndexOutOfBoundsException thrown by PercentCodec.insertAlwaysEncodeChars() method [commons-codec]
arthurscchan commented on PR #222: URL: https://github.com/apache/commons-codec/pull/222#issuecomment-1827774135 Hi @garydgregory, I think it is a different case. The invalid bytes are provided through constructor, it is only used for the initial setting of the PercentCodec object to set which bytes are to be encoded during the encode or decode method. Thus if we initialise the PercentCodec with a byte array contains invalid bytes, it just mean that the encode method will not encode that byte. It does not affect the encode and decode process at all. Thus the encode / decode method round trip won't be affected and the result is the same as the original input. Maybe I could add a round trip call and ensure the result are the same in the test case. Alternatively, instead of checking the length and skip the invalid byte during constructor phase, I could simply add a try catch block in the code, when any IndexOutOfBound (or more general, and kind of RuntimeException) is thrown, wrap it with EncoderException. This could at least make the method not throwing "unexpected" RuntimeException. It maybe a better approach. WDYT? -- 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
Re: [PR] CODEC-314: Fix possible IndexOutOfBoundsException thrown by PercentCodec.insertAlwaysEncodeChars() method [commons-codec]
arthurscchan commented on PR #222: URL: https://github.com/apache/commons-codec/pull/222#issuecomment-1827764168 @garydgregory Oh, you are right, if we filtered out invalid data, then the round trip result will be differed from the original input. Sorry for missing that. Maybe throwing EncoderException is much better. Instead of checking the length and skip the invalid byte, I could simply add a try catch block in the code, when any IndexOutOfBound (or more general, and kind of RuntimeException) is thrown, wrap it with EncoderException. This could at least make the method not throwing "unexpected" RuntimeException. It maybe a better approach. WDYT? -- 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
Re: [PR] Refactoring Using techniques in Set 1 [commons-digester]
garydgregory commented on PR #108: URL: https://github.com/apache/commons-digester/pull/108#issuecomment-1827724597 Hello @shreyakapoor08 It would be more helpful if you looked at our Jira database and fixed bugs instead of proposing non-functional changes. Any PR takes time to review... -- 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
