[GitHub] [commons-configuration] kinow commented on pull request #37: Configuration-766: BigDecimal(double) should not be used.
kinow commented on PR #37: URL: https://github.com/apache/commons-configuration/pull/37#issuecomment-1121962737 Rebased. See my previous comment on the patch from JIRA and updating the tests too :+1: -- 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] kinow commented on a diff in pull request #107: Bump mailapi from 1.6.6 to 2.0.1
kinow commented on code in PR #107:
URL:
https://github.com/apache/commons-configuration/pull/107#discussion_r868840083
##
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:
In the tests, I think it doesn't make sense to support javax and jakarta,
since mailapi is bringing javamail 2.x with the Jakarta namespace.
--
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] kinow commented on pull request #107: Bump mailapi from 1.6.6 to 2.0.1
kinow commented on PR #107: URL: https://github.com/apache/commons-configuration/pull/107#issuecomment-1121956939 From their release notes, looks like there's a package that was renamed for the Jakarta namespace.  I did a quick fix locally and pushed after it passed for me. There's a JIRA for that too now, CONFIGURATION-813, and I'll ping others to see what they think about this issue & tentative solution. -Bruno -- 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] (TEXT-215) NumericEntityUnescaper may miss decimal entity
[
https://issues.apache.org/jira/browse/TEXT-215?focusedWorklogId=768321=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-768321
]
ASF GitHub Bot logged work on TEXT-215:
---
Author: ASF GitHub Bot
Created on: 10/May/22 05:44
Start Date: 10/May/22 05:44
Worklog Time Spent: 10m
Work Description: kinow commented on PR #310:
URL: https://github.com/apache/commons-text/pull/310#issuecomment-1121955771
> Thanks for the quick answer ! I'm not subscribed yet, but will do it right
now, and then I'll send the email to explain my PR. Thank you very much !
Brilliant!
Every component is discussed there, that's the only downside. Use the
following prefix for your subject, please: "[text] Enter your email subject
here".
I have a rule in GMail to move it to another folder so that I can take a
look when I'm not busy. You can ignore emails for components you are not
interested (I'm about to write one for Commons Configuration).
Hopefully we will find a solution for this issue and fix & release it soon.
Thanks!!!
Issue Time Tracking
---
Worklog Id: (was: 768321)
Time Spent: 2h (was: 1h 50m)
> NumericEntityUnescaper may miss decimal entity
> --
>
> Key: TEXT-215
> URL: https://issues.apache.org/jira/browse/TEXT-215
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Richard Bunel
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
> *Description:*
> A security breach can be used in the NumericEntityUnescaper through the use
> of decimal character entities.
> At
> [line|https://github.com/apache/commons-text/blob/master/src/main/java/org/apache/commons/text/translate/NumericEntityUnescaper.java#L117]
> 117 a string of hexadecimal characters are searched, whether or not the
> entity is an hexadecimal one.
> Therefore, if the "semiColonOptional" option is enabled and a deicmal entity
> without semi-colon is immediately followed by one or several letters from A
> to F, these letters will be caught. The Integer parsing with a radix at 10
> will then fail and the whole entity will be ignored.
> *Example:*
> If one uses the following string:
> {code:java}
> {code}
> The sequence identifying the entity will wrongly be
[GitHub] [commons-text] kinow commented on pull request #310: TEXT-215: Prevent decimal numeric entities from wrongly including hexadecimal characters
kinow commented on PR #310: URL: https://github.com/apache/commons-text/pull/310#issuecomment-1121955771 > Thanks for the quick answer ! I'm not subscribed yet, but will do it right now, and then I'll send the email to explain my PR. Thank you very much ! Brilliant! Every component is discussed there, that's the only downside. Use the following prefix for your subject, please: "[text] Enter your email subject here". I have a rule in GMail to move it to another folder so that I can take a look when I'm not busy. You can ignore emails for components you are not interested (I'm about to write one for Commons Configuration). Hopefully we will find a solution for this issue and fix & release it soon. Thanks!!! -- 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] (TEXT-215) NumericEntityUnescaper may miss decimal entity
[
https://issues.apache.org/jira/browse/TEXT-215?focusedWorklogId=768320=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-768320
]
ASF GitHub Bot logged work on TEXT-215:
---
Author: ASF GitHub Bot
Created on: 10/May/22 05:40
Start Date: 10/May/22 05:40
Worklog Time Spent: 10m
Work Description: rbunel35 commented on PR #310:
URL: https://github.com/apache/commons-text/pull/310#issuecomment-1121953889
Thanks for the quick answer !
I'm not subscribed yet, but will do it right now, and then I'll send the
email to explain my PR.
Thank you very much !
Issue Time Tracking
---
Worklog Id: (was: 768320)
Time Spent: 1h 50m (was: 1h 40m)
> NumericEntityUnescaper may miss decimal entity
> --
>
> Key: TEXT-215
> URL: https://issues.apache.org/jira/browse/TEXT-215
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Richard Bunel
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> *Description:*
> A security breach can be used in the NumericEntityUnescaper through the use
> of decimal character entities.
> At
> [line|https://github.com/apache/commons-text/blob/master/src/main/java/org/apache/commons/text/translate/NumericEntityUnescaper.java#L117]
> 117 a string of hexadecimal characters are searched, whether or not the
> entity is an hexadecimal one.
> Therefore, if the "semiColonOptional" option is enabled and a deicmal entity
> without semi-colon is immediately followed by one or several letters from A
> to F, these letters will be caught. The Integer parsing with a radix at 10
> will then fail and the whole entity will be ignored.
> *Example:*
> If one uses the following string:
> {code:java}
> {code}
> The sequence identifying the entity will wrongly be
[GitHub] [commons-text] rbunel35 commented on pull request #310: TEXT-215: Prevent decimal numeric entities from wrongly including hexadecimal characters
rbunel35 commented on PR #310: URL: https://github.com/apache/commons-text/pull/310#issuecomment-1121953889 Thanks for the quick answer ! I'm not subscribed yet, but will do it right now, and then I'll send the email to explain my PR. Thank you very much ! -- 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] (CONFIGURATION-813) Support javamail 2.0 in Configuration (package renamed, javax -> jakarta)
Bruno P. Kinoshita created CONFIGURATION-813: Summary: Support javamail 2.0 in Configuration (package renamed, javax -> jakarta) Key: CONFIGURATION-813 URL: https://issues.apache.org/jira/browse/CONFIGURATION-813 Project: Commons Configuration Issue Type: Bug Reporter: Bruno P. Kinoshita Via dependabot, I will update the PR with a tentative fix. https://github.com/apache/commons-configuration/pull/107 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work logged] (TEXT-215) NumericEntityUnescaper may miss decimal entity
[
https://issues.apache.org/jira/browse/TEXT-215?focusedWorklogId=768316=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-768316
]
ASF GitHub Bot logged work on TEXT-215:
---
Author: ASF GitHub Bot
Created on: 10/May/22 05:28
Start Date: 10/May/22 05:28
Worklog Time Spent: 10m
Work Description: kinow commented on PR #310:
URL: https://github.com/apache/commons-text/pull/310#issuecomment-1121947467
> Hey @kinow,
>
> I hope I'm not too much impatient (sorry if that's the case ^^) but do you
have news about this PR ? You mentioned I could bump you if it took too long.
>
> Thanks in advance !
Hi @rbunel35
Thanks for the remainder. I'm starting a new job in a few months, and will
have about one month with extra spare time, when I expect to be able to release
Text if nobody else beats me to it.
I think we will have to move this question to a wider audience, @rbunel35 .
We have two options here, I can send the email to the Commons Dev [mailing
list](https://commons.apache.org/mail-lists.html) explaining what the PR is
fixing, and trying to explain on the difference between browsers & specs, or if
you are subscribed you can send the email over there.
The only difference, I think, is that I may forget the issue again if there
are no replies over there :smile: in which case you'd have to ping me again. Up
to you :+1:
Thanks!!!
Bruno
Issue Time Tracking
---
Worklog Id: (was: 768316)
Time Spent: 1h 40m (was: 1.5h)
> NumericEntityUnescaper may miss decimal entity
> --
>
> Key: TEXT-215
> URL: https://issues.apache.org/jira/browse/TEXT-215
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Richard Bunel
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> *Description:*
> A security breach can be used in the NumericEntityUnescaper through the use
> of decimal character entities.
> At
> [line|https://github.com/apache/commons-text/blob/master/src/main/java/org/apache/commons/text/translate/NumericEntityUnescaper.java#L117]
> 117 a string of hexadecimal characters are searched, whether or not the
> entity is an hexadecimal one.
> Therefore, if the "semiColonOptional" option is enabled and a deicmal entity
> without semi-colon is immediately followed by one or several letters from A
> to F, these letters will be caught. The Integer parsing with a radix at 10
> will then fail and the whole entity will be ignored.
> *Example:*
> If one uses the following string:
> {code:java}
> {code}
> The sequence identifying the entity will wrongly be
[GitHub] [commons-text] kinow commented on pull request #310: TEXT-215: Prevent decimal numeric entities from wrongly including hexadecimal characters
kinow commented on PR #310: URL: https://github.com/apache/commons-text/pull/310#issuecomment-1121947467 > Hey @kinow, > > I hope I'm not too much impatient (sorry if that's the case ^^) but do you have news about this PR ? You mentioned I could bump you if it took too long. > > Thanks in advance ! Hi @rbunel35 Thanks for the remainder. I'm starting a new job in a few months, and will have about one month with extra spare time, when I expect to be able to release Text if nobody else beats me to it. I think we will have to move this question to a wider audience, @rbunel35 . We have two options here, I can send the email to the Commons Dev [mailing list](https://commons.apache.org/mail-lists.html) explaining what the PR is fixing, and trying to explain on the difference between browsers & specs, or if you are subscribed you can send the email over there. The only difference, I think, is that I may forget the issue again if there are no replies over there :smile: in which case you'd have to ping me again. Up to you :+1: Thanks!!! Bruno -- 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] (TEXT-215) NumericEntityUnescaper may miss decimal entity
[
https://issues.apache.org/jira/browse/TEXT-215?focusedWorklogId=768315=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-768315
]
ASF GitHub Bot logged work on TEXT-215:
---
Author: ASF GitHub Bot
Created on: 10/May/22 05:24
Start Date: 10/May/22 05:24
Worklog Time Spent: 10m
Work Description: rbunel35 commented on PR #310:
URL: https://github.com/apache/commons-text/pull/310#issuecomment-1121945534
Hey @kinow,
I hope I'm not too much impatient (sorry if that's the case ^^) but do you
have news about this PR ?
You mentioned I could bump you if it took too long.
Thanks in advance !
Issue Time Tracking
---
Worklog Id: (was: 768315)
Time Spent: 1.5h (was: 1h 20m)
> NumericEntityUnescaper may miss decimal entity
> --
>
> Key: TEXT-215
> URL: https://issues.apache.org/jira/browse/TEXT-215
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Richard Bunel
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> *Description:*
> A security breach can be used in the NumericEntityUnescaper through the use
> of decimal character entities.
> At
> [line|https://github.com/apache/commons-text/blob/master/src/main/java/org/apache/commons/text/translate/NumericEntityUnescaper.java#L117]
> 117 a string of hexadecimal characters are searched, whether or not the
> entity is an hexadecimal one.
> Therefore, if the "semiColonOptional" option is enabled and a deicmal entity
> without semi-colon is immediately followed by one or several letters from A
> to F, these letters will be caught. The Integer parsing with a radix at 10
> will then fail and the whole entity will be ignored.
> *Example:*
> If one uses the following string:
> {code:java}
> {code}
> The sequence identifying the entity will wrongly be
[GitHub] [commons-text] rbunel35 commented on pull request #310: TEXT-215: Prevent decimal numeric entities from wrongly including hexadecimal characters
rbunel35 commented on PR #310: URL: https://github.com/apache/commons-text/pull/310#issuecomment-1121945534 Hey @kinow, I hope I'm not too much impatient (sorry if that's the case ^^) but do you have news about this PR ? You mentioned I could bump you if it took too long. Thanks in advance ! -- 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-fileupload] dependabot[bot] opened a new pull request, #145: Bump spotbugs from 4.6.0 to 4.7.0
dependabot[bot] opened a new pull request, #145: URL: https://github.com/apache/commons-fileupload/pull/145 Bumps [spotbugs](https://github.com/spotbugs/spotbugs) from 4.6.0 to 4.7.0. Release notes Sourced from https://github.com/spotbugs/spotbugs/releases;>spotbugs's releases. SpotBugs 4.7.0 CHANGELOG Changed Updated documentation by adding parenthesis () to the negative odd check message (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1995;>#1995) https://github.com/axkr;>@axkr Let the Plugin class implement AutoCloseable so we can release the .jar file (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/2024;>#2024) https://github.com/gtoison;>@gtoison Fixed Fixed reports to truncate existing files before writing new content (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1950;>#1950) https://github.com/sdati;>@sdati Fixed traversal of nested archives governed by -nested:true (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1930;>#1930) https://github.com/Vogel612;>@Vogel612 Warnings of deprecated System::setSecurityManager calls on Java 17 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1983;>#1983) https://github.com/wborn;>@wborn Fixed false positive SSD bug for locking on java.lang.Class objects (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1978;>#1978) https://github.com/jpschewe;>@jpschewe FindReturnRef throws an IllegalArgumentException unexpectedly (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/2019;>#2019) https://github.com/KengoTODA;>@KengoTODA Bumped Saxon-HE from 10.6 to 11.3 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1955;>#1955, https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1999;>#1999) Bump ObjectWeb ASM from 9.2 to 9.3 supporting JDK 19 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/2004;>#2004) Added New detector ThrowingExceptions and introduced new bug types https://github.com/oroszbd;>@oroszbd THROWS_METHOD_THROWS_RUNTIMEEXCEPTION is reported in case of a method throwing RuntimeException, THROWS_METHOD_THROWS_CLAUSE_BASIC_EXCEPTION is reported when a method has Exception in its throws clause and THROWS_METHOD_THROWS_CLAUSE_THROWABLE is reported when a method has Throwable in its throws clause (See https://wiki.sei.cmu.edu/confluence/display/java/ERR07-J.+Do+not+throw+RuntimeException%2C+Exception%2C+or+Throwable;>SEI CERT ERR07-J) New rule PERM_SUPER_NOT_CALLED_IN_GETPERMISSIONS to warn for custom class loaders who do not call their superclasses' getPermissions() in their getPermissions() method. This rule based on the SEI CERT rule SEC07-J Call the superclass's getPermissions() method when writing a custom class loader. (https://wiki.sei.cmu.edu/confluence/display/java/SEC07-J.+Call+the+superclass%27s+getPermissions%28%29+method+when+writing+a+custom+class+loader;>#SEC07-J) https://github.com/baloghadamsoftware;>@baloghadamsoftware New rule USC_POTENTIAL_SECURITY_CHECK_BASED_ON_UNTRUSTED_SOURCE to detect cases where a non-final method of a non-final class is called from public methods of public classes and then the same method is called on the same object inside a doPrivileged block. Since the called method may have been overridden to behave differently on the first and second invocations this is a possible security check based on an unreliable source. This rule is based on SEC02-J. Do not base security checks on untrusted sources. (https://wiki.sei.cmu.edu/confluence/display/java/SEC02-J.+Do+not+base+security+checks+on+untrusted+sources;>#SEC02-J) https://github.com/baloghadamsoftware;>@baloghadamsoftware New detector DontUseFloatsAsLoopCounters to detect usage of floating-point variables as loop counters (FL_FLOATS_AS_LOOP_COUNTERS), according to SEI CERT rules https://wiki.sei.cmu.edu/confluence/display/java/NUM09-J.+Do+not+use+floating-point+variables+as+loop+counters;>NUM09-J. Do not use floating-point variables as loop counters https://github.com/adrianturtoczki;>@adrianturtoczki New test detector ViewCFG to visualize the control-flow graph for SpotBugs developers https://github.com/baloghadamsoftware;>@baloghadamsoftware CHECKSUM file checksum (sha256) spotbugs-4.7.0-javadoc.jar 43745221e8fdf50fa2f89d659034523dd58da3d10223de6e0c91704c07e025a0 spotbugs-4.7.0-sources.jar 6e90f856826b48a3031e2cb903534b4fdb494759863ea14e8df93c9cf15a272c spotbugs-4.7.0.tgz 8c871e279c7d9b1933158db6355b8ac817a84fd724b88b1e393e3abcf6874910 spotbugs-4.7.0.zip 9ee793b0f3f78901089211dfa67b8603e38fd1abd64eac09d2590df506cfedf5 spotbugs-annotations-4.7.0-javadoc.jar 76a9a7d45590494a220840d173809b2fe0ec50e554435dd9b28de9312cc6a34a spotbugs-annotations-4.7.0-sources.jar
[jira] [Commented] (JEXL-367) Named function and fat-arrow (=>) lambda syntax
[ https://issues.apache.org/jira/browse/JEXL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17533929#comment-17533929 ] Hussachai Puripunpinyo commented on JEXL-367: - [~henrib] Awesome. Thanks so much. Glad that I asked for this named function :) > Named function and fat-arrow (=>) lambda syntax > --- > > Key: JEXL-367 > URL: https://issues.apache.org/jira/browse/JEXL-367 > Project: Commons JEXL > Issue Type: Wish >Affects Versions: 3.2.1 >Reporter: Hussachai Puripunpinyo >Assignee: Henri Biestro >Priority: Major > > The JEXL code surprisingly looks a lot like Javascript. I think this change > is a good transition for folks to update the code, and it's pretty fine if > they can tolerate using the deprecate syntax and don't mind seeing a warning > log pop up every time. > I'd like to propose supporting => and deprecate ->. > The reasons are > - JavaScript becomes very popular and many people are familiar with it. > - JEXL is more like for a quick short script. In many scenarios, the target > audiences are not a programer. They often mistake a language as a JavaScript > (from my experience). > - JEXL syntax already looks a lot like JavaScript > -- var for variable declaration (Java added in Java 10, but JavaScript > supports this from the beginning) > -- The function keyword > -- Implicit type coercion > -- Ternary operator > The proposed change. > * Support => in addition to -> > * Deprecate -> and show a warning log when it's used. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JEXL-367) Named function and fat-arrow (=>) lambda syntax
[ https://issues.apache.org/jira/browse/JEXL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17533901#comment-17533901 ] Henri Biestro commented on JEXL-367: Final steps, review [here|https://github.com/apache/commons-jexl/pull/96]. > Named function and fat-arrow (=>) lambda syntax > --- > > Key: JEXL-367 > URL: https://issues.apache.org/jira/browse/JEXL-367 > Project: Commons JEXL > Issue Type: Wish >Affects Versions: 3.2.1 >Reporter: Hussachai Puripunpinyo >Assignee: Henri Biestro >Priority: Major > > The JEXL code surprisingly looks a lot like Javascript. I think this change > is a good transition for folks to update the code, and it's pretty fine if > they can tolerate using the deprecate syntax and don't mind seeing a warning > log pop up every time. > I'd like to propose supporting => and deprecate ->. > The reasons are > - JavaScript becomes very popular and many people are familiar with it. > - JEXL is more like for a quick short script. In many scenarios, the target > audiences are not a programer. They often mistake a language as a JavaScript > (from my experience). > - JEXL syntax already looks a lot like JavaScript > -- var for variable declaration (Java added in Java 10, but JavaScript > supports this from the beginning) > -- The function keyword > -- Implicit type coercion > -- Ternary operator > The proposed change. > * Support => in addition to -> > * Deprecate -> and show a warning log when it's used. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [commons-jexl] henrib opened a new pull request, #96: JEXL-367
henrib opened a new pull request, #96: URL: https://github.com/apache/commons-jexl/pull/96 Ready for 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
[jira] [Commented] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17533833#comment-17533833
]
Steve Bosman commented on COLLECTIONS-770:
--
Created pull request - https://github.com/apache/commons-collections/pull/308
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, countHasNextCall.patch, stackdump.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
> stringMap.merge(userId, Collections.singleton(name),
> SetUtils::union);
> }
> }
> {code}
> I did some debugging and it occurs when the toString method of one the set is
> called. It looks like the issues is with the iterator of "SetUtils.SetView".
> Here just the method I used to create test sets and in the attachment you
> find the full tests class and a stack dump. The execution time is growing
> exponentially with the numbers of times the SetUtils.union is called. So for
> 29 elements it took 16 seconds to execute toString, and with 30 it took 32
> seconds.
> {code:java}
> @Test
> void setWith20Elements() {
> assertTimeout(ofSeconds(2), () -> createSet(30).toString());
> }
> Set createSet(int number) {
> List inputs = new ArrayList<>();
> for (int i = 0; i < number; i++) {
>inputs.add("Test"+ i);
> }
> Set testSet = Collections.singleton("String1");
> for (String element : inputs) {
> Set part = Collections.singleton(element);
> testSet = SetUtils.union(testSet,part);
> }
> return testSet;
> }
> {code}
> Thanks for your support
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (VFS-819) VFSClassLoader ClassNotFoundException JDK 17
[
https://issues.apache.org/jira/browse/VFS-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Miller closed VFS-819.
---
Resolution: Not A Bug
> VFSClassLoader ClassNotFoundException JDK 17
>
>
> Key: VFS-819
> URL: https://issues.apache.org/jira/browse/VFS-819
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
> Environment: OpenJDK 17 version "17.0.3" 2022-04-19
> Apache Maven 3.8.5
> Multiple Linux
>Reporter: Mike Miller
>Priority: Major
>
> We (Accumulo) are seeing the VFSClassLoader failing in JDK 17. We have very
> simple tests, that are all failing when trying to use it to load classes from
> the classpath.
> {noformat}
> [INFO] Running
> org.apache.accumulo.start.classloader.vfs.providers.VfsClassLoaderTest
> [ERROR] Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 26.367 s <<< FAILURE! - in
> org.apache.accumulo.start.classloader.vfs.providers.VfsClassLoaderTest
> [ERROR]
> org.apache.accumulo.start.classloader.vfs.providers.VfsClassLoaderTest.testGetClass
> Time elapsed: 0.02 s <<< ERROR!
> java.lang.ClassNotFoundException: test.HelloWorld
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:587)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
> at
> org.apache.accumulo.start.classloader.vfs.providers.VfsClassLoaderTest.testGetClass(VfsClassLoaderTest.java:66)
> {noformat}
> Here is an example:
> {code:java}
> this.cl = new VFSClassLoader(dirContents, vfs);
> @Test
> public void testGetClass() throws Exception {
> Class helloWorldClass = this.cl.loadClass("test.HelloWorld");
> Object o = helloWorldClass.getDeclaredConstructor().newInstance();
> assertEquals("Hello World!", o.toString());
> }{code}
> https://github.com/apache/accumulo/blob/main/start/src/test/java/org/apache/accumulo/start/classloader/vfs/providers/VfsClassLoaderTest.java
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Work logged] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?focusedWorklogId=767884=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-767884
]
ASF GitHub Bot logged work on COLLECTIONS-770:
--
Author: ASF GitHub Bot
Created on: 09/May/22 12:30
Start Date: 09/May/22 12:30
Worklog Time Spent: 10m
Work Description: codecov-commenter commented on PR #308:
URL:
https://github.com/apache/commons-collections/pull/308#issuecomment-1121037988
#
[Codecov](https://codecov.io/gh/apache/commons-collections/pull/308?src=pr=h1_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation)
Report
> Merging
[#308](https://codecov.io/gh/apache/commons-collections/pull/308?src=pr=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation)
(2257274) into
[master](https://codecov.io/gh/apache/commons-collections/commit/1677daceab74895fdf5056c9a48aa94f9e709fb9?el=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation)
(1677dac) will **increase** coverage by `0.01%`.
> The diff coverage is `100.00%`.
```diff
@@ Coverage Diff @@
## master #308 +/- ##
+ Coverage 85.87% 85.88% +0.01%
- Complexity 4676 4683 +7
Files 292 292
Lines 1346913482 +13
Branches 1955 1959 +4
+ Hits 1156611579 +13
Misses 1326 1326
Partials577 577
```
| [Impacted
Files](https://codecov.io/gh/apache/commons-collections/pull/308?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation)
| Coverage Δ | |
|---|---|---|
|
[.../commons/collections4/iterators/IteratorChain.java](https://codecov.io/gh/apache/commons-collections/pull/308/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvY29sbGVjdGlvbnM0L2l0ZXJhdG9ycy9JdGVyYXRvckNoYWluLmphdmE=)
| `88.88% <100.00%> (+2.61%)` | :arrow_up: |
|
[...s/collections4/iterators/UnmodifiableIterator.java](https://codecov.io/gh/apache/commons-collections/pull/308/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvY29sbGVjdGlvbnM0L2l0ZXJhdG9ycy9Vbm1vZGlmaWFibGVJdGVyYXRvci5qYXZh)
| `100.00% <100.00%> (ø)` | |
--
[Continue to review full report at
Codecov](https://codecov.io/gh/apache/commons-collections/pull/308?src=pr=continue_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation).
> **Legend** - [Click here to learn
more](https://docs.codecov.io/docs/codecov-delta?utm_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation)
> `Δ = absolute (impact)`, `ø = not affected`, `? = missing data`
> Powered by
[Codecov](https://codecov.io/gh/apache/commons-collections/pull/308?src=pr=footer_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation).
Last update
[1677dac...2257274](https://codecov.io/gh/apache/commons-collections/pull/308?src=pr=lastupdated_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation).
Read the [comment
docs](https://docs.codecov.io/docs/pull-request-comments?utm_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation).
Issue Time Tracking
---
Worklog Id: (was: 767884)
Time Spent: 20m (was: 10m)
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, countHasNextCall.patch, stackdump.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
>
[GitHub] [commons-collections] codecov-commenter commented on pull request #308: COLLECTIONS-770 When creating an iterator chain containing other iterator chains flatten the resulting internal object.
codecov-commenter commented on PR #308: URL: https://github.com/apache/commons-collections/pull/308#issuecomment-1121037988 # [Codecov](https://codecov.io/gh/apache/commons-collections/pull/308?src=pr=h1_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) Report > Merging [#308](https://codecov.io/gh/apache/commons-collections/pull/308?src=pr=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (2257274) into [master](https://codecov.io/gh/apache/commons-collections/commit/1677daceab74895fdf5056c9a48aa94f9e709fb9?el=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (1677dac) will **increase** coverage by `0.01%`. > The diff coverage is `100.00%`. ```diff @@ Coverage Diff @@ ## master #308 +/- ## + Coverage 85.87% 85.88% +0.01% - Complexity 4676 4683 +7 Files 292 292 Lines 1346913482 +13 Branches 1955 1959 +4 + Hits 1156611579 +13 Misses 1326 1326 Partials577 577 ``` | [Impacted Files](https://codecov.io/gh/apache/commons-collections/pull/308?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) | Coverage Δ | | |---|---|---| | [.../commons/collections4/iterators/IteratorChain.java](https://codecov.io/gh/apache/commons-collections/pull/308/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvY29sbGVjdGlvbnM0L2l0ZXJhdG9ycy9JdGVyYXRvckNoYWluLmphdmE=) | `88.88% <100.00%> (+2.61%)` | :arrow_up: | | [...s/collections4/iterators/UnmodifiableIterator.java](https://codecov.io/gh/apache/commons-collections/pull/308/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvY29sbGVjdGlvbnM0L2l0ZXJhdG9ycy9Vbm1vZGlmaWFibGVJdGVyYXRvci5qYXZh) | `100.00% <100.00%> (ø)` | | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/commons-collections/pull/308?src=pr=continue_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta?utm_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/commons-collections/pull/308?src=pr=footer_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation). Last update [1677dac...2257274](https://codecov.io/gh/apache/commons-collections/pull/308?src=pr=lastupdated_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments?utm_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?focusedWorklogId=767883=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-767883
]
ASF GitHub Bot logged work on COLLECTIONS-770:
--
Author: ASF GitHub Bot
Created on: 09/May/22 12:21
Start Date: 09/May/22 12:21
Worklog Time Spent: 10m
Work Description: stevebosman-oc opened a new pull request, #308:
URL: https://github.com/apache/commons-collections/pull/308
Contributed on behalf of the @opencastsoftware open source team
I am slightly wary of opening up UnmodifiableIterator, but this seems to
solve the performance degradation of nested IteratorChains seen in
COLLECTIONS-770
Issue Time Tracking
---
Worklog Id: (was: 767883)
Remaining Estimate: 0h
Time Spent: 10m
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, countHasNextCall.patch, stackdump.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
> stringMap.merge(userId, Collections.singleton(name),
> SetUtils::union);
> }
> }
> {code}
> I did some debugging and it occurs when the toString method of one the set is
> called. It looks like the issues is with the iterator of "SetUtils.SetView".
> Here just the method I used to create test sets and in the attachment you
> find the full tests class and a stack dump. The execution time is growing
> exponentially with the numbers of times the SetUtils.union is called. So for
> 29 elements it took 16 seconds to execute toString, and with 30 it took 32
> seconds.
> {code:java}
> @Test
> void setWith20Elements() {
> assertTimeout(ofSeconds(2), () -> createSet(30).toString());
> }
> Set createSet(int number) {
> List inputs = new ArrayList<>();
> for (int i = 0; i < number; i++) {
>inputs.add("Test"+ i);
> }
> Set testSet = Collections.singleton("String1");
> for (String element : inputs) {
> Set part = Collections.singleton(element);
> testSet = SetUtils.union(testSet,part);
> }
> return testSet;
> }
> {code}
> Thanks for your support
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [commons-collections] stevebosman-oc opened a new pull request, #308: COLLECTIONS-770 When creating an iterator chain containing other iterator chains flatten the resulting internal object.
stevebosman-oc opened a new pull request, #308: URL: https://github.com/apache/commons-collections/pull/308 Contributed on behalf of the @opencastsoftware open source team I am slightly wary of opening up UnmodifiableIterator, but this seems to solve the performance degradation of nested IteratorChains seen in COLLECTIONS-770 -- 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] [Closed] (IMAGING-161) Move package commons.itu_t4 to formats.tiff package
[ https://issues.apache.org/jira/browse/IMAGING-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita closed IMAGING-161. -- Assignee: (was: Benedikt Ritter) Resolution: Abandoned > Move package commons.itu_t4 to formats.tiff package > --- > > Key: IMAGING-161 > URL: https://issues.apache.org/jira/browse/IMAGING-161 > Project: Commons Imaging > Issue Type: Improvement > Components: Format: TIFF, imaging.common.* >Reporter: Benedikt Ritter >Priority: Major > Fix For: Review Patch > > > All public methods from the T4AndT6Compression class are only used in the > tiff package. We should move the code to the tiff package and make it package > private to remove it from the public API. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (IMAGING-233) Unable to parse most web icons (favicon.ico)
[ https://issues.apache.org/jira/browse/IMAGING-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita closed IMAGING-233. -- Fix Version/s: 1.0-alpha3 Resolution: Cannot Reproduce > Unable to parse most web icons (favicon.ico) > > > Key: IMAGING-233 > URL: https://issues.apache.org/jira/browse/IMAGING-233 > Project: Commons Imaging > Issue Type: Wish > Components: Format: ICO >Affects Versions: 1.0-alpha1 >Reporter: David Li >Priority: Major > Fix For: 1.0-alpha3 > > > I am unable to use 1.0-alpha1 to process a vast majority of icons on the web, > i.e. [https://www.google.com/favicon.ico]. Attempting to do so results in > `org.apache.commons.imaging.ImageReadException: Can't parse this format`. > > `file` identifies these icons as "MS Windows icon resource - 2 icons, 16x16, > 32 bits/pixel, 32x32, 32 bits/pixel" -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (IMAGING-252) Unit Tests Fail when running under Windows
[
https://issues.apache.org/jira/browse/IMAGING-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita resolved IMAGING-252.
Resolution: Fixed
Hi [~gwlucas] o/
Triaging the issues for alpha-3. This one appears to have been fixed some time
ago. We now test Windows with GitHub Actions -
https://github.com/apache/commons-imaging/blob/c33ef79cd2026b5b622102c8c7ebc9eebdd5b899/.github/workflows/maven.yml#L29
> Unit Tests Fail when running under Windows
> --
>
> Key: IMAGING-252
> URL: https://issues.apache.org/jira/browse/IMAGING-252
> Project: Commons Imaging
> Issue Type: Bug
> Components: Build, imaging.*
>Affects Versions: 1.0-alpha1
>Reporter: Gary Lucas
>Priority: Major
>
> When performing a maven verify under a Windows OS, the unit test for
> TestImageInfo.java fails. The problem is due to the fact that the toString()
> method used for the test data format (BMP, I think) returns a multi-line
> product. Under windows, the PrintWriter class that is used internally to
> format the string introduces carriage returns. But the "expected" string
> that the TestImageInfo class uses has line feeds but no carriage returns.
> So the assertEquals() test fails.
> By tradition, Windows text includes a carriage-return/line-feed at the end of
> each line of text while Linux text has just a line-feed. So if these unit
> tests are performed on Linux, they pass. Only Windows is an issue.
> Recommend including a line of code to remove the carriage-returns from the
> return String from the ImageInfo.toString() method call. Instead of:
> {quote}assertEquals(expected, imageInfo.toString());
> {quote}
> use:
>
> {quote}String test = imageInfo.toString().replaceAll("r", "");
> assertEquals(expected, test);
> {quote}
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IMAGING-252) Unit Tests Fail when running under Windows
[
https://issues.apache.org/jira/browse/IMAGING-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-252:
---
Assignee: Bruno P. Kinoshita
> Unit Tests Fail when running under Windows
> --
>
> Key: IMAGING-252
> URL: https://issues.apache.org/jira/browse/IMAGING-252
> Project: Commons Imaging
> Issue Type: Bug
> Components: Build, imaging.*
>Affects Versions: 1.0-alpha1
>Reporter: Gary Lucas
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 1.0-alpha3
>
>
> When performing a maven verify under a Windows OS, the unit test for
> TestImageInfo.java fails. The problem is due to the fact that the toString()
> method used for the test data format (BMP, I think) returns a multi-line
> product. Under windows, the PrintWriter class that is used internally to
> format the string introduces carriage returns. But the "expected" string
> that the TestImageInfo class uses has line feeds but no carriage returns.
> So the assertEquals() test fails.
> By tradition, Windows text includes a carriage-return/line-feed at the end of
> each line of text while Linux text has just a line-feed. So if these unit
> tests are performed on Linux, they pass. Only Windows is an issue.
> Recommend including a line of code to remove the carriage-returns from the
> return String from the ImageInfo.toString() method call. Instead of:
> {quote}assertEquals(expected, imageInfo.toString());
> {quote}
> use:
>
> {quote}String test = imageInfo.toString().replaceAll("r", "");
> assertEquals(expected, test);
> {quote}
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IMAGING-252) Unit Tests Fail when running under Windows
[
https://issues.apache.org/jira/browse/IMAGING-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-252:
---
Fix Version/s: 1.0-alpha3
> Unit Tests Fail when running under Windows
> --
>
> Key: IMAGING-252
> URL: https://issues.apache.org/jira/browse/IMAGING-252
> Project: Commons Imaging
> Issue Type: Bug
> Components: Build, imaging.*
>Affects Versions: 1.0-alpha1
>Reporter: Gary Lucas
>Priority: Major
> Fix For: 1.0-alpha3
>
>
> When performing a maven verify under a Windows OS, the unit test for
> TestImageInfo.java fails. The problem is due to the fact that the toString()
> method used for the test data format (BMP, I think) returns a multi-line
> product. Under windows, the PrintWriter class that is used internally to
> format the string introduces carriage returns. But the "expected" string
> that the TestImageInfo class uses has line feeds but no carriage returns.
> So the assertEquals() test fails.
> By tradition, Windows text includes a carriage-return/line-feed at the end of
> each line of text while Linux text has just a line-feed. So if these unit
> tests are performed on Linux, they pass. Only Windows is an issue.
> Recommend including a line of code to remove the carriage-returns from the
> return String from the ImageInfo.toString() method call. Instead of:
> {quote}assertEquals(expected, imageInfo.toString());
> {quote}
> use:
>
> {quote}String test = imageInfo.toString().replaceAll("r", "");
> assertEquals(expected, test);
> {quote}
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17533748#comment-17533748
]
Steve Bosman edited comment on COLLECTIONS-770 at 5/9/22 11:43 AM:
---
I can see there are two different forms of nesting here. The iterators end up
inside UnmodifiableIterators and also nested inside IteratorChains. It seems to
me the solution is to collapse the nesting when creating a new unioned
IteratorChain. I have had a quick try and it looks like the numbers in the test
case above can be vastly reduced. It does however rely on a modification to
UnmodifiableIterator to allow access to the IteratorChain.
e.g. given four iterators it1, it2, it3, and it4 inside two iterator chains ic1
(of it1 and it2), and ic2 (of it3 and it4) then when unioned create a chain
(it1, it2, it3, it4) instead of a chain (ic1, ic2)
There is similar logic for unmodifiableIterators, but more hoops to jump
through.
I hope the above explanation is okay, but if I can get this tested and working,
I will submit a PR which should make it more obvious.
was (Author: stevebosman):
I can see there are two different forms of nesting here. The iterators end up
inside UnmodifiableIterators and also nested inside IteratorChains. It seems to
me the solution is to collapse the nesting when creating a new unioned
IteratorChain. I have had a quick try and it looks like the numbers in the test
case above can be vastly reduced. It does however rely on a modification to
UnmodifiableIterator to allow access to the IteratorChain.
e.g. given four iterators it1, it2, it3, and it4 inside two iterator chains
ic1, and ic2 then when unioned create a chain (it1, it2, it3, it4) instead of a
chain (ic1, ic2)
There is similar logic for unmodifiableIterators, but more hoops to jump
through.
I hope the above explanation is okay, but if I can get this tested and working,
I will submit a PR which should make it more obvious.
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, countHasNextCall.patch, stackdump.txt
>
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
> stringMap.merge(userId, Collections.singleton(name),
> SetUtils::union);
> }
> }
> {code}
> I did some debugging and it occurs when the toString method of one the set is
> called. It looks like the issues is with the iterator of "SetUtils.SetView".
> Here just the method I used to create test sets and in the attachment you
> find the full tests class and a stack dump. The execution time is growing
> exponentially with the numbers of times the SetUtils.union is called. So for
> 29 elements it took 16 seconds to execute toString, and with 30 it took 32
> seconds.
> {code:java}
> @Test
> void setWith20Elements() {
> assertTimeout(ofSeconds(2), () -> createSet(30).toString());
> }
> Set createSet(int number) {
> List inputs = new ArrayList<>();
> for (int i = 0; i < number; i++) {
>inputs.add("Test"+ i);
> }
> Set testSet = Collections.singleton("String1");
> for (String element : inputs) {
> Set part = Collections.singleton(element);
> testSet = SetUtils.union(testSet,part);
> }
> return testSet;
> }
> {code}
> Thanks for your support
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (COLLECTIONS-770) ToString method is unresponsive after multiple SetUtils union calls
[
https://issues.apache.org/jira/browse/COLLECTIONS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17533748#comment-17533748
]
Steve Bosman commented on COLLECTIONS-770:
--
I can see there are two different forms of nesting here. The iterators end up
inside UnmodifiableIterators and also nested inside IteratorChains. It seems to
me the solution is to collapse the nesting when creating a new unioned
IteratorChain. I have had a quick try and it looks like the numbers in the test
case above can be vastly reduced. It does however rely on a modification to
UnmodifiableIterator to allow access to the IteratorChain.
e.g. given four iterators it1, it2, it3, and it4 inside two iterator chains
ic1, and ic2 then when unioned create a chain (it1, it2, it3, it4) instead of a
chain (ic1, ic2)
There is similar logic for unmodifiableIterators, but more hoops to jump
through.
I hope the above explanation is okay, but if I can get this tested and working,
I will submit a PR which should make it more obvious.
> ToString method is unresponsive after multiple SetUtils union calls
> ---
>
> Key: COLLECTIONS-770
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-770
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.4
>Reporter: Thomas Bürli
>Priority: Minor
> Attachments: SetUtilsTest.java, countHasNextCall.patch, stackdump.txt
>
>
> I had the following code and my application stopped responsing as soon the
> number of names for a userId got too big.
> {code:java}
>Map> stringMap = new TreeMap<>();
> for (String name : names) {
> for (String userId : userIds) {
> stringMap.merge(userId, Collections.singleton(name),
> SetUtils::union);
> }
> }
> {code}
> I did some debugging and it occurs when the toString method of one the set is
> called. It looks like the issues is with the iterator of "SetUtils.SetView".
> Here just the method I used to create test sets and in the attachment you
> find the full tests class and a stack dump. The execution time is growing
> exponentially with the numbers of times the SetUtils.union is called. So for
> 29 elements it took 16 seconds to execute toString, and with 30 it took 32
> seconds.
> {code:java}
> @Test
> void setWith20Elements() {
> assertTimeout(ofSeconds(2), () -> createSet(30).toString());
> }
> Set createSet(int number) {
> List inputs = new ArrayList<>();
> for (int i = 0; i < number; i++) {
>inputs.add("Test"+ i);
> }
> Set testSet = Collections.singleton("String1");
> for (String element : inputs) {
> Set part = Collections.singleton(element);
> testSet = SetUtils.union(testSet,part);
> }
> return testSet;
> }
> {code}
> Thanks for your support
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (JEXL-369) Add 'let' and 'const' variable declarations
[ https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17533719#comment-17533719 ] Henri Biestro edited comment on JEXL-369 at 5/9/22 9:18 AM: [~dmitri_blinov], Thanks for your valuable input and insight :) Commit [72490fa5|https://github.com/apache/commons-jexl/commit/72490fa5c841720c70f26186f6e874f9d2ae4379] was (Author: henrib): [~dmitri_blinov], Thanks for your valuable input and insight :) Commit [72490fa5https://github.com/apache/commons-jexl/commit/72490fa5c841720c70f26186f6e874f9d2ae4379] > Add 'let' and 'const' variable declarations > --- > > Key: JEXL-369 > URL: https://issues.apache.org/jira/browse/JEXL-369 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > Add creation of lexical scope variables, modifiable with 'let', > non-modifiable through 'const'. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (JEXL-369) Add 'let' and 'const' variable declarations
[ https://issues.apache.org/jira/browse/JEXL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-369. Resolution: Fixed [~dmitri_blinov], Thanks for your valuable input and insight :) Commit [72490fa5https://github.com/apache/commons-jexl/commit/72490fa5c841720c70f26186f6e874f9d2ae4379] > Add 'let' and 'const' variable declarations > --- > > Key: JEXL-369 > URL: https://issues.apache.org/jira/browse/JEXL-369 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > Add creation of lexical scope variables, modifiable with 'let', > non-modifiable through 'const'. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [commons-jexl] henrib merged pull request #95: JEXL-369
henrib merged PR #95: URL: https://github.com/apache/commons-jexl/pull/95 -- 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] (IMAGING-310) JpegImageParser: Grayscale JPEG file with app14Segment returns ColorType.UNKNOWN
[
https://issues.apache.org/jira/browse/IMAGING-310?focusedWorklogId=767817=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-767817
]
ASF GitHub Bot logged work on IMAGING-310:
--
Author: ASF GitHub Bot
Created on: 09/May/22 07:44
Start Date: 09/May/22 07:44
Worklog Time Spent: 10m
Work Description: kinow commented on code in PR #163:
URL: https://github.com/apache/commons-imaging/pull/163#discussion_r867723828
##
src/main/java/org/apache/commons/imaging/formats/jpeg/JpegImageParser.java:
##
@@ -824,44 +824,44 @@ public ImageInfo getImageInfo(final ByteSource
byteSource, final Maphttp://docs.oracle.com/javase/6/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color
ImageInfo.ColorType colorType = ImageInfo.ColorType.UNKNOWN;
-// Some images have both JFIF/APP0 and APP14.
-// JFIF is meant to win but in them APP14 is clearly right, so make it
win.
-if (app14Segment != null && app14Segment.isAdobeJpegSegment()) {
-final int colorTransform = app14Segment.getAdobeColorTransform();
-switch (colorTransform) {
-case App14Segment.ADOBE_COLOR_TRANSFORM_UNKNOWN:
-if (numberOfComponents == 3) {
-colorType = ImageInfo.ColorType.RGB;
-} else if (numberOfComponents == 4) {
-colorType = ImageInfo.ColorType.CMYK;
+switch (numberOfComponents) {
+case 1:
+colorType = ImageInfo.ColorType.GRAYSCALE;
+break;
+case 2:
+colorType = ImageInfo.ColorType.GRAYSCALE;
+transparent = true;
+break;
+case 3:
+case 4:
+// Some images have both JFIF/APP0 and APP14.
+// JFIF is meant to win but in them APP14 is clearly right, so
make it win.
+if (app14Segment != null && app14Segment.isAdobeJpegSegment()) {
+final int colorTransform =
app14Segment.getAdobeColorTransform();
+switch (colorTransform) {
+case App14Segment.ADOBE_COLOR_TRANSFORM_UNKNOWN:
+if (numberOfComponents == 3) {
+colorType = ImageInfo.ColorType.RGB;
+} else if (numberOfComponents == 4) {
+colorType = ImageInfo.ColorType.CMYK;
+}
+break;
+case App14Segment.ADOBE_COLOR_TRANSFORM_YCbCr:
+colorType = ImageInfo.ColorType.YCbCr;
+break;
+case App14Segment.ADOBE_COLOR_TRANSFORM_YCCK:
+colorType = ImageInfo.ColorType.YCCK;
+break;
+default:
+break;
}
-break;
-case App14Segment.ADOBE_COLOR_TRANSFORM_YCbCr:
-colorType = ImageInfo.ColorType.YCbCr;
-break;
-case App14Segment.ADOBE_COLOR_TRANSFORM_YCCK:
-colorType = ImageInfo.ColorType.YCCK;
-break;
-default:
-break;
-}
-} else if (jfifSegment != null) {
-if (numberOfComponents == 1) {
-colorType = ImageInfo.ColorType.GRAYSCALE;
-} else if (numberOfComponents == 3) {
-colorType = ImageInfo.ColorType.YCbCr;
-}
-} else {
-switch (numberOfComponents) {
-case 1:
-colorType = ImageInfo.ColorType.GRAYSCALE;
-break;
-case 2:
-colorType = ImageInfo.ColorType.GRAYSCALE;
-transparent = true;
-break;
-case 3:
-case 4:
+} else if (jfifSegment != null) {
+if (numberOfComponents == 1) {
Review Comment:
Ping 2. Release going out soon :steam_locomotive:
Issue Time Tracking
---
Worklog Id: (was: 767817)
Time Spent: 2h (was: 1h 50m)
> JpegImageParser: Grayscale JPEG file with app14Segment returns
> ColorType.UNKNOWN
>
>
> Key: IMAGING-310
> URL: https://issues.apache.org/jira/browse/IMAGING-310
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 1.0-alpha2
>Reporter: John Phillips
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Fix For: 1.0-alpha3
>
> Attachments: sample-grayscale-with-app14segment.jpg
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> In org.apache.commons.imaging.formats.jpeg. the logic to determine colorType
> (lines 825-970) does not account for a Grayscale image when there is an app14
>
[GitHub] [commons-imaging] kinow commented on a diff in pull request #163: IMAGING-310 JpegImageParser.getImageInfo() Refactor colorType logic to first look at numberOfComponents
kinow commented on code in PR #163:
URL: https://github.com/apache/commons-imaging/pull/163#discussion_r867723828
##
src/main/java/org/apache/commons/imaging/formats/jpeg/JpegImageParser.java:
##
@@ -824,44 +824,44 @@ public ImageInfo getImageInfo(final ByteSource
byteSource, final Maphttp://docs.oracle.com/javase/6/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color
ImageInfo.ColorType colorType = ImageInfo.ColorType.UNKNOWN;
-// Some images have both JFIF/APP0 and APP14.
-// JFIF is meant to win but in them APP14 is clearly right, so make it
win.
-if (app14Segment != null && app14Segment.isAdobeJpegSegment()) {
-final int colorTransform = app14Segment.getAdobeColorTransform();
-switch (colorTransform) {
-case App14Segment.ADOBE_COLOR_TRANSFORM_UNKNOWN:
-if (numberOfComponents == 3) {
-colorType = ImageInfo.ColorType.RGB;
-} else if (numberOfComponents == 4) {
-colorType = ImageInfo.ColorType.CMYK;
+switch (numberOfComponents) {
+case 1:
+colorType = ImageInfo.ColorType.GRAYSCALE;
+break;
+case 2:
+colorType = ImageInfo.ColorType.GRAYSCALE;
+transparent = true;
+break;
+case 3:
+case 4:
+// Some images have both JFIF/APP0 and APP14.
+// JFIF is meant to win but in them APP14 is clearly right, so
make it win.
+if (app14Segment != null && app14Segment.isAdobeJpegSegment()) {
+final int colorTransform =
app14Segment.getAdobeColorTransform();
+switch (colorTransform) {
+case App14Segment.ADOBE_COLOR_TRANSFORM_UNKNOWN:
+if (numberOfComponents == 3) {
+colorType = ImageInfo.ColorType.RGB;
+} else if (numberOfComponents == 4) {
+colorType = ImageInfo.ColorType.CMYK;
+}
+break;
+case App14Segment.ADOBE_COLOR_TRANSFORM_YCbCr:
+colorType = ImageInfo.ColorType.YCbCr;
+break;
+case App14Segment.ADOBE_COLOR_TRANSFORM_YCCK:
+colorType = ImageInfo.ColorType.YCCK;
+break;
+default:
+break;
}
-break;
-case App14Segment.ADOBE_COLOR_TRANSFORM_YCbCr:
-colorType = ImageInfo.ColorType.YCbCr;
-break;
-case App14Segment.ADOBE_COLOR_TRANSFORM_YCCK:
-colorType = ImageInfo.ColorType.YCCK;
-break;
-default:
-break;
-}
-} else if (jfifSegment != null) {
-if (numberOfComponents == 1) {
-colorType = ImageInfo.ColorType.GRAYSCALE;
-} else if (numberOfComponents == 3) {
-colorType = ImageInfo.ColorType.YCbCr;
-}
-} else {
-switch (numberOfComponents) {
-case 1:
-colorType = ImageInfo.ColorType.GRAYSCALE;
-break;
-case 2:
-colorType = ImageInfo.ColorType.GRAYSCALE;
-transparent = true;
-break;
-case 3:
-case 4:
+} else if (jfifSegment != null) {
+if (numberOfComponents == 1) {
Review Comment:
Ping 2. Release going out soon :steam_locomotive:
--
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-imaging] kinow commented on a diff in pull request #36: Avoid jpeg parse fail due to jfxx and exif
kinow commented on code in PR #36:
URL: https://github.com/apache/commons-imaging/pull/36#discussion_r867723683
##
src/main/java/org/apache/commons/imaging/formats/jpeg/JpegImageParser.java:
##
@@ -312,7 +312,12 @@ private void dumpSegments(final List v)
{
@Override
public ImageMetadata getMetadata(final ByteSource byteSource, final
Map params)
throws ImageReadException, IOException {
-final TiffImageMetadata exif = getExifMetadata(byteSource, params);
+TiffImageMetadata exif = null;
+try {
+exif = getExifMetadata(byteSource, params);
+} catch (Exception e) {
+// exif parse failed.
+}
Review Comment:
Ping
--
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-imaging] kinow merged pull request #215: Bump commons-parent from 52 to 53
kinow merged PR #215: URL: https://github.com/apache/commons-imaging/pull/215 -- 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
