[GitHub] [commons-jexl] dmitri-blinov closed pull request #7: Inline property assignment construct
dmitri-blinov closed pull request #7: URL: https://github.com/apache/commons-jexl/pull/7 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-jexl] dmitri-blinov closed pull request #11: lambda syntax enhancements
dmitri-blinov closed pull request #11: URL: https://github.com/apache/commons-jexl/pull/11 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] dependabot[bot] opened a new pull request #188: Bump slf4j-simple from 1.7.26 to 1.7.31
dependabot[bot] opened a new pull request #188: URL: https://github.com/apache/commons-vfs/pull/188 Bumps [slf4j-simple](https://github.com/qos-ch/slf4j) from 1.7.26 to 1.7.31. Commits See full diff in https://github.com/qos-ch/slf4j/commits;>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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-email] dependabot[bot] closed pull request #24: Bump slf4j-jdk14 from 1.7.7 to 1.7.30
dependabot[bot] closed pull request #24: URL: https://github.com/apache/commons-email/pull/24 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COLLECTIONS-795) provide a PairIterator to zip two iterators of different types.
[
https://issues.apache.org/jira/browse/COLLECTIONS-795?focusedWorklogId=612068=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-612068
]
ASF GitHub Bot logged work on COLLECTIONS-795:
--
Author: ASF GitHub Bot
Created on: 18/Jun/21 21:16
Start Date: 18/Jun/21 21:16
Worklog Time Spent: 10m
Work Description: anantdamle commented on pull request #238:
URL:
https://github.com/apache/commons-collections/pull/238#issuecomment-863754751
Gentle Bump: Any review comments or improvements
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 612068)
Time Spent: 6.5h (was: 6h 20m)
> provide a PairIterator to zip two iterators of different types.
> ---
>
> Key: COLLECTIONS-795
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-795
> Project: Commons Collections
> Issue Type: New Feature
> Components: Iterator
>Reporter: Anant Damle
>Priority: Minor
> Time Spent: 6.5h
> Remaining Estimate: 0h
>
> ZippingIterator provides a way to simulatenously iterate over multiple
> iterators of the *same-type.*
> The proposed pair iterator allows simultaneously iterating over two iterators
> of different type, like the example below:
> {code:java}
> Iterator leftIterator = ...;
> Iterator rightIterator = ...;
> PairIterator pairIterator = PairIterator.of(leftIterator, rightIterator);
> while (pairIterator.hasNext()) {
>ImmutablePair item = pairIterator.next();
>...
> }{code}
>
> Another convenience could be to use an Iterable for easy for-each constructs.
> {code:java}
> List studentIds = ...
> List studentNames = ...
> for (PairedItem items :
> IterableUtils.pairedIterable(studentIds, studentNames) {
> Integer studentId = item.getLeft();
> String studentName = item.getRight();
> ...
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-collections] anantdamle commented on pull request #238: [COLLECTIONS-795] Add a new Iterator to allowing zipping over two iterators of different types
anantdamle commented on pull request #238: URL: https://github.com/apache/commons-collections/pull/238#issuecomment-863754751 Gentle Bump: Any review comments or improvements -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-email] dependabot[bot] commented on pull request #24: Bump slf4j-jdk14 from 1.7.7 to 1.7.30
dependabot[bot] commented on pull request #24: URL: https://github.com/apache/commons-email/pull/24#issuecomment-864247765 Superseded by #50. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] dependabot[bot] commented on pull request #104: Bump slf4j-log4j12 from 1.5.11 to 1.7.30
dependabot[bot] commented on pull request #104: URL: https://github.com/apache/commons-vfs/pull/104#issuecomment-863955153 Superseded by #189. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-jexl] dmitri-blinov closed pull request #13: Introduce short-handed ternary operation x ? y
dmitri-blinov closed pull request #13: URL: https://github.com/apache/commons-jexl/pull/13 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-collections] garydgregory commented on pull request #242: feat(MapUtils): Add empty string judgment
garydgregory commented on pull request #242: URL: https://github.com/apache/commons-collections/pull/242#issuecomment-863961286 -1 I agree with @kinow. This would also create a bad precedent where empty strings are treated differently in a single method and also likely to break existing applications. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-jexl] dmitri-blinov closed pull request #12: Introduced indexed 'for' statement like in for(var key, entry : map)
dmitri-blinov closed pull request #12: URL: https://github.com/apache/commons-jexl/pull/12 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COLLECTIONS-795) provide a PairIterator to zip two iterators of different types.
[
https://issues.apache.org/jira/browse/COLLECTIONS-795?focusedWorklogId=611991=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-611991
]
ASF GitHub Bot logged work on COLLECTIONS-795:
--
Author: ASF GitHub Bot
Created on: 18/Jun/21 21:06
Start Date: 18/Jun/21 21:06
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #238:
URL:
https://github.com/apache/commons-collections/pull/238#issuecomment-863962396
No bumping needed. We are all volunteers. We are all busy. Please be
patient.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 611991)
Time Spent: 6h 20m (was: 6h 10m)
> provide a PairIterator to zip two iterators of different types.
> ---
>
> Key: COLLECTIONS-795
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-795
> Project: Commons Collections
> Issue Type: New Feature
> Components: Iterator
>Reporter: Anant Damle
>Priority: Minor
> Time Spent: 6h 20m
> Remaining Estimate: 0h
>
> ZippingIterator provides a way to simulatenously iterate over multiple
> iterators of the *same-type.*
> The proposed pair iterator allows simultaneously iterating over two iterators
> of different type, like the example below:
> {code:java}
> Iterator leftIterator = ...;
> Iterator rightIterator = ...;
> PairIterator pairIterator = PairIterator.of(leftIterator, rightIterator);
> while (pairIterator.hasNext()) {
>ImmutablePair item = pairIterator.next();
>...
> }{code}
>
> Another convenience could be to use an Iterable for easy for-each constructs.
> {code:java}
> List studentIds = ...
> List studentNames = ...
> for (PairedItem items :
> IterableUtils.pairedIterable(studentIds, studentNames) {
> Integer studentId = item.getLeft();
> String studentName = item.getRight();
> ...
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-collections] garydgregory commented on pull request #238: [COLLECTIONS-795] Add a new Iterator to allowing zipping over two iterators of different types
garydgregory commented on pull request #238: URL: https://github.com/apache/commons-collections/pull/238#issuecomment-863962396 No bumping needed. We are all volunteers. We are all busy. Please be patient. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-collections] kingmao666 opened a new pull request #242: feat(MapUtils): Add empty string judgment
kingmao666 opened a new pull request #242: URL: https://github.com/apache/commons-collections/pull/242 Add empty string judgment -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-ognl] dependabot[bot] opened a new pull request #39: Bump slf4j-api from 1.7.30 to 1.7.31
dependabot[bot] opened a new pull request #39: URL: https://github.com/apache/commons-ognl/pull/39 Bumps [slf4j-api](https://github.com/qos-ch/slf4j) from 1.7.30 to 1.7.31. Commits See full diff in https://github.com/qos-ch/slf4j/commits;>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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] dependabot[bot] closed pull request #104: Bump slf4j-log4j12 from 1.5.11 to 1.7.30
dependabot[bot] closed pull request #104: URL: https://github.com/apache/commons-vfs/pull/104 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-email] dependabot[bot] opened a new pull request #50: Bump slf4j-jdk14 from 1.7.7 to 1.7.31
dependabot[bot] opened a new pull request #50: URL: https://github.com/apache/commons-email/pull/50 Bumps [slf4j-jdk14](https://github.com/qos-ch/slf4j) from 1.7.7 to 1.7.31. Commits See full diff in https://github.com/qos-ch/slf4j/commits;>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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (POOL-396) Exceptions in validation can cause an object's lifecycle to be stuck in EVICTION state
[
https://issues.apache.org/jira/browse/POOL-396?focusedWorklogId=611915=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-611915
]
ASF GitHub Bot logged work on POOL-396:
---
Author: ASF GitHub Bot
Created on: 18/Jun/21 20:56
Start Date: 18/Jun/21 20:56
Worklog Time Spent: 10m
Work Description: coveralls edited a comment on pull request #85:
URL: https://github.com/apache/commons-pool/pull/85#issuecomment-860714291
[](https://coveralls.io/builds/40709686)
Coverage increased (+0.1%) to 84.146% when pulling
**34db391001f8cbbf07e918e11a75f2283b1144ba on jeremyk-91:POOL-396-validation**
into **e405182e6eaabc7422dfd6f65511b7883443b1e9 on apache:master**.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 611915)
Time Spent: 0.5h (was: 20m)
> Exceptions in validation can cause an object's lifecycle to be stuck in
> EVICTION state
> --
>
> Key: POOL-396
> URL: https://issues.apache.org/jira/browse/POOL-396
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.4.2, 2.9.0
>Reporter: Jeremy Kong
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, if validation of an object throws an exception when testing an
> idle object during eviction, an exception will be thrown from the evict()
> method. This causes the object to be left in the EVICTION state, but still be
> present in the idleObjects queue.
> Future runs of the eviction thread will run into an infinite loop, because
> they pick up the afflicted object from the queue, fail to set its state to
> EVICTION, don't count it as a test, and repeat ad infinitum. This infinite
> loop means that no further evictions will take place; it also causes
> increases in garbage collection owing to allocation of the EvictionIterator
> on each loop iteration.
> This test added to TestGenericObjectPool (plus a small change allowing
> exceptions to be thrown from the validateObject method of SimpleFactory)
> reproduces the issue.
> {code:java}
> @Test
> @Timeout(value = 6, unit = TimeUnit.MILLISECONDS)
> public void testExceptionInValidationDuringEviction() throws Exception {
> genericObjectPool.setMaxIdle(1);
> genericObjectPool.setMaxTotal(2);
> genericObjectPool.setNumTestsPerEvictionRun(1);
> genericObjectPool.setMinEvictableIdleTime(Duration.ofMillis(0));
> genericObjectPool.setTestWhileIdle(true);
> String active = genericObjectPool.borrowObject();
> genericObjectPool.returnObject(active);
> simpleFactory.setThrowExceptionOnValidate(true);
> try {
> genericObjectPool.evict();
> } catch (Exception e) {
> // OK that a given run fails. But the object should still be evicted.
> }
> genericObjectPool.evict(); // currently fails: causes an infinite loop!
> assertEquals(0, genericObjectPool.getNumActive());
> assertEquals(0, genericObjectPool.getNumIdle());
> }
> {code}
> It seems that protection against exceptions thrown by validation code exist
> elsewhere (e.g. in borrowObject()); similarly, protections against exceptions
> thrown by user eviction policy code exist in evict(). So it looks like the
> testWhileIdle() portion of evict() needs to similarly be protected.
> Thanks!
> Jeremy
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-pool] coveralls edited a comment on pull request #85: POOL-396: Handle validation exceptions during eviction.
coveralls edited a comment on pull request #85: URL: https://github.com/apache/commons-pool/pull/85#issuecomment-860714291 [](https://coveralls.io/builds/40709686) Coverage increased (+0.1%) to 84.146% when pulling **34db391001f8cbbf07e918e11a75f2283b1144ba on jeremyk-91:POOL-396-validation** into **e405182e6eaabc7422dfd6f65511b7883443b1e9 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] dependabot[bot] closed pull request #134: Bump slf4j-simple from 1.7.26 to 1.7.30
dependabot[bot] closed pull request #134: URL: https://github.com/apache/commons-vfs/pull/134 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] dependabot[bot] commented on pull request #134: Bump slf4j-simple from 1.7.26 to 1.7.30
dependabot[bot] commented on pull request #134: URL: https://github.com/apache/commons-vfs/pull/134#issuecomment-863954676 Superseded by #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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-numbers] coveralls edited a comment on pull request #96: Replace Summation and LinearCombination with Sum
coveralls edited a comment on pull request #96: URL: https://github.com/apache/commons-numbers/pull/96#issuecomment-862557471 [](https://coveralls.io/builds/40689715) Coverage decreased (-0.4%) to 99.245% when pulling **a69b10f4134bc6ce9674b4032a6bfaa2292c1c03 on darkma773r:sum** into **65ebfaa427f8f8d6b99c5f3acde482757763cb23 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] dependabot[bot] opened a new pull request #189: Bump slf4j-log4j12 from 1.5.11 to 1.7.31
dependabot[bot] opened a new pull request #189: URL: https://github.com/apache/commons-vfs/pull/189 Bumps [slf4j-log4j12](https://github.com/qos-ch/slf4j) from 1.5.11 to 1.7.31. Commits See full diff in https://github.com/qos-ch/slf4j/commits;>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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (JEXL-233) Documentation rewrite
[ https://issues.apache.org/jira/browse/JEXL-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitri Blinov closed JEXL-233. -- Resolution: Fixed > Documentation rewrite > - > > Key: JEXL-233 > URL: https://issues.apache.org/jira/browse/JEXL-233 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Dmitri Blinov >Priority: Minor > Attachments: syntax.xml > > > I have reorganized the JEXL syntax doc, basically adjusted the document > structure to be more logical in my view, and brushed up some descriptions. > Comments are welcome! If it is ok, please promote the attachment to the > source tree. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JEXL-316) Operator ?? has very low priority
[
https://issues.apache.org/jira/browse/JEXL-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov closed JEXL-316.
--
Fix Version/s: (was: Later)
Resolution: Won't Do
> Operator ?? has very low priority
> -
>
> Key: JEXL-316
> URL: https://issues.apache.org/jira/browse/JEXL-316
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
>
> In current version of JEXL the script
> {code:java}
> 10??0 + 200 {code}
> evaluates to 10, which is counterintuitive. It requires to always use
> parantheses after {{\\??}}. The operator {{??}} should have higer priority.
> It is the same problem as with current version of freemarker, but they
> promise to fix it in the next major release.
> The suggestion is to set priority of operator {{??}} to be between
> {{UnaryExpression()}} and {{ValueExpression()}}
> {code}
> void ConditionalExpression() #void : {}
> {
> ConditionalOrExpression()
> (
> Expression() Expression() #TernaryNode(3)
> |
> Expression() #TernaryNode(2)
> )?
> }
> ...
> void UnaryExpression() #void : {}
> {
> UnaryExpression() #UnaryMinusNode(1)
> |
> UnaryExpression() #UnaryPlusNode(1)
> |
> UnaryExpression() #BitwiseComplNode(1)
> |
> (|) UnaryExpression() #NotNode(1)
> |
> UnaryExpression() #EmptyFunction(1)
> |
> UnaryExpression() #SizeFunction(1)
> |
> NullpExpression()
> }
> void NullpExpression() #void : {}
> {
> ValueExpression()
> (
> ValueExpression() #NullpNode(2)
> )*
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (JEXL-185) Ability to trace execution of script statements
[ https://issues.apache.org/jira/browse/JEXL-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitri Blinov closed JEXL-185. -- Resolution: Won't Do > Ability to trace execution of script statements > --- > > Key: JEXL-185 > URL: https://issues.apache.org/jira/browse/JEXL-185 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: 3.0 >Reporter: Dmitri Blinov >Priority: Minor > > Since the rising complexity of the JEXL scripts makes it easier to write > sophisticated scripts, and harder to debug overall script evaluation, it > would be helpful to provide some way to trace individual statements execution > within the script by a callback interface. > Callback could be applied to JEXL engine as a whole, or to > Script.executeScript method as an additional parameter for example. > Callback interface should contain a method which should be invoked by JEXL on > completion of individual statement. Method parameters should contain such > values as DebugInfo (start..end statement position within the script), > statement execution result or exception (which in silent mode may be > swallowed), initial context, and possibly a stack frame to be able to peep > into local variables. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JEXL-266) Allow to remove an element from iterator collection within for-loops
[
https://issues.apache.org/jira/browse/JEXL-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov closed JEXL-266.
--
Resolution: Won't Do
> Allow to remove an element from iterator collection within for-loops
>
>
> Key: JEXL-266
> URL: https://issues.apache.org/jira/browse/JEXL-266
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
> Environment: I have created a patch as initial implementation for
> this new feature, please see github pull request here
> [pr#5|https://github.com/apache/commons-jexl/pull/5]. I whould be very
> grateful if this could be interesting for the community and included in
> master branch. Thanks in advance!
>Reporter: Dmitri Blinov
>Priority: Minor
>
> The for-loop in JEXL provides a convenient way to iterate over different
> types of collections, however, its not possible for a script writer to
> utilize underlying
> {code:java}
> iterator.remove(){code}
> method within such a loop. The proposal is to introduce new {{remove}}
> statement which should be used within for-loops and should internally call
> {{iterator.remove()}} method and skip the loop to the next element;
> For example, the following code should remove items {{1,2,3}} from set and
> return value {{3}}.
> {code:java}
> var set = {1,2,3,4,5,6}; for (var item : set) if (item <= 3) remove; return
> size(set)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (JEXL-268) Jexl lambdas as parameters to new Java8 methods
[
https://issues.apache.org/jira/browse/JEXL-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov closed JEXL-268.
--
Resolution: Won't Do
> Jexl lambdas as parameters to new Java8 methods
> ---
>
> Key: JEXL-268
> URL: https://issues.apache.org/jira/browse/JEXL-268
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
> Fix For: Later
>
>
> Java8 introduced functional interfaces, among them {{Function}} and
> {{BiFunction}} interfaces which are used as parameters to method calls, for
> example, {{Map.computeIfAbsent()}} or {{Map.computeIfPresent()}}. In Jexl we
> have lambdas which in theory are good candidates to construct a {{Function}}
> for lambda with one parameter, and a {{BiFunction}} for lambda with two
> parameters.
> The problem is Jexl can not currently support Java8 features and all
> instances of lambda are of single {{internal.Closure}} class, which should
> not try to implement both interfaces at once. One of the solutions, IMO, is
> to have a feature to overload lamda creations to construct custom lambda
> classes without shaking Jexl code tree.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (JEXL-276) Introduce short-handed ternary operation x ? y
[
https://issues.apache.org/jira/browse/JEXL-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov closed JEXL-276.
--
Resolution: Won't Do
> Introduce short-handed ternary operation x ? y
> --
>
> Key: JEXL-276
> URL: https://issues.apache.org/jira/browse/JEXL-276
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> A short-handed ternary operation {{x ? y}} is an equivalent of the {{x ? y :
> null}}. The {{x : y}} operator is analogous to {{if (x) y}} statement with
> {{else}} part omitted. With new syntax we will have ternary operator and
> {{if}} statement to have full symmetry of forms, e.g.
> {{x ? y : x}} is {{if (x) y else z}}, {{x ? y}} is {{if (x) y}}
> Just to note, the proposed short-handed differs from Elvis operator {{x ?:
> y}} which is effectively {{x ? x : y}}. In other words, elvis operator allows
> for the middle part of the ternary operator to be omitted, whereas the
> proposed form allows for the imission of the last part.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (JEXL-269) Indexed for-loop
[
https://issues.apache.org/jira/browse/JEXL-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov closed JEXL-269.
--
Resolution: Won't Do
> Indexed for-loop
>
>
> Key: JEXL-269
> URL: https://issues.apache.org/jira/browse/JEXL-269
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
> Environment: I have created a PR for this feature, please see
> [PR#12|https://github.com/apache/commons-jexl/pull/12]
>Reporter: Dmitri Blinov
>Priority: Minor
>
> Introduce new extended syntax of 'for' statement, which allows to specify two
> variables, like the following
> {code:java}
> for (var i, item : list){code}
> Inside the loop, the first variable gets current iteration counter, starting
> from 0, and the second variable gets current iterated value. The special
> consideration is taken for iteration over map entries, like the following
> {code:java}
> for(var key, entry : map){code}
> , in this case the first variable is the map key, and the second is the
> corresponding map value
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365439#comment-17365439
]
Gilles Sadowski edited comment on NUMBERS-163 at 6/18/21, 11:00 AM:
{quote}name is also incorrect
{quote}
Class was just named so because it computes [the exact product of the first two
arguments summed with the third
argument|https://docs.oracle.com/javase/9/docs/api/java/lang/Math.html#fma-double-double-double-]
Alex mentioned that the requirements for {{Math.fma}} (the "true" one) are
different; no problem: Class can be called {{LinearCombination}} or {{Dot}} or
{{SumOfProducts}}.
What I'm discussing is whether
* immutability (cf.
[ValJO|https://blog.joda.org/2014/03/valjos-value-java-objects.html] which
almost everything in [Numbers] is based on)
* accumulation
can be provided together (without too much loss of performance).
bq. performance implications
I certainly did not get similar results; we likely are testing different
use-cases...
Such a big discrepancy would warrant a separation of the above two properties.
IMO a *mutable* class in the public API is a serious problem. I recall that a
long, long, time ago, we switched to an immutable {{Vector3D}} on the ground
that it was _not_ less performant.
bq. source algorithms
IMHO it is confusing to use both a generic name ("Sum") and assume specific
implementations' requirements.
Shall we define an interface:
{code}
public interface SumOfProducts
extends DoubleSupplier,
BinaryOperator {
SumOfProducts add(double m1, double m2);
SumOfProducts add(SumOfProducts other);
@Override
default SumOfProducts apply(SumOfProducts a, SumOfProducts b) {
return a.add(b);
}
// ...
}
{code}
?
Also: What about following Alex's suggestion of an "enum", in order to provide
a choice of implementations (with specific accuracy and performance
expectations, as per its reference description)?
was (Author: erans):
{quote}name is also incorrect
{quote}
Class was just named so because it computes [the exact product of the first two
arguments summed with the third
argument|https://docs.oracle.com/javase/9/docs/api/java/lang/Math.html#fma-double-double-double-]
Alex mentioned that the requirements for {{Math.fma}} (the "true" one) are
different; no problem: Class can be called {{LinearCombination}} or {{Dot}} or
{{SumOfProducts}}.
What I'm discussing is whether
* immutability (cf.
[ValJO|https://blog.joda.org/2014/03/valjos-value-java-objects.html] which
almost everything in [Numbers] is based on)
* accumulation
can be provided together (without too much loss of performance).
bq. performance implications
I certainly did not get similar results; we likely are testing different
use-cases...
Such a big discrepancy would warrant a separation of the above two properties.
IMO a *mutable* class in the public API is a serious problem. I recall that a
long, long, time ago, we switched to an immutable {{Vector3D}} on the ground
that it was _not_ less performant.
bq. source algorithms
IMHO it is confusing to use both a generic name ("Sum") and assume specific
implementations' requirements.
Shall we define an interface:
{code}
public interface SumOfProducts implements DoubleSupplier,
BinaryOperator {
SumOfProducts add(double m1, double m2);
SumOfProducts add(SumOfProducts other);
@Override
default SumOfProducts apply(SumOfProducts a, SumOfProducts b) {
return a.add(b);
}
// ...
}
{code}
?
Also: What about following Alex's suggestion of an "enum", in order to provide
a choice of implementations (with specific accuracy and performance
expectations, as per its reference description)?
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Attachments: FMA.java, Sum.java
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365439#comment-17365439
]
Gilles Sadowski commented on NUMBERS-163:
-
{quote}name is also incorrect
{quote}
Class was just named so because it computes [the exact product of the first two
arguments summed with the third
argument|https://docs.oracle.com/javase/9/docs/api/java/lang/Math.html#fma-double-double-double-]
Alex mentioned that the requirements for {{Math.fma}} (the "true" one) are
different; no problem: Class can be called {{LinearCombination}} or {{Dot}} or
{{SumOfProducts}}.
What I'm discussing is whether
* immutability (cf.
[ValJO|https://blog.joda.org/2014/03/valjos-value-java-objects.html] which
almost everything in [Numbers] is based on)
* accumulation
can be provided together (without too much loss of performance).
bq. performance implications
I certainly did not get similar results; we likely are testing different
use-cases...
Such a big discrepancy would warrant a separation of the above two properties.
IMO a *mutable* class in the public API is a serious problem. I recall that a
long, long, time ago, we switched to an immutable {{Vector3D}} on the ground
that it was _not_ less performant.
bq. source algorithms
IMHO it is confusing to use both a generic name ("Sum") and assume specific
implementations' requirements.
Shall we define an interface:
{code}
public interface SumOfProducts implements DoubleSupplier,
BinaryOperator {
SumOfProducts add(double m1, double m2);
SumOfProducts add(SumOfProducts other);
@Override
default SumOfProducts apply(SumOfProducts a, SumOfProducts b) {
return a.add(b);
}
// ...
}
{code}
?
Also: What about following Alex's suggestion of an "enum", in order to provide
a choice of implementations (with specific accuracy and performance
expectations, as per its reference description)?
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Attachments: FMA.java, Sum.java
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JEXL-352) Possible memory leak regarding parser jjtree nodes in JEXL 3.2
[
https://issues.apache.org/jira/browse/JEXL-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365271#comment-17365271
]
Øyvind Horneland commented on JEXL-352:
---
Excellent! Thank you.
> Possible memory leak regarding parser jjtree nodes in JEXL 3.2
> --
>
> Key: JEXL-352
> URL: https://issues.apache.org/jira/browse/JEXL-352
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: * JEXL 3.2
> * Java 11
> * Jetty 9.4.41.v20210516
>
>Reporter: Øyvind Horneland
>Assignee: Henri Biestro
>Priority: Critical
> Fix For: 3.2.1
>
> Attachments: jexl-engine-hprof.png
>
>
> Our application encountered a memory leak issue after upgrading from JEXL 3.1
> to 3.2.
> It seems that every call to JexlEngine createExpression now adds new entries
> to engine.parser.jjtree.nodes. In our case we suddenly had millions of nodes
> in this list.
> This sample seems to reproduce the issue
> {code:java}
> JexlEngine jexlEngine = new JexlBuilder().create();
> String testExpression = "dummy";
> jexlEngine.createExpression(testExpression); //
> jexlEngine.parser.jjtree.nodes.size() == 1
> jexlEngine.createExpression(testExpression); //
> jexlEngine.parser.jjtree.nodes.size() == 2
> {code}
> We currently don't cache the returned expression and JexlEngine is configured
> with defaults as shown in the sample.
> Note that calling jexlEngine.clearCache() does not free the nodes.
> Attached screenshot for the hprof of our application with ~ 1.7 million nodes
> in jjtree.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
