[GitHub] [commons-text] garydgregory merged pull request #296: Bump spotbugs from 4.5.2 to 4.5.3
garydgregory merged pull request #296: URL: https://github.com/apache/commons-text/pull/296 -- 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-text] garydgregory merged pull request #295: Bump graalvm.version from 21.3.0 to 22.0.0
garydgregory merged pull request #295: URL: https://github.com/apache/commons-text/pull/295 -- 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-text] dependabot[bot] opened a new pull request #296: Bump spotbugs from 4.5.2 to 4.5.3
dependabot[bot] opened a new pull request #296: URL: https://github.com/apache/commons-text/pull/296 Bumps [spotbugs](https://github.com/spotbugs/spotbugs) from 4.5.2 to 4.5.3. Release notes Sourced from https://github.com/spotbugs/spotbugs/releases;>spotbugs's releases. SpotBugs 4.5.3 CHANGELOG Security Bumped log4j from 2.16.0 to 2.17.1 to address https://nvd.nist.gov/vuln/detail/CVE-2021-45105;>CVE-2021-45105 and https://nvd.nist.gov/vuln/detail/CVE-2021-44832;>CVE-2021-44832 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1885;>#1885, https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1897;>#1897) Fixed Remove duplicated logging frameworks from the Eclipse plugin distribution (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1868;>#1868) https://github.com/KengoTODA;>@KengoTODA Corrected class name validation to no longer fail for Kotlin classes on class path containing special characters. (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1883;>#1883) https://github.com/studro;>@studro CHECKSUM file checksum (sha256) spotbugs-4.5.3-javadoc.jar c5762e13d996117c5ae94675f6ab835d515c90a8cce7d10438bb99d004e0005a spotbugs-4.5.3-sources.jar 196df4ebf7fb681cb819362461137d4e8b475b6a8229bb65363c7042924b702b spotbugs-4.5.3.tgz 7118d112804701f79172f4c3c8904832cdd085236eaa34ce847c71bddcd08927 spotbugs-4.5.3.zip 15e9ee3a0de47195e6206bb50c0c9e487627ba9affe2da586e05333c1d4a12e8 spotbugs-annotations-4.5.3-javadoc.jar 81825340a691d8b2df8670cb67db4a142d8889b32183c8f1a235bde41b9c1607 spotbugs-annotations-4.5.3-sources.jar b338136e3e82d585348cde58a8fe3a678e16f51a35c31c1463e05fefef557aad spotbugs-annotations.jar cb8ef0e128fefc3885205b09a758bcc5aeca2c4faa205195a10d22301530e4f8 spotbugs-ant-4.5.3-javadoc.jar 9b1902fea658a339414b26559c505f4244b749f823f55568ce8b6c64153b540a spotbugs-ant-4.5.3-sources.jar ce7cfbed848ccb0e3765cec6b9c60c458699aa51f60ad9216cf89dbf38d8d793 spotbugs-ant.jar b866a2a89a03b49e60b5f27e0f5987eb8c12c2d2aefc6e9ddcbcdae345c765db spotbugs.jar 7416dda5bf6f1e2740a906bc86b0db4c4413a039cc81d5a80a171d0996708745 test-harness-4.5.3-javadoc.jar 48a87a2484c96f84292b443ec07d19b327f790b03b42294d016bd12153150540 test-harness-4.5.3-sources.jar 2c1f5ef929453f3b682c7eb7c1e22db3082b5f74c5a5be439be5dc31dd7a31aa test-harness-4.5.3.jar 45ca0e944ee5704318d79f67815cde7ca5f7fb22814e325d00e2d25d9b552659 test-harness-core-4.5.3-javadoc.jar 0adc71c823667b6db8c1284ad20844ad94c59a64f60df108c3c8c99b7b854b08 test-harness-core-4.5.3-sources.jar f320f5eb4069e9686b760b2a6a0760989753225f9e9ce1226e3258ec64795d8a test-harness-core-4.5.3.jar fd1a0c06a5eaff50ed0953d42fb7d69a41031c6a6630ad5e47c38a9f0eaca285 test-harness-jupiter-4.5.3-javadoc.jar c612793dda9d1aef37420e35e415cf54b66fa5348540726ece51ae72d8a81dcc test-harness-jupiter-4.5.3-sources.jar 210353a57016e26b1a654d936a15f039613fa1ac532d485c1b1d03902f6c6315 test-harness-jupiter-4.5.3.jar 18095fec31b85981ecaafdef86ca9ae1e9588e1b9bc6d209f82829cf9d0c13f4 Changelog Sourced from https://github.com/spotbugs/spotbugs/blob/master/CHANGELOG.md;>spotbugs's changelog. 4.5.3 - 2022-01-04 Security Bumped log4j from 2.16.0 to 2.17.1 to address https://nvd.nist.gov/vuln/detail/CVE-2021-45105;>CVE-2021-45105 and https://nvd.nist.gov/vuln/detail/CVE-2021-44832;>CVE-2021-44832 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1885;>#1885, https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1897;>#1897) Fixed Remove duplicated logging frameworks from the Eclipse plugin distribution (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1868;>#1868) Corrected class name validation to no longer fail for Kotlin classes on class path containing special characters. (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1883;>#1883) Commits https://github.com/spotbugs/spotbugs/commit/e7aaa9c69e623c15c30a3210f8a041b0116150e3;>e7aaa9c release 4.5.3 https://github.com/spotbugs/spotbugs/commit/13530c7d2f17f6163f3ccc95eb6935a714bf559e;>13530c7 chore: replace all CRLF with LF https://github.com/spotbugs/spotbugs/commit/df0505a75003213845889444c847bfa1b3c62cad;>df0505a chore: stop handling binary files as text https://github.com/spotbugs/spotbugs/commit/a262e678a6412f3e7e84295b73374190cd22fa34;>a262e67 docs: update CHANGELOG entry https://github.com/spotbugs/spotbugs/commit/f9663e68ac3d4543d940b87b704e2411e8b291a5;>f9663e6 build(deps): bump log4j-slf4j18-impl from 2.17.0 to 2.17.1
[GitHub] [commons-text] dependabot[bot] opened a new pull request #295: Bump graalvm.version from 21.3.0 to 22.0.0
dependabot[bot] opened a new pull request #295: URL: https://github.com/apache/commons-text/pull/295 Bumps `graalvm.version` from 21.3.0 to 22.0.0. Updates `js` from 21.3.0 to 22.0.0 Changelog Sourced from https://github.com/oracle/graaljs/blob/master/CHANGELOG.md;>js's changelog. Version 22.0.0 ECMAScript 2022 mode/features enabled by default. Implemented the https://github.com/tc39/intl-displaynames-v2;>Intl.DisplayNames v2 proposal. Implemented the https://github.com/tc39/proposal-intl-locale-info;>Intl Locale Info proposal. It is available in ECMAScript staging mode (--js.ecmascript-version=staging). Implemented the https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange;>Intl.DateTimeFormat.prototype.formatRange proposal. Implemented the https://github.com/tc39/proposal-intl-extend-timezonename;>Extend TimeZoneName Option proposal. It is available in ECMAScript staging mode (--js.ecmascript-version=staging). Implemented the https://github.com/tc39/proposal-intl-enumeration;>Intl Enumeration API proposal. It is available in ECMAScript staging mode (--js.ecmascript-version=staging). Updated Node.js to version 14.18.1. Added option js.esm-bare-specifier-relative-lookup (default: false) to customize how bare specifiers for ES Modules are resolved. When disabled, bare specifiers are resolved with an absolute path lookup. When enabled, bare specifiers are resolved relative to the importing module's path. ICU4J library moved to truffle. Commits https://github.com/oracle/graaljs/commit/8b45fea56704c6d4c085b71d62a2df09943d194f;>8b45fea GraalVM 22.0.0 release https://github.com/oracle/graaljs/commit/81a53720b4b0ba728f673ff637c7fd381e758b6a;>81a5372 [GR-35922] Backport: CompileFunctionInContext() should create the function in... https://github.com/oracle/graaljs/commit/b6f1e9714727dbdc774a18f39509a4ab499a10a3;>b6f1e97 Adding a regression test of parsingContext option of vm.compileFunction(). https://github.com/oracle/graaljs/commit/e8e06415d7663d19a6eedeb73bbd9b732e9af197;>e8e0641 CompileFunctionInContext() should create the function in the right context. https://github.com/oracle/graaljs/commit/c173cf910f0872e7af1d3cf7c3f2d4e40ff5682c;>c173cf9 [GR-35646] Update Truffle import to 22.0 release branch. https://github.com/oracle/graaljs/commit/a403280363a650c23f45f2437c930a09da308d12;>a403280 Fixed naming scheme for language libraries https://github.com/oracle/graaljs/commit/4d5a31e1af1b007390754f18625f2912092147c6;>4d5a31e [GR-24501] Backport: Removing the definition of ICU4J library from graal-js. https://github.com/oracle/graaljs/commit/34ecc9d237ba0a97210435687488fce703befd95;>34ecc9d TestV8 test-suite status update with the expectation of ICU4J update to 70.1. https://github.com/oracle/graaljs/commit/7b6e55b7caebeadbbba68e3d617bcb2dd6dce91a;>7b6e55b Adding a note about the move of ICU4J library into change-log. https://github.com/oracle/graaljs/commit/977fb45299b16392ac9351d5982d163c089f3ad2;>977fb45 Removing the definition of ICU4J library from graal-js. Additional commits viewable in https://github.com/graalvm/graaljs/compare/vm-21.3.0...vm-22.0.0;>compare view Updates `js-scriptengine` from 21.3.0 to 22.0.0 Changelog Sourced from https://github.com/oracle/graaljs/blob/master/CHANGELOG.md;>js-scriptengine's changelog. Version 22.0.0 ECMAScript 2022 mode/features enabled by default. Implemented the https://github.com/tc39/intl-displaynames-v2;>Intl.DisplayNames v2 proposal. Implemented the https://github.com/tc39/proposal-intl-locale-info;>Intl Locale Info proposal. It is available in ECMAScript staging mode (--js.ecmascript-version=staging). Implemented the https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange;>Intl.DateTimeFormat.prototype.formatRange proposal. Implemented the https://github.com/tc39/proposal-intl-extend-timezonename;>Extend TimeZoneName Option proposal. It is available in ECMAScript staging mode (--js.ecmascript-version=staging). Implemented the https://github.com/tc39/proposal-intl-enumeration;>Intl Enumeration API proposal. It is available in ECMAScript staging mode (--js.ecmascript-version=staging). Updated Node.js to version 14.18.1. Added option js.esm-bare-specifier-relative-lookup (default: false) to customize how bare specifiers for ES Modules are resolved. When disabled, bare specifiers are resolved with an absolute path lookup. When enabled, bare specifiers are resolved relative to the importing module's path. ICU4J library moved to truffle. Commits https://github.com/oracle/graaljs/commit/8b45fea56704c6d4c085b71d62a2df09943d194f;>8b45fea GraalVM 22.0.0 release https://github.com/oracle/graaljs/commit/81a53720b4b0ba728f673ff637c7fd381e758b6a;>81a5372 [GR-35922] Backport: CompileFunctionInContext() should create
[jira] [Work logged] (LANG-1662) Create methods on ReflectionToStringBuilder to reflect only select fields
[ https://issues.apache.org/jira/browse/LANG-1662?focusedWorklogId=713050=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-713050 ] ASF GitHub Bot logged work on LANG-1662: Author: ASF GitHub Bot Created on: 21/Jan/22 19:43 Start Date: 21/Jan/22 19:43 Worklog Time Spent: 10m Work Description: rafaelweingartner commented on a change in pull request #849: URL: https://github.com/apache/commons-lang/pull/849#discussion_r789948481 ## File path: src/main/java/org/apache/commons/lang3/builder/ReflectionToStringBuilder.java ## @@ -385,6 +385,19 @@ public static String toStringExclude(final Object object, final Collection Create methods on ReflectionToStringBuilder to reflect only select fields > - > > Key: LANG-1662 > URL: https://issues.apache.org/jira/browse/LANG-1662 > Project: Commons Lang > Issue Type: Improvement > Components: lang.builder.* >Reporter: Daniel Augusto Veronezi Salvador >Priority: Minor > Original Estimate: 6h > Time Spent: 40m > Remaining Estimate: 5h 20m > > *ReflectionToStringBuilder* has methods to exclude fields from *toString*; If > we have an object with several fields and want to reflect only a fews, we > have to list all the fields that we don't want to reflect and pass to > *excludeFieldNames*. > Would be valid implement a way to pass the fields that we want and reflect > only the selected fields? > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-lang] rafaelweingartner commented on a change in pull request #849: [LANG-1662] Create methods on ReflectionToStringBuilder to reflect only select fields
rafaelweingartner commented on a change in pull request #849: URL: https://github.com/apache/commons-lang/pull/849#discussion_r789948481 ## File path: src/main/java/org/apache/commons/lang3/builder/ReflectionToStringBuilder.java ## @@ -385,6 +385,19 @@ public static String toStringExclude(final Object object, final Collection
[jira] [Work logged] (LANG-1662) Create methods on ReflectionToStringBuilder to reflect only select fields
[ https://issues.apache.org/jira/browse/LANG-1662?focusedWorklogId=713049=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-713049 ] ASF GitHub Bot logged work on LANG-1662: Author: ASF GitHub Bot Created on: 21/Jan/22 19:41 Start Date: 21/Jan/22 19:41 Worklog Time Spent: 10m Work Description: GutoVeronezi commented on a change in pull request #849: URL: https://github.com/apache/commons-lang/pull/849#discussion_r789947238 ## File path: src/main/java/org/apache/commons/lang3/builder/ReflectionToStringBuilder.java ## @@ -385,6 +385,19 @@ public static String toStringExclude(final Object object, final Collection Create methods on ReflectionToStringBuilder to reflect only select fields > - > > Key: LANG-1662 > URL: https://issues.apache.org/jira/browse/LANG-1662 > Project: Commons Lang > Issue Type: Improvement > Components: lang.builder.* >Reporter: Daniel Augusto Veronezi Salvador >Priority: Minor > Original Estimate: 6h > Time Spent: 0.5h > Remaining Estimate: 5.5h > > *ReflectionToStringBuilder* has methods to exclude fields from *toString*; If > we have an object with several fields and want to reflect only a fews, we > have to list all the fields that we don't want to reflect and pass to > *excludeFieldNames*. > Would be valid implement a way to pass the fields that we want and reflect > only the selected fields? > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-lang] GutoVeronezi commented on a change in pull request #849: [LANG-1662] Create methods on ReflectionToStringBuilder to reflect only select fields
GutoVeronezi commented on a change in pull request #849: URL: https://github.com/apache/commons-lang/pull/849#discussion_r789947238 ## File path: src/main/java/org/apache/commons/lang3/builder/ReflectionToStringBuilder.java ## @@ -385,6 +385,19 @@ public static String toStringExclude(final Object object, final Collection
[jira] [Work logged] (LANG-1662) Create methods on ReflectionToStringBuilder to reflect only select fields
[ https://issues.apache.org/jira/browse/LANG-1662?focusedWorklogId=713048=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-713048 ] ASF GitHub Bot logged work on LANG-1662: Author: ASF GitHub Bot Created on: 21/Jan/22 19:37 Start Date: 21/Jan/22 19:37 Worklog Time Spent: 10m Work Description: rafaelweingartner commented on a change in pull request #849: URL: https://github.com/apache/commons-lang/pull/849#discussion_r789944501 ## File path: src/main/java/org/apache/commons/lang3/builder/ReflectionToStringBuilder.java ## @@ -385,6 +385,19 @@ public static String toStringExclude(final Object object, final Collection Create methods on ReflectionToStringBuilder to reflect only select fields > - > > Key: LANG-1662 > URL: https://issues.apache.org/jira/browse/LANG-1662 > Project: Commons Lang > Issue Type: Improvement > Components: lang.builder.* >Reporter: Daniel Augusto Veronezi Salvador >Priority: Minor > Original Estimate: 6h > Time Spent: 20m > Remaining Estimate: 5h 40m > > *ReflectionToStringBuilder* has methods to exclude fields from *toString*; If > we have an object with several fields and want to reflect only a fews, we > have to list all the fields that we don't want to reflect and pass to > *excludeFieldNames*. > Would be valid implement a way to pass the fields that we want and reflect > only the selected fields? > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-lang] rafaelweingartner commented on a change in pull request #849: [LANG-1662] Create methods on ReflectionToStringBuilder to reflect only select fields
rafaelweingartner commented on a change in pull request #849: URL: https://github.com/apache/commons-lang/pull/849#discussion_r789944501 ## File path: src/main/java/org/apache/commons/lang3/builder/ReflectionToStringBuilder.java ## @@ -385,6 +385,19 @@ public static String toStringExclude(final Object object, final Collection
[jira] [Commented] (POOL-404) No way to close evictor thread
[
https://issues.apache.org/jira/browse/POOL-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480250#comment-17480250
]
Phil Steitz commented on POOL-404:
--
That would have to be a *global* JVM-level close that would not be advisable
[~ggregory] . [~patrickjamesbarry] , those references are to evictors for
pools that appear to be open. Are you sure that your code is calling close on
each pool that it creates?
> No way to close evictor thread
> --
>
> Key: POOL-404
> URL: https://issues.apache.org/jira/browse/POOL-404
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.11.1
>Reporter: Patrick Barry
>Priority: Major
>
> Using GenericObjectPool> to help with
> lettuce client/redis connection management. I have everything shutting down
> cleanly except the commons-pool-evictor. I see this problem has been
> reported many times in the past, but all the changes are still not allowing
> this thread to shut down cleanly on close. I am using version 2.11.1. I
> have tried to code around this issue, but because EvictionTimer.java is so
> locked down, there is very little that can done to change the behavior of how
> this class interacts with GenericObjectPool.
> For this thread to shutdown, the taskMap has to be empty, which it never is
> in my case. So even though we call close() on the pool, this class fails to
> shutdown the embedded executor because it thinks it has more tasks.
> Looking at this code, it did remove 1 entry from taskMap, but we had many
> more in that map. Is there a way to clear this map, so it will allow this
> thread/executor to shutdown?
> {code:java}
> static synchronized void cancel(final BaseGenericObjectPool.Evictor
> evictor, final Duration timeout,
> final boolean restarting) {
> if (evictor != null) {
> evictor.cancel(); //why does this not interrupt!?
> remove(evictor);
> }
> if (!restarting && executor != null && taskMap.isEmpty()) { //<-- How do
> you force taskMap to be empty!?
> executor.shutdown();
> try {
> executor.awaitTermination(timeout.toMillis(),
> TimeUnit.MILLISECONDS);
> } catch (final InterruptedException e) {
> // Swallow
> // Significant API changes would be required to propagate this
> }
> executor.setCorePoolSize(0);
> executor = null;
> }
> }{code}
> }
> I had all these entries in the taskMap when trying to shut down:
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@73d4066e
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@3c69362a
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@2412a42b
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@45404d5
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@29138d3a
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@5cbe2654
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@6dbcf214
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@496a31da
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@7c251f90
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@51841ac6
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@5ba26eb0
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@435e60ff
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@17d32e9b
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@66f0548d
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@2e6f610d
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@1e86a5a7
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@10afe71a
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@741f8dbe
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@212dfd39
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@a2ddf26
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@49ede9c7
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@65d57e4e
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@6daf7d37
> *Method calls:*
> pool.close() ->
> stopEvictor(); ->
> startEvictor(Duration.ofMillis(-1L)); ->
> EvictionTimer.cancel(evictor, evictorShutdownTimeoutDuration, false); ->
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Work logged] (LANG-1662) Create methods on ReflectionToStringBuilder to reflect only select fields
[
https://issues.apache.org/jira/browse/LANG-1662?focusedWorklogId=713044=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-713044
]
ASF GitHub Bot logged work on LANG-1662:
Author: ASF GitHub Bot
Created on: 21/Jan/22 19:24
Start Date: 21/Jan/22 19:24
Worklog Time Spent: 10m
Work Description: GutoVeronezi opened a new pull request #849:
URL: https://github.com/apache/commons-lang/pull/849
As commented in JIRA issue
[LANG-1662](https://issues.apache.org/jira/browse/LANG-1662) and the maillist
([here](https://lists.apache.org/thread/348sxhc277r45hkwt39rpdwxmxt5lrrs) and
[here](https://lists.apache.org/thread/4nxrlfrzssv5w09c2gs9sphn7rgoc613)), the
class **ReflectionToStringBuilder** has methods to exclude fields from
*toString*; If we have an object with several fields and want to reflect only
some, we have to list all the fields that we don't want to reflect and pass to
**excludeFieldNames**.
To examplify what I mean:
- In a case which we need to print only the fields `a`, `b` and `e` from
the class `UseCase`, the current solution is:
```java
Example example = new UseCase.Example();
example.setA("test");
example.setB(1);
example.setC(1.1);
example.setD(true);
example.setE(false);
example.setF(false);
example.setG(true);
ToStringBuilder toStringBuilder = new ToStringBuilder(example,
ToStringStyle.JSON_STYLE);
toStringBuilder.append("a", example.getA());
toStringBuilder.append("b", example.getB());
toStringBuilder.append("e", example.isE());
System.out.println(toStringBuilder.build());
```
--
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
Issue Time Tracking
---
Worklog Id: (was: 713044)
Remaining Estimate: 5h 50m (was: 6h)
Time Spent: 10m
> Create methods on ReflectionToStringBuilder to reflect only select fields
> -
>
> Key: LANG-1662
> URL: https://issues.apache.org/jira/browse/LANG-1662
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.builder.*
>Reporter: Daniel Augusto Veronezi Salvador
>Priority: Minor
> Original Estimate: 6h
> Time Spent: 10m
> Remaining Estimate: 5h 50m
>
> *ReflectionToStringBuilder* has methods to exclude fields from *toString*; If
> we have an object with several fields and want to reflect only a fews, we
> have to list all the fields that we don't want to reflect and pass to
> *excludeFieldNames*.
> Would be valid implement a way to pass the fields that we want and reflect
> only the selected fields?
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-lang] GutoVeronezi opened a new pull request #849: [LANG-1662] Create methods on ReflectionToStringBuilder to reflect only select fields
GutoVeronezi opened a new pull request #849:
URL: https://github.com/apache/commons-lang/pull/849
As commented in JIRA issue
[LANG-1662](https://issues.apache.org/jira/browse/LANG-1662) and the maillist
([here](https://lists.apache.org/thread/348sxhc277r45hkwt39rpdwxmxt5lrrs) and
[here](https://lists.apache.org/thread/4nxrlfrzssv5w09c2gs9sphn7rgoc613)), the
class **ReflectionToStringBuilder** has methods to exclude fields from
*toString*; If we have an object with several fields and want to reflect only
some, we have to list all the fields that we don't want to reflect and pass to
**excludeFieldNames**.
To examplify what I mean:
- In a case which we need to print only the fields `a`, `b` and `e` from
the class `UseCase`, the current solution is:
```java
Example example = new UseCase.Example();
example.setA("test");
example.setB(1);
example.setC(1.1);
example.setD(true);
example.setE(false);
example.setF(false);
example.setG(true);
ToStringBuilder toStringBuilder = new ToStringBuilder(example,
ToStringStyle.JSON_STYLE);
toStringBuilder.append("a", example.getA());
toStringBuilder.append("b", example.getB());
toStringBuilder.append("e", example.isE());
System.out.println(toStringBuilder.build());
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (LANG-1662) Create methods on ReflectionToStringBuilder to reflect only select fields
[ https://issues.apache.org/jira/browse/LANG-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Augusto Veronezi Salvador updated LANG-1662: --- Summary: Create methods on ReflectionToStringBuilder to reflect only select fields (was: Create flow to only reflect selected fields on ReflectToStringBuilder) > Create methods on ReflectionToStringBuilder to reflect only select fields > - > > Key: LANG-1662 > URL: https://issues.apache.org/jira/browse/LANG-1662 > Project: Commons Lang > Issue Type: Improvement > Components: lang.builder.* >Reporter: Daniel Augusto Veronezi Salvador >Priority: Minor > Original Estimate: 6h > Remaining Estimate: 6h > > *ReflectionToStringBuilder* has methods to exclude fields from *toString*; If > we have an object with several fields and want to reflect only a fews, we > have to list all the fields that we don't want to reflect and pass to > *excludeFieldNames*. > Would be valid implement a way to pass the fields that we want and reflect > only the selected fields? > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-configuration] dependabot[bot] opened a new pull request #159: Bump jackson-databind from 2.12.4 to 2.13.1
dependabot[bot] opened a new pull request #159: URL: https://github.com/apache/commons-configuration/pull/159 Bumps [jackson-databind](https://github.com/FasterXML/jackson) from 2.12.4 to 2.13.1. Commits See full diff in https://github.com/FasterXML/jackson/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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (POOL-404) No way to close evictor thread
[
https://issues.apache.org/jira/browse/POOL-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480140#comment-17480140
]
Gary D. Gregory edited comment on POOL-404 at 1/21/22, 3:35 PM:
[~psteitz]
Regardless of whether this is an issue in client code or Apache Commons Pool,
should we consider providing an escape hatch as a new close API with a close
mode option? An enum CloseMode (GRACEFUL, IMMEDIATE), somewhat similar to the
recently introduced {{DestroyMode}} for pooled objects? FWIW, just as a side
note, we introduced exactly that enum over in Apache HttpComponents HttpCore 5.
was (Author: garydgregory):
[~psteitz]
Regardless of whether this is an issue in client code or Apache Commons Pool,
should we consider providing an escape hatch as a new close API with a close
mode option? An enum {{{}CloseMode {{}}}{{{}GRACEFUL, {}}}{{{}IMMEDIATE{,
somewhat similar to the recently introduced {{DestroyMode}} for pooled objects?
FWIW, just as a side note, we introduced exactly that enum over in Apache
HttpComponents HttpCore 5.
> No way to close evictor thread
> --
>
> Key: POOL-404
> URL: https://issues.apache.org/jira/browse/POOL-404
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.11.1
>Reporter: Patrick Barry
>Priority: Major
>
> Using GenericObjectPool> to help with
> lettuce client/redis connection management. I have everything shutting down
> cleanly except the commons-pool-evictor. I see this problem has been
> reported many times in the past, but all the changes are still not allowing
> this thread to shut down cleanly on close. I am using version 2.11.1. I
> have tried to code around this issue, but because EvictionTimer.java is so
> locked down, there is very little that can done to change the behavior of how
> this class interacts with GenericObjectPool.
> For this thread to shutdown, the taskMap has to be empty, which it never is
> in my case. So even though we call close() on the pool, this class fails to
> shutdown the embedded executor because it thinks it has more tasks.
> Looking at this code, it did remove 1 entry from taskMap, but we had many
> more in that map. Is there a way to clear this map, so it will allow this
> thread/executor to shutdown?
> {code:java}
> static synchronized void cancel(final BaseGenericObjectPool.Evictor
> evictor, final Duration timeout,
> final boolean restarting) {
> if (evictor != null) {
> evictor.cancel(); //why does this not interrupt!?
> remove(evictor);
> }
> if (!restarting && executor != null && taskMap.isEmpty()) { //<-- How do
> you force taskMap to be empty!?
> executor.shutdown();
> try {
> executor.awaitTermination(timeout.toMillis(),
> TimeUnit.MILLISECONDS);
> } catch (final InterruptedException e) {
> // Swallow
> // Significant API changes would be required to propagate this
> }
> executor.setCorePoolSize(0);
> executor = null;
> }
> }{code}
> }
> I had all these entries in the taskMap when trying to shut down:
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@73d4066e
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@3c69362a
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@2412a42b
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@45404d5
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@29138d3a
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@5cbe2654
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@6dbcf214
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@496a31da
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@7c251f90
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@51841ac6
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@5ba26eb0
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@435e60ff
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@17d32e9b
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@66f0548d
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@2e6f610d
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@1e86a5a7
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@10afe71a
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@741f8dbe
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@212dfd39
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@a2ddf26
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@49ede9c7
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@65d57e4e
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@6daf7d37
> *Method calls:*
> pool.close() ->
>
[jira] [Comment Edited] (POOL-404) No way to close evictor thread
[
https://issues.apache.org/jira/browse/POOL-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480140#comment-17480140
]
Gary D. Gregory edited comment on POOL-404 at 1/21/22, 3:35 PM:
[~psteitz]
Regardless of whether this is an issue in client code or Apache Commons Pool,
should we consider providing an escape hatch as a new close API with a close
mode option? An enum {{{}CloseMode {{}}}{{{}GRACEFUL, {}}}{{{}IMMEDIATE{,
somewhat similar to the recently introduced {{DestroyMode}} for pooled objects?
FWIW, just as a side note, we introduced exactly that enum over in Apache
HttpComponents HttpCore 5.
was (Author: garydgregory):
[~psteitz]
Regardless of whether this is an issue in client code or Apache Commons Pool,
should we consider providing an escape hatch as a new close API with a close
mode option? An enum {{{}CloseMode {{}}}{{{}GRACEFUL, {}}}{{{}IMMEDIATE{,
somewhat similar to the recently introduced {{DestroyMode}} for pooled objects?
FWIW, just as a side note, we introduced exactly that enum over in Apache
HttpComponents HttpCore 5.
> No way to close evictor thread
> --
>
> Key: POOL-404
> URL: https://issues.apache.org/jira/browse/POOL-404
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.11.1
>Reporter: Patrick Barry
>Priority: Major
>
> Using GenericObjectPool> to help with
> lettuce client/redis connection management. I have everything shutting down
> cleanly except the commons-pool-evictor. I see this problem has been
> reported many times in the past, but all the changes are still not allowing
> this thread to shut down cleanly on close. I am using version 2.11.1. I
> have tried to code around this issue, but because EvictionTimer.java is so
> locked down, there is very little that can done to change the behavior of how
> this class interacts with GenericObjectPool.
> For this thread to shutdown, the taskMap has to be empty, which it never is
> in my case. So even though we call close() on the pool, this class fails to
> shutdown the embedded executor because it thinks it has more tasks.
> Looking at this code, it did remove 1 entry from taskMap, but we had many
> more in that map. Is there a way to clear this map, so it will allow this
> thread/executor to shutdown?
> {code:java}
> static synchronized void cancel(final BaseGenericObjectPool.Evictor
> evictor, final Duration timeout,
> final boolean restarting) {
> if (evictor != null) {
> evictor.cancel(); //why does this not interrupt!?
> remove(evictor);
> }
> if (!restarting && executor != null && taskMap.isEmpty()) { //<-- How do
> you force taskMap to be empty!?
> executor.shutdown();
> try {
> executor.awaitTermination(timeout.toMillis(),
> TimeUnit.MILLISECONDS);
> } catch (final InterruptedException e) {
> // Swallow
> // Significant API changes would be required to propagate this
> }
> executor.setCorePoolSize(0);
> executor = null;
> }
> }{code}
> }
> I had all these entries in the taskMap when trying to shut down:
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@73d4066e
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@3c69362a
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@2412a42b
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@45404d5
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@29138d3a
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@5cbe2654
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@6dbcf214
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@496a31da
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@7c251f90
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@51841ac6
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@5ba26eb0
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@435e60ff
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@17d32e9b
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@66f0548d
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@2e6f610d
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@1e86a5a7
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@10afe71a
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@741f8dbe
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@212dfd39
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@a2ddf26
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@49ede9c7
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@65d57e4e
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@6daf7d37
> *Method calls:*
>
[jira] [Commented] (POOL-404) No way to close evictor thread
[
https://issues.apache.org/jira/browse/POOL-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480140#comment-17480140
]
Gary D. Gregory commented on POOL-404:
--
[~psteitz]
Regardless of whether this is an issue in client code or Apache Commons Pool,
should we consider providing an escape hatch as a new close API with a close
mode option? An enum {{{}CloseMode {{}}}{{{}GRACEFUL, {}}}{{{}IMMEDIATE{,
somewhat similar to the recently introduced {{DestroyMode}} for pooled objects?
FWIW, just as a side note, we introduced exactly that enum over in Apache
HttpComponents HttpCore 5.
> No way to close evictor thread
> --
>
> Key: POOL-404
> URL: https://issues.apache.org/jira/browse/POOL-404
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.11.1
>Reporter: Patrick Barry
>Priority: Major
>
> Using GenericObjectPool> to help with
> lettuce client/redis connection management. I have everything shutting down
> cleanly except the commons-pool-evictor. I see this problem has been
> reported many times in the past, but all the changes are still not allowing
> this thread to shut down cleanly on close. I am using version 2.11.1. I
> have tried to code around this issue, but because EvictionTimer.java is so
> locked down, there is very little that can done to change the behavior of how
> this class interacts with GenericObjectPool.
> For this thread to shutdown, the taskMap has to be empty, which it never is
> in my case. So even though we call close() on the pool, this class fails to
> shutdown the embedded executor because it thinks it has more tasks.
> Looking at this code, it did remove 1 entry from taskMap, but we had many
> more in that map. Is there a way to clear this map, so it will allow this
> thread/executor to shutdown?
> {code:java}
> static synchronized void cancel(final BaseGenericObjectPool.Evictor
> evictor, final Duration timeout,
> final boolean restarting) {
> if (evictor != null) {
> evictor.cancel(); //why does this not interrupt!?
> remove(evictor);
> }
> if (!restarting && executor != null && taskMap.isEmpty()) { //<-- How do
> you force taskMap to be empty!?
> executor.shutdown();
> try {
> executor.awaitTermination(timeout.toMillis(),
> TimeUnit.MILLISECONDS);
> } catch (final InterruptedException e) {
> // Swallow
> // Significant API changes would be required to propagate this
> }
> executor.setCorePoolSize(0);
> executor = null;
> }
> }{code}
> }
> I had all these entries in the taskMap when trying to shut down:
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@73d4066e
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@3c69362a
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@2412a42b
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@45404d5
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@29138d3a
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@5cbe2654
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@6dbcf214
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@496a31da
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@7c251f90
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@51841ac6
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@5ba26eb0
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@435e60ff
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@17d32e9b
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@66f0548d
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@2e6f610d
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@1e86a5a7
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@10afe71a
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@741f8dbe
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@212dfd39
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@a2ddf26
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@49ede9c7
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@65d57e4e
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@6daf7d37
> *Method calls:*
> pool.close() ->
> stopEvictor(); ->
> startEvictor(Duration.ofMillis(-1L)); ->
> EvictionTimer.cancel(evictor, evictorShutdownTimeoutDuration, false); ->
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (STATISTICS-52) High precision PDF for the Normal distribution
[
https://issues.apache.org/jira/browse/STATISTICS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Herbert resolved STATISTICS-52.
Fix Version/s: 1.0
Resolution: Implemented
Added in commit:
f931dd5c6946f505495262beb5ad36603b4ab5bc
> High precision PDF for the Normal distribution
> --
>
> Key: STATISTICS-52
> URL: https://issues.apache.org/jira/browse/STATISTICS-52
> Project: Apache Commons Statistics
> Issue Type: Improvement
> Components: distribution
>Affects Versions: 1.0
>Reporter: Alex Herbert
>Priority: Minor
> Fix For: 1.0
>
>
> The normal distribution PDF is computed using:
>
> {code:java}
> Math.exp(-0.5 * x * x) / Math.sqrt(2 * Math.PI)
> {code}
> The value {{x^2}} can be computed to extended precision. This extra
> information in the round-off bits can increase the accuracy of the
> exponential function (see NUMBERS-177 under the title 'Accurate scaling by
> exp(z*z)').
>
> The effect of including the round-off bits on both accuracy and speed should
> be investigated.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (POOL-404) No way to close evictor thread
[
https://issues.apache.org/jira/browse/POOL-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Barry updated POOL-404:
---
Description:
Using GenericObjectPool> to help with
lettuce client/redis connection management. I have everything shutting down
cleanly except the commons-pool-evictor. I see this problem has been reported
many times in the past, but all the changes are still not allowing this thread
to shut down cleanly on close. I am using version 2.11.1. I have tried to
code around this issue, but because EvictionTimer.java is so locked down, there
is very little that can done to change the behavior of how this class interacts
with GenericObjectPool.
For this thread to shutdown, the taskMap has to be empty, which it never is in
my case. So even though we call close() on the pool, this class fails to
shutdown the embedded executor because it thinks it has more tasks.
Looking at this code, it did remove 1 entry from taskMap, but we had many more
in that map. Is there a way to clear this map, so it will allow this
thread/executor to shutdown?
{code:java}
static synchronized void cancel(final BaseGenericObjectPool.Evictor evictor,
final Duration timeout,
final boolean restarting) {
if (evictor != null) {
evictor.cancel(); //why does this not interrupt!?
remove(evictor);
}
if (!restarting && executor != null && taskMap.isEmpty()) { //<-- How do
you force taskMap to be empty!?
executor.shutdown();
try {
executor.awaitTermination(timeout.toMillis(),
TimeUnit.MILLISECONDS);
} catch (final InterruptedException e) {
// Swallow
// Significant API changes would be required to propagate this
}
executor.setCorePoolSize(0);
executor = null;
}
}{code}
}
I had all these entries in the taskMap when trying to shut down:
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@73d4066e
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@3c69362a
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@2412a42b
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@45404d5
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@29138d3a
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@5cbe2654
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@6dbcf214
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@496a31da
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@7c251f90
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@51841ac6
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@5ba26eb0
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@435e60ff
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@17d32e9b
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@66f0548d
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@2e6f610d
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@1e86a5a7
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@10afe71a
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@741f8dbe
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@212dfd39
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@a2ddf26
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@49ede9c7
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@65d57e4e
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@6daf7d37
*Method calls:*
pool.close() ->
stopEvictor(); ->
startEvictor(Duration.ofMillis(-1L)); ->
EvictionTimer.cancel(evictor, evictorShutdownTimeoutDuration, false); ->
was:
Using GenericObjectPool> to help with
lettuce client/redis connection management. I have everything shutting down
cleanly except the commons-pool-evictor. I see this problem has many reported
in the past, but it still not shutting down. I am using version 2.11.1. I
have tried to code around this issue, but because EvictionTimer.java is so
locked down, there is very little that can done to change the behavior of how
this class interacts with GenericObjectPool.
For this thread to shutdown, the taskMap has to be empty, which it never is in
my case. So even thought we call close() on the pool, this class fails to
shutdown the embedded executor because it thinks it has more tasks.
Looking at this code, it did remove 1 entry from taskMap, but we had many more
in that map. Is there a way to clear this map, so it will allow this
thread/executor to shutdown?
{code:java}
static synchronized void cancel(final BaseGenericObjectPool.Evictor evictor,
final Duration timeout,
final boolean restarting) {
if (evictor != null) {
evictor.cancel(); //why does this not interrupt!?
remove(evictor);
}
if (!restarting && executor != null && taskMap.isEmpty()) { //<-- How do
you force taskMap to be empty!?
[jira] [Commented] (STATISTICS-52) High precision PDF for the Normal distribution
[
https://issues.apache.org/jira/browse/STATISTICS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480077#comment-17480077
]
Alex Herbert commented on STATISTICS-52:
The previous JMH benchmark only tested the call to the exponential function.
However the normal distribution PDF requires more computations:
{code:java}
// provided
double mean, sd;
// Precomputed
double sdSqrt2pi = sd * Math.sqrt(2 * Math.PI);
double density(double x) {
final double z = (x - mean) / sd;
return Math.exp(-0.5 * z * z) / sdSqrt2pi;
}{code}
Thus the density computation must first normalise the input value x, compute
the exponential and perform a divide. Even if the mean and standard are 0 and 1
the divide uses a non-trivial value of 2.5066. Thus the benchmark has been
updated to include the extra steps.
Note the extra columns in the results simply remove the time for generation of
the random deviate in the baseline method:
{noformat}
baseline = generation of random X deviate
std = standard precision PDF
hp = high-precision PDF
Adjusted = Score[method] - Score[baseline]
Relative = Adjusted[2] / Adjusted[1]{noformat}
h2. Normally distributed X deviate
||Method||Score||Adjusted||Relative||
| baseline|8.878| | |
| std|34.722|25.844| |
| hp|35.897|27.019|1.045|
On this data the difference is lower (4.5%) than the previously observed 10%
for the exp function in isolation.
h2. Uniformally distributed X deviate
||Method||Low||High||Score||Adjusted||Relative||
| baseline|0|1|8.94| | |
| std|0|1|36.947|28.007| |
| hp|0|1|36.858|27.918|0.997|
| baseline|0|10|8.902| | |
| std|0|10|37.161|28.259| |
| hp|0|10|40.043|31.141|1.102|
| baseline|0|30|8.841| | |
| std|0|30|36.84|27.999| |
| hp|0|30|39.684|30.843|1.102|
| baseline|0|100|8.981| | |
| std|0|100|32.619|23.638| |
| hp|0|100|28.142|19.161|0.811|
| baseline|2|20|9.184| | |
| std|2|20|36.932|27.748| |
| hp|2|20|39.526|30.342|1.093|
| baseline|0|2.83|8.894| | |
| std|0|2.83|36.879|27.985| |
| hp|0|2.83|41.707|32.813|1.173|
When the full PDF is computed the relative speed difference is minor compared
to the previous benchmark of the exp function.
* When the computation is entirely standard precision ([0, 1]) then there is
no speed difference.
* When it is entirely high precision ([2, 20]) then is is about 10% slower.
* Where the function must choose between the standard precision computation
(x^2 < 2) or high precision then it is again about 10% slower on the [0, 10]
and [0, 30] data.
* In the worst case scenario of [0, 2.83] the random deviate value x^2 will be
< 2 approximately 50% of the time. This is 17% slower.
* On the [0, 100] data the method is faster; in this data about 60% of the
time the computation will not call Math.exp.
h2. Conclusion
Given that the other computation for the normal distribution CDF also uses a
high precision exp function within the error function (erf) to increase
accuracy it would be consistent to add the high precision PDF. The overall
speed impact is minor at around 5% slower on normally distributed X data and
17% slower on worse case uniformly distributed input data.
> High precision PDF for the Normal distribution
> --
>
> Key: STATISTICS-52
> URL: https://issues.apache.org/jira/browse/STATISTICS-52
> Project: Apache Commons Statistics
> Issue Type: Improvement
> Components: distribution
>Affects Versions: 1.0
>Reporter: Alex Herbert
>Priority: Minor
>
> The normal distribution PDF is computed using:
>
> {code:java}
> Math.exp(-0.5 * x * x) / Math.sqrt(2 * Math.PI)
> {code}
> The value {{x^2}} can be computed to extended precision. This extra
> information in the round-off bits can increase the accuracy of the
> exponential function (see NUMBERS-177 under the title 'Accurate scaling by
> exp(z*z)').
>
> The effect of including the round-off bits on both accuracy and speed should
> be investigated.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-parent] garydgregory merged pull request #88: Bump maven-compiler-plugin from 3.8.1 to 3.9.0
garydgregory merged pull request #88: URL: https://github.com/apache/commons-parent/pull/88 -- 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-csv] garydgregory merged pull request #211: Bump spotbugs-maven-plugin from 4.5.2.0 to 4.5.3.0
garydgregory merged pull request #211: URL: https://github.com/apache/commons-csv/pull/211 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-dbcp] garydgregory merged pull request #159: Bump h2 from 2.0.204 to 2.0.206
garydgregory merged pull request #159: URL: https://github.com/apache/commons-dbcp/pull/159 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (IO-663) FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
[
https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480052#comment-17480052
]
elharo commented on IO-663:
---
Looks like it was open only for reading. See discussion and PR on
https://issues.apache.org/jira/browse/MRELEASE-1066
> FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
> ---
>
> Key: IO-663
> URL: https://issues.apache.org/jira/browse/IO-663
> Project: Commons IO
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Critical
>
> This bug is shared (likely because of code copied from one place to another)
> between the similar methods in commons IO, codehaus-plexus-utils, and
> maven-shared-utils.
> I don't have an isolated test case because this bug is platform specific and
> I've only seen it in Jenkins CI builds on Windows using JDK 7 through 15. I
> don't have a Windows system handy to test it. However it is reproducible.
> Typical code that triggers it is in RestoreBackupPomsPhaseTest in
> maven-release:
> {{// copy poms so tests are valid without clean}}
> {{ File sourceDir = getTestFile( "src/test/resources" + projectPath );}}
> {{ File testDir = getTestFile( "target/test-classes" + projectPath );}}
> {{ FileUtils.copyDirectoryStructure( sourceDir, testDir );}}
> I don't know whether there might be something weird in the setup of those two
> directories that's involved.
> Typical error message is:
> Caused by: java.nio.file.FileSystemException:
>
> F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml:
> The process cannot access the file because it is being used by another
> process
> "The process cannot access the file because it is being used by another
> process" I think points to the root of the bug. This is a Windows file system
> error message.
> Some history is here where I noticed it:
> [https://github.com/apache/maven-release/pull/42]
> In this case, I started with plexus-utils 3.1.0 which worked, upgraded to
> plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory
> from both maven-shared-utils and commons-io, all of which failed in the same
> way.
> I think this is caused by the use of NIO, which doesn't work quite the same
> when copying files on Windows as on Linux and Mac OS X.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IO-663) FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
[
https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480048#comment-17480048
]
elharo commented on IO-663:
---
Not sure. I think this is the pR that fixed it:
https://github.com/apache/maven-release/pull/87 for maven-release
> FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
> ---
>
> Key: IO-663
> URL: https://issues.apache.org/jira/browse/IO-663
> Project: Commons IO
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Critical
>
> This bug is shared (likely because of code copied from one place to another)
> between the similar methods in commons IO, codehaus-plexus-utils, and
> maven-shared-utils.
> I don't have an isolated test case because this bug is platform specific and
> I've only seen it in Jenkins CI builds on Windows using JDK 7 through 15. I
> don't have a Windows system handy to test it. However it is reproducible.
> Typical code that triggers it is in RestoreBackupPomsPhaseTest in
> maven-release:
> {{// copy poms so tests are valid without clean}}
> {{ File sourceDir = getTestFile( "src/test/resources" + projectPath );}}
> {{ File testDir = getTestFile( "target/test-classes" + projectPath );}}
> {{ FileUtils.copyDirectoryStructure( sourceDir, testDir );}}
> I don't know whether there might be something weird in the setup of those two
> directories that's involved.
> Typical error message is:
> Caused by: java.nio.file.FileSystemException:
>
> F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml:
> The process cannot access the file because it is being used by another
> process
> "The process cannot access the file because it is being used by another
> process" I think points to the root of the bug. This is a Windows file system
> error message.
> Some history is here where I noticed it:
> [https://github.com/apache/maven-release/pull/42]
> In this case, I started with plexus-utils 3.1.0 which worked, upgraded to
> plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory
> from both maven-shared-utils and commons-io, all of which failed in the same
> way.
> I think this is caused by the use of NIO, which doesn't work quite the same
> when copying files on Windows as on Linux and Mac OS X.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (CLI-314) Release notes are missing
elharo created CLI-314: -- Summary: Release notes are missing Key: CLI-314 URL: https://issues.apache.org/jira/browse/CLI-314 Project: Commons CLI Issue Type: Bug Reporter: elharo Link on the home page https://commons.apache.org/proper/commons-cli/ to the release notes is 404 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-csv] dependabot[bot] opened a new pull request #211: Bump spotbugs-maven-plugin from 4.5.2.0 to 4.5.3.0
dependabot[bot] opened a new pull request #211: URL: https://github.com/apache/commons-csv/pull/211 Bumps [spotbugs-maven-plugin](https://github.com/spotbugs/spotbugs-maven-plugin) from 4.5.2.0 to 4.5.3.0. Release notes Sourced from https://github.com/spotbugs/spotbugs-maven-plugin/releases;>spotbugs-maven-plugin's releases. Spotbugs-maven-plugin 4.5.3.0 Support spotbugs maven plugin 4.5.3.0 Make maven scoped dependencies provided scope Commits https://github.com/spotbugs/spotbugs-maven-plugin/commit/ae3658622b8590836b7994801526c39e52f2e76f;>ae36586 [maven-release-plugin] prepare release spotbugs-maven-plugin-4.5.3.0 https://github.com/spotbugs/spotbugs-maven-plugin/commit/03b7e0dae5375b33abc6f3f2cda80fa6824b4b9e;>03b7e0d Merge pull request https://github-redirect.dependabot.com/spotbugs/spotbugs-maven-plugin/issues/392;>#392 from hazendaz/spotbugs https://github.com/spotbugs/spotbugs-maven-plugin/commit/477b67e3277a419386c384830b831b59fd2bf188;>477b67e [pom] Bump spotbugs to 4.5.3 https://github.com/spotbugs/spotbugs-maven-plugin/commit/4c29db7bfa66552bc972eb70369d0c677e7de434;>4c29db7 Merge pull request https://github-redirect.dependabot.com/spotbugs/spotbugs-maven-plugin/issues/390;>#390 from hazendaz/spotbugs https://github.com/spotbugs/spotbugs-maven-plugin/commit/7ceb76b9bb290eb393eea8f52eaced6cdc8281f5;>7ceb76b [actions] Adjust name for wrapper 3.3.9 usage and wrapper goal https://github.com/spotbugs/spotbugs-maven-plugin/commit/15b5b51bb0d0c81d9cd84685354be31510fbe142;>15b5b51 [actions] Add github action to run entirely through maven 3.3.9 https://github.com/spotbugs/spotbugs-maven-plugin/commit/fd7b8cc94f0f57d4a2d605f00ed609de16d0dd3c;>fd7b8cc Merge pull request https://github-redirect.dependabot.com/spotbugs/spotbugs-maven-plugin/issues/389;>#389 from hazendaz/spotbugs https://github.com/spotbugs/spotbugs-maven-plugin/commit/196b77ff23e457b82a0ea624c19bf0e8ae60d662;>196b77f [mvn] Update maven wrapper https://github.com/spotbugs/spotbugs-maven-plugin/commit/15fff12958c4f97550313383852901d32ea2cecb;>15fff12 Merge pull request https://github-redirect.dependabot.com/spotbugs/spotbugs-maven-plugin/issues/388;>#388 from hazendaz/spotbugs https://github.com/spotbugs/spotbugs-maven-plugin/commit/6c0bb1e9c333c887d096747409d621d37933f943;>6c0bb1e Merge pull request https://github-redirect.dependabot.com/spotbugs/spotbugs-maven-plugin/issues/387;>#387 from spotbugs/dependabot/maven/scmPluginVersion-1.12.2 Additional commits viewable in https://github.com/spotbugs/spotbugs-maven-plugin/compare/spotbugs-maven-plugin-4.5.2.0...spotbugs-maven-plugin-4.5.3.0;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-parent] dependabot[bot] opened a new pull request #88: Bump maven-compiler-plugin from 3.8.1 to 3.9.0
dependabot[bot] opened a new pull request #88: URL: https://github.com/apache/commons-parent/pull/88 Bumps [maven-compiler-plugin](https://github.com/apache/maven-compiler-plugin) from 3.8.1 to 3.9.0. Commits https://github.com/apache/maven-compiler-plugin/commit/aeb15b6cf38ee44391febf23310a4f2b432ab444;>aeb15b6 [maven-release-plugin] prepare release maven-compiler-plugin-3.9.0 https://github.com/apache/maven-compiler-plugin/commit/6335382f97aad2e69b9f9a0a4af3cf801cd29273;>6335382 Shared GitHub Acton v2 https://github.com/apache/maven-compiler-plugin/commit/8d5d3cd68db3cefb947e1e1bf5fd83ac231ef00d;>8d5d3cd Fix site build https://github.com/apache/maven-compiler-plugin/commit/ce4eb1e353d176f8573f7a3ba893fc3ec42ec21b;>ce4eb1e Bump plexus-component-metadata from 2.1.0 to 2.1.1 https://github.com/apache/maven-compiler-plugin/commit/f875750ee9bcf07bb25b470c5ceb73d7dccfbe12;>f875750 Bump mockito-core from 4.1.0 to 4.2.0 https://github.com/apache/maven-compiler-plugin/commit/5463357ebc1c65a4e25bfd8ea4c453a618b66bf1;>5463357 fix CI site goal https://github.com/apache/maven-compiler-plugin/commit/859c9039e4b73367a0d9486cc63b98ec1cc1fa6f;>859c903 Update plugins https://github.com/apache/maven-compiler-plugin/commit/b0de9bc0fbe9416e81b6a13cb9e67fdf891192af;>b0de9bc Bump mockito-core from 4.0.0 to 4.1.0 https://github.com/apache/maven-compiler-plugin/commit/f95dd463d904276564ac47ee822c37ac8751f4e9;>f95dd46 Bump plexusCompilerVersion from 2.8.8 to 2.9.0 https://github.com/apache/maven-compiler-plugin/commit/26900cfe598981a516b66e01843e79f1c486a147;>26900cf Bump mockito-core from 2.28.2 to 4.0.0 Additional commits viewable in https://github.com/apache/maven-compiler-plugin/compare/maven-compiler-plugin-3.8.1...maven-compiler-plugin-3.9.0;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-release-plugin] kinow merged pull request #97: Bump maven.plugin.version from 3.6.2 to 3.6.4
kinow merged pull request #97: URL: https://github.com/apache/commons-release-plugin/pull/97 -- 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-release-plugin] kinow commented on pull request #97: Bump maven.plugin.version from 3.6.2 to 3.6.4
kinow commented on pull request #97: URL: https://github.com/apache/commons-release-plugin/pull/97#issuecomment-1018420169 @dependabot rebase -- 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-release-plugin] kinow merged pull request #98: Bump spotbugs from 4.5.2 to 4.5.3
kinow merged pull request #98: URL: https://github.com/apache/commons-release-plugin/pull/98 -- 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-release-plugin] dependabot[bot] opened a new pull request #98: Bump spotbugs from 4.5.2 to 4.5.3
dependabot[bot] opened a new pull request #98: URL: https://github.com/apache/commons-release-plugin/pull/98 Bumps [spotbugs](https://github.com/spotbugs/spotbugs) from 4.5.2 to 4.5.3. Release notes Sourced from https://github.com/spotbugs/spotbugs/releases;>spotbugs's releases. SpotBugs 4.5.3 CHANGELOG Security Bumped log4j from 2.16.0 to 2.17.1 to address https://nvd.nist.gov/vuln/detail/CVE-2021-45105;>CVE-2021-45105 and https://nvd.nist.gov/vuln/detail/CVE-2021-44832;>CVE-2021-44832 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1885;>#1885, https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1897;>#1897) Fixed Remove duplicated logging frameworks from the Eclipse plugin distribution (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1868;>#1868) https://github.com/KengoTODA;>@KengoTODA Corrected class name validation to no longer fail for Kotlin classes on class path containing special characters. (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1883;>#1883) https://github.com/studro;>@studro CHECKSUM file checksum (sha256) spotbugs-4.5.3-javadoc.jar c5762e13d996117c5ae94675f6ab835d515c90a8cce7d10438bb99d004e0005a spotbugs-4.5.3-sources.jar 196df4ebf7fb681cb819362461137d4e8b475b6a8229bb65363c7042924b702b spotbugs-4.5.3.tgz 7118d112804701f79172f4c3c8904832cdd085236eaa34ce847c71bddcd08927 spotbugs-4.5.3.zip 15e9ee3a0de47195e6206bb50c0c9e487627ba9affe2da586e05333c1d4a12e8 spotbugs-annotations-4.5.3-javadoc.jar 81825340a691d8b2df8670cb67db4a142d8889b32183c8f1a235bde41b9c1607 spotbugs-annotations-4.5.3-sources.jar b338136e3e82d585348cde58a8fe3a678e16f51a35c31c1463e05fefef557aad spotbugs-annotations.jar cb8ef0e128fefc3885205b09a758bcc5aeca2c4faa205195a10d22301530e4f8 spotbugs-ant-4.5.3-javadoc.jar 9b1902fea658a339414b26559c505f4244b749f823f55568ce8b6c64153b540a spotbugs-ant-4.5.3-sources.jar ce7cfbed848ccb0e3765cec6b9c60c458699aa51f60ad9216cf89dbf38d8d793 spotbugs-ant.jar b866a2a89a03b49e60b5f27e0f5987eb8c12c2d2aefc6e9ddcbcdae345c765db spotbugs.jar 7416dda5bf6f1e2740a906bc86b0db4c4413a039cc81d5a80a171d0996708745 test-harness-4.5.3-javadoc.jar 48a87a2484c96f84292b443ec07d19b327f790b03b42294d016bd12153150540 test-harness-4.5.3-sources.jar 2c1f5ef929453f3b682c7eb7c1e22db3082b5f74c5a5be439be5dc31dd7a31aa test-harness-4.5.3.jar 45ca0e944ee5704318d79f67815cde7ca5f7fb22814e325d00e2d25d9b552659 test-harness-core-4.5.3-javadoc.jar 0adc71c823667b6db8c1284ad20844ad94c59a64f60df108c3c8c99b7b854b08 test-harness-core-4.5.3-sources.jar f320f5eb4069e9686b760b2a6a0760989753225f9e9ce1226e3258ec64795d8a test-harness-core-4.5.3.jar fd1a0c06a5eaff50ed0953d42fb7d69a41031c6a6630ad5e47c38a9f0eaca285 test-harness-jupiter-4.5.3-javadoc.jar c612793dda9d1aef37420e35e415cf54b66fa5348540726ece51ae72d8a81dcc test-harness-jupiter-4.5.3-sources.jar 210353a57016e26b1a654d936a15f039613fa1ac532d485c1b1d03902f6c6315 test-harness-jupiter-4.5.3.jar 18095fec31b85981ecaafdef86ca9ae1e9588e1b9bc6d209f82829cf9d0c13f4 Changelog Sourced from https://github.com/spotbugs/spotbugs/blob/master/CHANGELOG.md;>spotbugs's changelog. 4.5.3 - 2022-01-04 Security Bumped log4j from 2.16.0 to 2.17.1 to address https://nvd.nist.gov/vuln/detail/CVE-2021-45105;>CVE-2021-45105 and https://nvd.nist.gov/vuln/detail/CVE-2021-44832;>CVE-2021-44832 (https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1885;>#1885, https://github-redirect.dependabot.com/spotbugs/spotbugs/pull/1897;>#1897) Fixed Remove duplicated logging frameworks from the Eclipse plugin distribution (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1868;>#1868) Corrected class name validation to no longer fail for Kotlin classes on class path containing special characters. (https://github-redirect.dependabot.com/spotbugs/spotbugs/issues/1883;>#1883) Commits https://github.com/spotbugs/spotbugs/commit/e7aaa9c69e623c15c30a3210f8a041b0116150e3;>e7aaa9c release 4.5.3 https://github.com/spotbugs/spotbugs/commit/13530c7d2f17f6163f3ccc95eb6935a714bf559e;>13530c7 chore: replace all CRLF with LF https://github.com/spotbugs/spotbugs/commit/df0505a75003213845889444c847bfa1b3c62cad;>df0505a chore: stop handling binary files as text https://github.com/spotbugs/spotbugs/commit/a262e678a6412f3e7e84295b73374190cd22fa34;>a262e67 docs: update CHANGELOG entry https://github.com/spotbugs/spotbugs/commit/f9663e68ac3d4543d940b87b704e2411e8b291a5;>f9663e6 build(deps): bump log4j-slf4j18-impl from 2.17.0 to 2.17.1
[GitHub] [commons-release-plugin] dependabot[bot] opened a new pull request #97: Bump maven.plugin.version from 3.6.2 to 3.6.4
dependabot[bot] opened a new pull request #97: URL: https://github.com/apache/commons-release-plugin/pull/97 Bumps `maven.plugin.version` from 3.6.2 to 3.6.4. Updates `maven-plugin-annotations` from 3.6.2 to 3.6.4 Commits https://github.com/apache/maven-plugin-tools/commit/33eb6d9df8be0e9cd0ac9b684741382b3d0e0fc7;>33eb6d9 [maven-release-plugin] prepare release maven-plugin-tools-3.6.4 https://github.com/apache/maven-plugin-tools/commit/c8ddcdcb10d342a5a5e2f38245bb569af5730c7c;>c8ddcdc [MPLUGIN-387] Bump Ant to 1.9.16 https://github.com/apache/maven-plugin-tools/commit/f14830dba00667fc661a520557fcdff6a8b0d1ad;>f14830d [MPLUGIN-387] Bump xmlunit to 1.6 https://github.com/apache/maven-plugin-tools/commit/036fdebb5cdbab68d79550cc6a0991f2a96ce4c8;>036fdeb [MPLUGIN-387] Bump plexus-compiler-manager to 2.8.8 https://github.com/apache/maven-plugin-tools/commit/d296e04045026716f1fba5d296a0dd4330cc7f92;>d296e04 [MPLUGIN-387] Switch from fest-assert to AssertJ 2.9.1 https://github.com/apache/maven-plugin-tools/commit/9ff352cc5680fe4e672dd99d0ff9160fc51a1317;>9ff352c [MPLUGIN-387] Bump plexus-archiver to 4.2.5 https://github.com/apache/maven-plugin-tools/commit/f6461047666e7c2dc0103042088825fd6a16a8ab;>f646104 [MPLUGIN-387] Upgrade BeanShell to 2.0b6 https://github.com/apache/maven-plugin-tools/commit/db1803198a77a40917a533e70ece7f066b783bf1;>db18031 [MPLUGIN-387] Bump junit to 4.13.2 https://github.com/apache/maven-plugin-tools/commit/c7ae057613aab21957197f93d33d6c0e2eb55bf8;>c7ae057 Added Dependabot configuration https://github.com/apache/maven-plugin-tools/commit/86d870fbc4a3aa1cd3b8da8a2fde015e5e8dfe43;>86d870f [MPLUGIN-387] Upgrade Doxia/Doxia Tools to 1.11.1 Additional commits viewable in https://github.com/apache/maven-plugin-tools/compare/maven-plugin-tools-3.6.2...maven-plugin-tools-3.6.4;>compare view Updates `maven-plugin-tools-ant` from 3.6.2 to 3.6.4 Updates `maven-plugin-plugin` from 3.6.2 to 3.6.4 Commits https://github.com/apache/maven-plugin-tools/commit/33eb6d9df8be0e9cd0ac9b684741382b3d0e0fc7;>33eb6d9 [maven-release-plugin] prepare release maven-plugin-tools-3.6.4 https://github.com/apache/maven-plugin-tools/commit/c8ddcdcb10d342a5a5e2f38245bb569af5730c7c;>c8ddcdc [MPLUGIN-387] Bump Ant to 1.9.16 https://github.com/apache/maven-plugin-tools/commit/f14830dba00667fc661a520557fcdff6a8b0d1ad;>f14830d [MPLUGIN-387] Bump xmlunit to 1.6 https://github.com/apache/maven-plugin-tools/commit/036fdebb5cdbab68d79550cc6a0991f2a96ce4c8;>036fdeb [MPLUGIN-387] Bump plexus-compiler-manager to 2.8.8 https://github.com/apache/maven-plugin-tools/commit/d296e04045026716f1fba5d296a0dd4330cc7f92;>d296e04 [MPLUGIN-387] Switch from fest-assert to AssertJ 2.9.1 https://github.com/apache/maven-plugin-tools/commit/9ff352cc5680fe4e672dd99d0ff9160fc51a1317;>9ff352c [MPLUGIN-387] Bump plexus-archiver to 4.2.5 https://github.com/apache/maven-plugin-tools/commit/f6461047666e7c2dc0103042088825fd6a16a8ab;>f646104 [MPLUGIN-387] Upgrade BeanShell to 2.0b6 https://github.com/apache/maven-plugin-tools/commit/db1803198a77a40917a533e70ece7f066b783bf1;>db18031 [MPLUGIN-387] Bump junit to 4.13.2 https://github.com/apache/maven-plugin-tools/commit/c7ae057613aab21957197f93d33d6c0e2eb55bf8;>c7ae057 Added Dependabot configuration https://github.com/apache/maven-plugin-tools/commit/86d870fbc4a3aa1cd3b8da8a2fde015e5e8dfe43;>86d870f [MPLUGIN-387] Upgrade Doxia/Doxia Tools to 1.11.1 Additional commits viewable in https://github.com/apache/maven-plugin-tools/compare/maven-plugin-tools-3.6.2...maven-plugin-tools-3.6.4;>compare view 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
