[ANNOUNCE] Apache Commons DBCP 2.12.0

[Gary Gregory]

The Apache Commons DBCP team is pleased to announce the release of
Apache Commons DBCP 2.12.0.

Apache Commons DBCP software implements Database Connection Pooling.

This is a minor release, including bug fixes and enhancements. Commons
DBCP requires Java 8 or above.

The list of changes is here:
https://commons.apache.org/proper/commons-dbcp/changes-report.html#a2.12.0

For complete information on Apache Commons DBCP, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Commons DBCP website:

https://commons.apache.org/proper/commons-dbcp/

Download page: https://commons.apache.org/proper/commons-dbcp/download_dbcp.cgi

Gary Gregory
Apache Commons Team

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons DBCP 2.12.0 based on RC1

[Gary Gregory]

This vote passes with the following four binding +1 votes from:

- Bruno Kinoshita
- Gary Gregory
- Phil Steitz
- Rob Tompkins

Thank you all for taking the time to review this release candidate.

Gary

On Sat, Mar 2, 2024 at 4:23 PM Rob Tompkins  wrote:
>
> +1 ran tests, site looks good, signatures look good.
>
> > On Feb 29, 2024, at 5:46 PM, Gary Gregory  wrote:
> >
> > Hi All,
> >
> > We have fixed a few bugs and added some enhancements since Apache
> > Commons DBCP 2.11.0 was released, so I would like to release Apache
> > Commons DBCP 2.12.0.
> >
> > Apache Commons DBCP 2.12.0 RC1 is available for review here:
> >https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1
> > (svn revision 67637)
> >
> > The Git tag commons-dbcp-2.12.0-RC1 commit for this RC is
> > 49270ef2445b775ed0a6673757d15185d859e6ac which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=49270ef2445b775ed0a6673757d15185d859e6ac
> > You may checkout this tag using:
> >git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
> > --branch commons-dbcp-2.12.0-RC1 commons-dbcp-2.12.0-RC1
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1693/org/apache/commons/commons-dbcp2/2.12.0/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Thu Feb 29 22:33:36 UTC 2024
> > Apache\ Commons\
> > DBCP-2.12.0.spdx.rdf.xml=2a949b0ab04a69ed12d826e29fdd22aa4d92fdccd6188974263364323a9a6ac99a099f851299f6237af5b272e042a28e41de71dbb11934b0d10b27a82cd2d31f
> > commons-dbcp2-2.12.0-bin.tar.gz=2202dbb7145e67ed4c99a4ac9a6716a4886110e4d219ac869c4d81bfe75981cf0535664e2d939b3db5ae3515338101dcc29e10aa7e69576155c42789b6ca966b
> > commons-dbcp2-2.12.0-bin.zip=d2141744d0a7ad48e456aa0a6254efb706b491f30c6fc0056e2029de9b21f97ac6265508f1513631347e9f72d2da2269815745a0967dc6f3a8d621cb0fb818ce
> > commons-dbcp2-2.12.0-bom.json=f128916347a2a72e8dd7705f54049041814e40765f75536c10ef18fa43ca1d7e5a77a74a74aa10f446927be35189f3d092edf6abc9436c616eddce293bfa590a
> > commons-dbcp2-2.12.0-bom.xml=3b4e2a3066085d3ea0ecb1e1c8106ed0b817a7939e85df7fd4d6d2cd386206f1d2a774e77998f25e1c39c577d784c02078d470f2b7998f8af175a22de3f7bc89
> > commons-dbcp2-2.12.0-javadoc.jar=dac615d144c5e72efb7a46862e4d82ca8726705600731be5e5573ab76061013cdcd9cd301d15e610e5403f223c955040fabdebaa24fe20a17f74cfde02f9
> > commons-dbcp2-2.12.0-sources.jar=a35d60fcc5835be64f93049823c17c65bd34ceb6fb4c444de122be5e2ea9039dd1df755ff7dd80c2a82a120a8e4dea1beb2d4f178efd8762e00b42e491c17bdb
> > commons-dbcp2-2.12.0-src.tar.gz=2e115574abd2e8582202dcd35c90b093d5a39c24a1bb7abc6930ec6f10c9eee1c90f00061adcf9e3249a175e4de4eb71374dbf94c81e39bf395dbb360749b01a
> > commons-dbcp2-2.12.0-src.zip=c2597d665fbc2bfc1adac2a7120295d3a1d72a6fd36d5c02de07cc6735bfb375abb920eba8b78b0d2d562e31207acb1d330cfc558c0769d6d0a0580c85cc796a
> > commons-dbcp2-2.12.0-test-sources.jar=2262f12da577c7458ef7e12c57ecea399be2837b6a0a675355859e78c337aa961e9a0f99225ad0d15e64ca25b321fb6aaea1aa4ec8e65350c9ace7eeb15eee22
> > commons-dbcp2-2.12.0-tests.jar=c1fbe0ef2655f32ec8c04ce853d5418176d16bf84f7af94193d8e37c465ef9e26c150e35c9ef0e35fdabfb366f9a49596212c01280f3524198323eaeb00980fe
> >
> > I have tested this with:
> >
> > mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site 
> > deploy
> >
> > using:
> >
> > openjdk version "21.0.2" 2024-01-16
> > OpenJDK Runtime Environment Homebrew (build 21.0.2)
> > OpenJDK 64-Bit Server VM Homebrew (build 21.0.2, mixed mode, sharing)
> >
> > Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> > Maven home: /usr/local/Cellar/maven/3.9.6/libexec
> > Java version: 21.0.2, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk/21.0.2/libexec/openjdk.jdk/Contents/Home
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac"
> >
> > Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
> > PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64
> >
> > Details of changes since 2.11.0 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/RELEASE-NOTES.txt
> >
> > https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/changes-report.html
> >
> > Site:
> >
> > https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/index.html
> >(note some *relative* links are broken and the 2.12.0 directories
&g

Re: [VOTE] Release Apache Commons DBCP 2.12.0 based on RC1

[Rob Tompkins]

+1 ran tests, site looks good, signatures look good.

> On Feb 29, 2024, at 5:46 PM, Gary Gregory  wrote:
> 
> Hi All,
> 
> We have fixed a few bugs and added some enhancements since Apache
> Commons DBCP 2.11.0 was released, so I would like to release Apache
> Commons DBCP 2.12.0.
> 
> Apache Commons DBCP 2.12.0 RC1 is available for review here:
>https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1
> (svn revision 67637)
> 
> The Git tag commons-dbcp-2.12.0-RC1 commit for this RC is
> 49270ef2445b775ed0a6673757d15185d859e6ac which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=49270ef2445b775ed0a6673757d15185d859e6ac
> You may checkout this tag using:
>git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
> --branch commons-dbcp-2.12.0-RC1 commons-dbcp-2.12.0-RC1
> 
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1693/org/apache/commons/commons-dbcp2/2.12.0/
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> #Thu Feb 29 22:33:36 UTC 2024
> Apache\ Commons\
> DBCP-2.12.0.spdx.rdf.xml=2a949b0ab04a69ed12d826e29fdd22aa4d92fdccd6188974263364323a9a6ac99a099f851299f6237af5b272e042a28e41de71dbb11934b0d10b27a82cd2d31f
> commons-dbcp2-2.12.0-bin.tar.gz=2202dbb7145e67ed4c99a4ac9a6716a4886110e4d219ac869c4d81bfe75981cf0535664e2d939b3db5ae3515338101dcc29e10aa7e69576155c42789b6ca966b
> commons-dbcp2-2.12.0-bin.zip=d2141744d0a7ad48e456aa0a6254efb706b491f30c6fc0056e2029de9b21f97ac6265508f1513631347e9f72d2da2269815745a0967dc6f3a8d621cb0fb818ce
> commons-dbcp2-2.12.0-bom.json=f128916347a2a72e8dd7705f54049041814e40765f75536c10ef18fa43ca1d7e5a77a74a74aa10f446927be35189f3d092edf6abc9436c616eddce293bfa590a
> commons-dbcp2-2.12.0-bom.xml=3b4e2a3066085d3ea0ecb1e1c8106ed0b817a7939e85df7fd4d6d2cd386206f1d2a774e77998f25e1c39c577d784c02078d470f2b7998f8af175a22de3f7bc89
> commons-dbcp2-2.12.0-javadoc.jar=dac615d144c5e72efb7a46862e4d82ca8726705600731be5e5573ab76061013cdcd9cd301d15e610e5403f223c955040fabdebaa24fe20a17f74cfde02f9
> commons-dbcp2-2.12.0-sources.jar=a35d60fcc5835be64f93049823c17c65bd34ceb6fb4c444de122be5e2ea9039dd1df755ff7dd80c2a82a120a8e4dea1beb2d4f178efd8762e00b42e491c17bdb
> commons-dbcp2-2.12.0-src.tar.gz=2e115574abd2e8582202dcd35c90b093d5a39c24a1bb7abc6930ec6f10c9eee1c90f00061adcf9e3249a175e4de4eb71374dbf94c81e39bf395dbb360749b01a
> commons-dbcp2-2.12.0-src.zip=c2597d665fbc2bfc1adac2a7120295d3a1d72a6fd36d5c02de07cc6735bfb375abb920eba8b78b0d2d562e31207acb1d330cfc558c0769d6d0a0580c85cc796a
> commons-dbcp2-2.12.0-test-sources.jar=2262f12da577c7458ef7e12c57ecea399be2837b6a0a675355859e78c337aa961e9a0f99225ad0d15e64ca25b321fb6aaea1aa4ec8e65350c9ace7eeb15eee22
> commons-dbcp2-2.12.0-tests.jar=c1fbe0ef2655f32ec8c04ce853d5418176d16bf84f7af94193d8e37c465ef9e26c150e35c9ef0e35fdabfb366f9a49596212c01280f3524198323eaeb00980fe
> 
> I have tested this with:
> 
> mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy
> 
> using:
> 
> openjdk version "21.0.2" 2024-01-16
> OpenJDK Runtime Environment Homebrew (build 21.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 21.0.2, mixed mode, sharing)
> 
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: /usr/local/Cellar/maven/3.9.6/libexec
> Java version: 21.0.2, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk/21.0.2/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac"
> 
> Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
> PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64
> 
> Details of changes since 2.11.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/changes-report.html
> 
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/index.html
>(note some *relative* links are broken and the 2.12.0 directories
> are not yet created - these will be OK once the site is deployed.)
> 
> JApiCmp Report (compared to 2.11.0):
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/japicmp.html
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/rat-report.html
> 
> KEYS:
>  https://downloads.apache.org/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
> 
>  [ ] +1 Release these artifacts
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  

Re: [VOTE] Release Apache Commons DBCP 2.12.0 based on RC1

[Phil Steitz]

+1

Checked build, tests, built jar, reports, release notes.  All look good.
Checked build on
Maven 3.9.3
openjdk version "17.0.10" 2024-01-16
OpenJDK Runtime Environment (build 17.0.10+7-Ubuntu-120.04.1)

Phil

On Thu, Feb 29, 2024 at 3:48 PM Gary Gregory  wrote:

> Hi All,
>
> We have fixed a few bugs and added some enhancements since Apache
> Commons DBCP 2.11.0 was released, so I would like to release Apache
> Commons DBCP 2.12.0.
>
> Apache Commons DBCP 2.12.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1
> (svn revision 67637)
>
> The Git tag commons-dbcp-2.12.0-RC1 commit for this RC is
> 49270ef2445b775ed0a6673757d15185d859e6ac which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=49270ef2445b775ed0a6673757d15185d859e6ac
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
> --branch <https://gitbox.apache.org/repos/asf/commons-dbcp.git--branch>
> commons-dbcp-2.12.0-RC1 commons-dbcp-2.12.0-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1693/org/apache/commons/commons-dbcp2/2.12.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Thu Feb 29 22:33:36 UTC 2024
> Apache\ Commons\
>
> DBCP-2.12.0.spdx.rdf.xml=2a949b0ab04a69ed12d826e29fdd22aa4d92fdccd6188974263364323a9a6ac99a099f851299f6237af5b272e042a28e41de71dbb11934b0d10b27a82cd2d31f
>
> commons-dbcp2-2.12.0-bin.tar.gz=2202dbb7145e67ed4c99a4ac9a6716a4886110e4d219ac869c4d81bfe75981cf0535664e2d939b3db5ae3515338101dcc29e10aa7e69576155c42789b6ca966b
>
> commons-dbcp2-2.12.0-bin.zip=d2141744d0a7ad48e456aa0a6254efb706b491f30c6fc0056e2029de9b21f97ac6265508f1513631347e9f72d2da2269815745a0967dc6f3a8d621cb0fb818ce
>
> commons-dbcp2-2.12.0-bom.json=f128916347a2a72e8dd7705f54049041814e40765f75536c10ef18fa43ca1d7e5a77a74a74aa10f446927be35189f3d092edf6abc9436c616eddce293bfa590a
>
> commons-dbcp2-2.12.0-bom.xml=3b4e2a3066085d3ea0ecb1e1c8106ed0b817a7939e85df7fd4d6d2cd386206f1d2a774e77998f25e1c39c577d784c02078d470f2b7998f8af175a22de3f7bc89
>
> commons-dbcp2-2.12.0-javadoc.jar=dac615d144c5e72efb7a46862e4d82ca8726705600731be5e5573ab76061013cdcd9cd301d15e610e5403f223c955040fabdebaa24fe20a17f74cfde02f9
>
> commons-dbcp2-2.12.0-sources.jar=a35d60fcc5835be64f93049823c17c65bd34ceb6fb4c444de122be5e2ea9039dd1df755ff7dd80c2a82a120a8e4dea1beb2d4f178efd8762e00b42e491c17bdb
>
> commons-dbcp2-2.12.0-src.tar.gz=2e115574abd2e8582202dcd35c90b093d5a39c24a1bb7abc6930ec6f10c9eee1c90f00061adcf9e3249a175e4de4eb71374dbf94c81e39bf395dbb360749b01a
>
> commons-dbcp2-2.12.0-src.zip=c2597d665fbc2bfc1adac2a7120295d3a1d72a6fd36d5c02de07cc6735bfb375abb920eba8b78b0d2d562e31207acb1d330cfc558c0769d6d0a0580c85cc796a
>
> commons-dbcp2-2.12.0-test-sources.jar=2262f12da577c7458ef7e12c57ecea399be2837b6a0a675355859e78c337aa961e9a0f99225ad0d15e64ca25b321fb6aaea1aa4ec8e65350c9ace7eeb15eee22
>
> commons-dbcp2-2.12.0-tests.jar=c1fbe0ef2655f32ec8c04ce853d5418176d16bf84f7af94193d8e37c465ef9e26c150e35c9ef0e35fdabfb366f9a49596212c01280f3524198323eaeb00980fe
>
> I have tested this with:
>
> mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site
> deploy
>
> using:
>
> openjdk version "21.0.2" 2024-01-16
> OpenJDK Runtime Environment Homebrew (build 21.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 21.0.2, mixed mode, sharing)
>
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: /usr/local/Cellar/maven/3.9.6/libexec
> Java version: 21.0.2, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk/21.0.2/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac"
>
> Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
> PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64
>
> Details of changes since 2.11.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/index.html
> (note some *relative* links are broken and the 2.12.0 directories
> are not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 2.11.0):
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/japicmp.html
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/rat-report.html
>
> KEYS:
>   https://

Re: [VOTE] Release Apache Commons DBCP 2.12.0 based on RC1

[Gary Gregory]

My +1

Gary

On Thu, Feb 29, 2024 at 5:46 PM Gary Gregory  wrote:
>
> Hi All,
>
> We have fixed a few bugs and added some enhancements since Apache
> Commons DBCP 2.11.0 was released, so I would like to release Apache
> Commons DBCP 2.12.0.
>
> Apache Commons DBCP 2.12.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1
> (svn revision 67637)
>
> The Git tag commons-dbcp-2.12.0-RC1 commit for this RC is
> 49270ef2445b775ed0a6673757d15185d859e6ac which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=49270ef2445b775ed0a6673757d15185d859e6ac
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
> --branch commons-dbcp-2.12.0-RC1 commons-dbcp-2.12.0-RC1
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1693/org/apache/commons/commons-dbcp2/2.12.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Thu Feb 29 22:33:36 UTC 2024
> Apache\ Commons\
> DBCP-2.12.0.spdx.rdf.xml=2a949b0ab04a69ed12d826e29fdd22aa4d92fdccd6188974263364323a9a6ac99a099f851299f6237af5b272e042a28e41de71dbb11934b0d10b27a82cd2d31f
> commons-dbcp2-2.12.0-bin.tar.gz=2202dbb7145e67ed4c99a4ac9a6716a4886110e4d219ac869c4d81bfe75981cf0535664e2d939b3db5ae3515338101dcc29e10aa7e69576155c42789b6ca966b
> commons-dbcp2-2.12.0-bin.zip=d2141744d0a7ad48e456aa0a6254efb706b491f30c6fc0056e2029de9b21f97ac6265508f1513631347e9f72d2da2269815745a0967dc6f3a8d621cb0fb818ce
> commons-dbcp2-2.12.0-bom.json=f128916347a2a72e8dd7705f54049041814e40765f75536c10ef18fa43ca1d7e5a77a74a74aa10f446927be35189f3d092edf6abc9436c616eddce293bfa590a
> commons-dbcp2-2.12.0-bom.xml=3b4e2a3066085d3ea0ecb1e1c8106ed0b817a7939e85df7fd4d6d2cd386206f1d2a774e77998f25e1c39c577d784c02078d470f2b7998f8af175a22de3f7bc89
> commons-dbcp2-2.12.0-javadoc.jar=dac615d144c5e72efb7a46862e4d82ca8726705600731be5e5573ab76061013cdcd9cd301d15e610e5403f223c955040fabdebaa24fe20a17f74cfde02f9
> commons-dbcp2-2.12.0-sources.jar=a35d60fcc5835be64f93049823c17c65bd34ceb6fb4c444de122be5e2ea9039dd1df755ff7dd80c2a82a120a8e4dea1beb2d4f178efd8762e00b42e491c17bdb
> commons-dbcp2-2.12.0-src.tar.gz=2e115574abd2e8582202dcd35c90b093d5a39c24a1bb7abc6930ec6f10c9eee1c90f00061adcf9e3249a175e4de4eb71374dbf94c81e39bf395dbb360749b01a
> commons-dbcp2-2.12.0-src.zip=c2597d665fbc2bfc1adac2a7120295d3a1d72a6fd36d5c02de07cc6735bfb375abb920eba8b78b0d2d562e31207acb1d330cfc558c0769d6d0a0580c85cc796a
> commons-dbcp2-2.12.0-test-sources.jar=2262f12da577c7458ef7e12c57ecea399be2837b6a0a675355859e78c337aa961e9a0f99225ad0d15e64ca25b321fb6aaea1aa4ec8e65350c9ace7eeb15eee22
> commons-dbcp2-2.12.0-tests.jar=c1fbe0ef2655f32ec8c04ce853d5418176d16bf84f7af94193d8e37c465ef9e26c150e35c9ef0e35fdabfb366f9a49596212c01280f3524198323eaeb00980fe
>
> I have tested this with:
>
> mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy
>
> using:
>
> openjdk version "21.0.2" 2024-01-16
> OpenJDK Runtime Environment Homebrew (build 21.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 21.0.2, mixed mode, sharing)
>
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: /usr/local/Cellar/maven/3.9.6/libexec
> Java version: 21.0.2, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk/21.0.2/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac"
>
> Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
> PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64
>
> Details of changes since 2.11.0 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/changes-report.html
>
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/index.html
> (note some *relative* links are broken and the 2.12.0 directories
> are not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 2.11.0):
> 
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/japicmp.html
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/rat-report.html
>
> KEYS:
>   https://downloads.apache.org/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
&g

Re: [VOTE] Release Apache Commons DBCP 2.12.0 based on RC1

[Bruno Kinoshita]

+1

Building fine on

Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
Maven home: /opt/apache-maven-3.8.5
Java version: 17.0.10, vendor: Private Build, runtime:
/usr/lib/jvm/java-17-openjdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.15.0-97-generic", arch: "amd64", family:
"unix"

Release notes OK, dist area archive sigs OK, site reports OK.

Thanks!

On Thu, 29 Feb 2024 at 23:48, Gary Gregory  wrote:

> Hi All,
>
> We have fixed a few bugs and added some enhancements since Apache
> Commons DBCP 2.11.0 was released, so I would like to release Apache
> Commons DBCP 2.12.0.
>
> Apache Commons DBCP 2.12.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1
> (svn revision 67637)
>
> The Git tag commons-dbcp-2.12.0-RC1 commit for this RC is
> 49270ef2445b775ed0a6673757d15185d859e6ac which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=49270ef2445b775ed0a6673757d15185d859e6ac
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
> --branch <https://gitbox.apache.org/repos/asf/commons-dbcp.git--branch>
> commons-dbcp-2.12.0-RC1 commons-dbcp-2.12.0-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1693/org/apache/commons/commons-dbcp2/2.12.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Thu Feb 29 22:33:36 UTC 2024
> Apache\ Commons\
>
> DBCP-2.12.0.spdx.rdf.xml=2a949b0ab04a69ed12d826e29fdd22aa4d92fdccd6188974263364323a9a6ac99a099f851299f6237af5b272e042a28e41de71dbb11934b0d10b27a82cd2d31f
>
> commons-dbcp2-2.12.0-bin.tar.gz=2202dbb7145e67ed4c99a4ac9a6716a4886110e4d219ac869c4d81bfe75981cf0535664e2d939b3db5ae3515338101dcc29e10aa7e69576155c42789b6ca966b
>
> commons-dbcp2-2.12.0-bin.zip=d2141744d0a7ad48e456aa0a6254efb706b491f30c6fc0056e2029de9b21f97ac6265508f1513631347e9f72d2da2269815745a0967dc6f3a8d621cb0fb818ce
>
> commons-dbcp2-2.12.0-bom.json=f128916347a2a72e8dd7705f54049041814e40765f75536c10ef18fa43ca1d7e5a77a74a74aa10f446927be35189f3d092edf6abc9436c616eddce293bfa590a
>
> commons-dbcp2-2.12.0-bom.xml=3b4e2a3066085d3ea0ecb1e1c8106ed0b817a7939e85df7fd4d6d2cd386206f1d2a774e77998f25e1c39c577d784c02078d470f2b7998f8af175a22de3f7bc89
>
> commons-dbcp2-2.12.0-javadoc.jar=dac615d144c5e72efb7a46862e4d82ca8726705600731be5e5573ab76061013cdcd9cd301d15e610e5403f223c955040fabdebaa24fe20a17f74cfde02f9
>
> commons-dbcp2-2.12.0-sources.jar=a35d60fcc5835be64f93049823c17c65bd34ceb6fb4c444de122be5e2ea9039dd1df755ff7dd80c2a82a120a8e4dea1beb2d4f178efd8762e00b42e491c17bdb
>
> commons-dbcp2-2.12.0-src.tar.gz=2e115574abd2e8582202dcd35c90b093d5a39c24a1bb7abc6930ec6f10c9eee1c90f00061adcf9e3249a175e4de4eb71374dbf94c81e39bf395dbb360749b01a
>
> commons-dbcp2-2.12.0-src.zip=c2597d665fbc2bfc1adac2a7120295d3a1d72a6fd36d5c02de07cc6735bfb375abb920eba8b78b0d2d562e31207acb1d330cfc558c0769d6d0a0580c85cc796a
>
> commons-dbcp2-2.12.0-test-sources.jar=2262f12da577c7458ef7e12c57ecea399be2837b6a0a675355859e78c337aa961e9a0f99225ad0d15e64ca25b321fb6aaea1aa4ec8e65350c9ace7eeb15eee22
>
> commons-dbcp2-2.12.0-tests.jar=c1fbe0ef2655f32ec8c04ce853d5418176d16bf84f7af94193d8e37c465ef9e26c150e35c9ef0e35fdabfb366f9a49596212c01280f3524198323eaeb00980fe
>
> I have tested this with:
>
> mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site
> deploy
>
> using:
>
> openjdk version "21.0.2" 2024-01-16
> OpenJDK Runtime Environment Homebrew (build 21.0.2)
> OpenJDK 64-Bit Server VM Homebrew (build 21.0.2, mixed mode, sharing)
>
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: /usr/local/Cellar/maven/3.9.6/libexec
> Java version: 21.0.2, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk/21.0.2/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac"
>
> Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
> PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64
>
> Details of changes since 2.11.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/index.html
> (note some *relative* links are broken and the 2.12.0 directories
> are not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 2.11.0):
>
> https://d

[VOTE] Release Apache Commons DBCP 2.12.0 based on RC1

[Gary Gregory]

Hi All,

We have fixed a few bugs and added some enhancements since Apache
Commons DBCP 2.11.0 was released, so I would like to release Apache
Commons DBCP 2.12.0.

Apache Commons DBCP 2.12.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1
(svn revision 67637)

The Git tag commons-dbcp-2.12.0-RC1 commit for this RC is
49270ef2445b775ed0a6673757d15185d859e6ac which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=49270ef2445b775ed0a6673757d15185d859e6ac
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
--branch commons-dbcp-2.12.0-RC1 commons-dbcp-2.12.0-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1693/org/apache/commons/commons-dbcp2/2.12.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Thu Feb 29 22:33:36 UTC 2024
Apache\ Commons\
DBCP-2.12.0.spdx.rdf.xml=2a949b0ab04a69ed12d826e29fdd22aa4d92fdccd6188974263364323a9a6ac99a099f851299f6237af5b272e042a28e41de71dbb11934b0d10b27a82cd2d31f
commons-dbcp2-2.12.0-bin.tar.gz=2202dbb7145e67ed4c99a4ac9a6716a4886110e4d219ac869c4d81bfe75981cf0535664e2d939b3db5ae3515338101dcc29e10aa7e69576155c42789b6ca966b
commons-dbcp2-2.12.0-bin.zip=d2141744d0a7ad48e456aa0a6254efb706b491f30c6fc0056e2029de9b21f97ac6265508f1513631347e9f72d2da2269815745a0967dc6f3a8d621cb0fb818ce
commons-dbcp2-2.12.0-bom.json=f128916347a2a72e8dd7705f54049041814e40765f75536c10ef18fa43ca1d7e5a77a74a74aa10f446927be35189f3d092edf6abc9436c616eddce293bfa590a
commons-dbcp2-2.12.0-bom.xml=3b4e2a3066085d3ea0ecb1e1c8106ed0b817a7939e85df7fd4d6d2cd386206f1d2a774e77998f25e1c39c577d784c02078d470f2b7998f8af175a22de3f7bc89
commons-dbcp2-2.12.0-javadoc.jar=dac615d144c5e72efb7a46862e4d82ca8726705600731be5e5573ab76061013cdcd9cd301d15e610e5403f223c955040fabdebaa24fe20a17f74cfde02f9
commons-dbcp2-2.12.0-sources.jar=a35d60fcc5835be64f93049823c17c65bd34ceb6fb4c444de122be5e2ea9039dd1df755ff7dd80c2a82a120a8e4dea1beb2d4f178efd8762e00b42e491c17bdb
commons-dbcp2-2.12.0-src.tar.gz=2e115574abd2e8582202dcd35c90b093d5a39c24a1bb7abc6930ec6f10c9eee1c90f00061adcf9e3249a175e4de4eb71374dbf94c81e39bf395dbb360749b01a
commons-dbcp2-2.12.0-src.zip=c2597d665fbc2bfc1adac2a7120295d3a1d72a6fd36d5c02de07cc6735bfb375abb920eba8b78b0d2d562e31207acb1d330cfc558c0769d6d0a0580c85cc796a
commons-dbcp2-2.12.0-test-sources.jar=2262f12da577c7458ef7e12c57ecea399be2837b6a0a675355859e78c337aa961e9a0f99225ad0d15e64ca25b321fb6aaea1aa4ec8e65350c9ace7eeb15eee22
commons-dbcp2-2.12.0-tests.jar=c1fbe0ef2655f32ec8c04ce853d5418176d16bf84f7af94193d8e37c465ef9e26c150e35c9ef0e35fdabfb366f9a49596212c01280f3524198323eaeb00980fe

I have tested this with:

mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy

using:

openjdk version "21.0.2" 2024-01-16
OpenJDK Runtime Environment Homebrew (build 21.0.2)
OpenJDK 64-Bit Server VM Homebrew (build 21.0.2, mixed mode, sharing)

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /usr/local/Cellar/maven/3.9.6/libexec
Java version: 21.0.2, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk/21.0.2/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac"

Darwin  23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58
PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64

Details of changes since 2.11.0 are in the release notes:
    
https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/RELEASE-NOTES.txt
    
https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/changes-report.html

Site:
    
https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/index.html
(note some *relative* links are broken and the 2.12.0 directories
are not yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 2.11.0):
    
https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/japicmp.html
RAT Report:
    
https://dist.apache.org/repos/dist/dev/commons/dbcp/2.12.0-RC1/site/rat-report.html

KEYS:
  https://downloads.apache.org/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Gary Gregory,
Release Manager (using key 86fdc7e2a11262cb)

For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1a) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
--branch commons-dbcp-2.12.0-RC1 commons-dbcp-2

Re: [dbcp] Force close connections on fatal SQL Exceptions

[Phil Steitz]

On Tue, Feb 13, 2024 at 1:03 PM Bernd Eckenfels 
wrote:

> Phil Steitz wrote on 13. Feb 2024 20:46 (GMT +01:00):
> > Thanks, Gary.  I agree with everything below.  I think it's best to just
> > leave things as they are.
>
> If it’s plugable the project might not have to care,
> But then how to fix the reported problem? Do we have an idea what’s
> causing it?
>

At this point, my best guess is that the app is not closing connections on
some exception paths.  Given that force-killing connections that will get
killed anyway on return improves the situation supports that idea, but I
have not dug into the application code.

>
> And a extension to that, using a conn3crion pool you expect it abstracts
> and handles all
> Those idiosyncrasies of different drivers, platforms and JDBC
> interpretations. Just giving
> Up is not the best option.
>

We decided years ago that we were not going to try to add special code for
every driver and I think that is a good decision.  The code is already
plenty complex.  I think the solution implemented now to fast fail
validation in this case is sufficient.  I don't think waiting to close
until the connection is returned is actually causing the reported problem.

>
> In my experience with a properitary (but very robust pool since it handles
> a small number of drivers)
> throwing away connections on concrete suspicion turned out to be helpful.
> Either by configurable state, substrings of error messages or actual
> sqlexception subtypes.
>
> But maybe additional validation is also fine as long as it uses strict
> timeouts, some control for paralysis and starvation. If I understand this
> would happen in the mentioned problem case, so is there a timeout missing.
>
> Having said that as a tip to OP use tcpkeepalive and lower the timeouts.
> It saved my ass more than once, especially with VIPs in place.
>

The liveness problem is a [pool] concern, per my recent post.  I think
getting support in [pool] for managing transient factory outages would
really help.  Any ideas that you have on how to do that would be much
appreciated.

Phil

>
> Gruss
> Bernd
> —
> https://bernd.eckenfels.net
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [dbcp] Force close connections on fatal SQL Exceptions

[Bernd Eckenfels]

Phil Steitz wrote on 13. Feb 2024 20:46 (GMT +01:00):
> Thanks, Gary.  I agree with everything below.  I think it's best to just
> leave things as they are.

If it’s plugable the project might not have to care, 
But then how to fix the reported problem? Do we have an idea what’s causing it?

And a extension to that, using a conn3crion pool you expect it abstracts and 
handles all
Those idiosyncrasies of different drivers, platforms and JDBC interpretations. 
Just giving 
Up is not the best option.

In my experience with a properitary (but very robust pool since it handles a 
small number of drivers)
throwing away connections on concrete suspicion turned out to be helpful.
Either by configurable state, substrings of error messages or actual 
sqlexception subtypes.

But maybe additional validation is also fine as long as it uses strict 
timeouts, some control for paralysis and starvation. If I understand this would 
happen in the mentioned problem case, so is there a timeout missing.

Having said that as a tip to OP use tcpkeepalive and lower the timeouts. It 
saved my ass more than once, especially with VIPs in place.

Gruss
Bernd
— 
https://bernd.eckenfels.net

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [dbcp] Force close connections on fatal SQL Exceptions

[Phil Steitz]

Thanks, Gary.  I agree with everything below.  I think it's best to just
leave things as they are.

Phil

On Mon, Feb 12, 2024 at 7:25 PM Gary Gregory  wrote:

> I've used many JDBC drivers from different vendors, FOSS and
> proprietary, and if I've learned one thing, it is that each is its own
> world within the universe of the DBMS it operates in.
>
> It is impossible to write a generic tool; they all end up providing
> plugins for DB-specific features, sure, but those plugins invariably
> also account for behavioral differences between drivers.
>
> You can't even rely on all JDBC APIs to be implemented that one would
> imagine should be "core" to the functionality.  I've seen such APIs
> just stubbed to throw exceptions. This is especially common for
> metadata-related APIs.
>
> Relying on SQL states is pretty hopeless IMO. I've had to allow custom
> configs in apps to try and figure out the driver and connection state
> from exception class names and exception message contents because you
> can't rely on SQL states, and if you do then you realize that
> different drivers use different states in similar contexts, so then
> you allow for customization of _that_ too, bleh.
>
> All of this is to say that it feels dangerous to remove any hook we
> provide.
>
> I just can't see a reliable way to detect a broken Connection unless
> it's a detectable network breakage (if a socket or IO exception is the
> root cause).
>
> The bottom line is that connections are really expensive to create,
> and should only be thrown away if you know for sure it's gone bad. I'd
> never want to throw away a connection that is fine from the server POV
> but the driver throws exception X because for whatever reason, is
> reusable, but we throw it away.
>
> HTH,
> Gary
>
> On Mon, Feb 12, 2024 at 2:42 PM Phil Steitz  wrote:
> >
> > In DBCP-595, a change is suggested to force close connections when a
> fatal
> > SQL exception has occurred.  As of Version 2.2 of DBCP, fatal exceptions
> > are tracked and the fastFailValidation property can be set to fast fail
> > validations when a fatal exception has occurred on a connection.  This
> > change would obsolete that property, as it would make the pool close the
> > connection immediately.
> >
> > I see two pros for this change and one con.
> >
> > Pros:
> > 0) Bad connection is destroyed immediately
> > 1) Works when validation is turned off
> >
> > Con:
> > Incorrect SQL states returned by drivers or transient failures may cause
> > over-zealous purging of connections.
> >
> > I vaguely recall the "Con" as the reason why we implemented
> > fastFailValidation instead of direct close on these failures, but I can't
> > find the discussion in the archives.
> >
> > Phil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [dbcp] Force close connections on fatal SQL Exceptions

[Gary Gregory]

I've used many JDBC drivers from different vendors, FOSS and
proprietary, and if I've learned one thing, it is that each is its own
world within the universe of the DBMS it operates in.

It is impossible to write a generic tool; they all end up providing
plugins for DB-specific features, sure, but those plugins invariably
also account for behavioral differences between drivers.

You can't even rely on all JDBC APIs to be implemented that one would
imagine should be "core" to the functionality.  I've seen such APIs
just stubbed to throw exceptions. This is especially common for
metadata-related APIs.

Relying on SQL states is pretty hopeless IMO. I've had to allow custom
configs in apps to try and figure out the driver and connection state
from exception class names and exception message contents because you
can't rely on SQL states, and if you do then you realize that
different drivers use different states in similar contexts, so then
you allow for customization of _that_ too, bleh.

All of this is to say that it feels dangerous to remove any hook we provide.

I just can't see a reliable way to detect a broken Connection unless
it's a detectable network breakage (if a socket or IO exception is the
root cause).

The bottom line is that connections are really expensive to create,
and should only be thrown away if you know for sure it's gone bad. I'd
never want to throw away a connection that is fine from the server POV
but the driver throws exception X because for whatever reason, is
reusable, but we throw it away.

HTH,
Gary

On Mon, Feb 12, 2024 at 2:42 PM Phil Steitz  wrote:
>
> In DBCP-595, a change is suggested to force close connections when a fatal
> SQL exception has occurred.  As of Version 2.2 of DBCP, fatal exceptions
> are tracked and the fastFailValidation property can be set to fast fail
> validations when a fatal exception has occurred on a connection.  This
> change would obsolete that property, as it would make the pool close the
> connection immediately.
>
> I see two pros for this change and one con.
>
> Pros:
> 0) Bad connection is destroyed immediately
> 1) Works when validation is turned off
>
> Con:
> Incorrect SQL states returned by drivers or transient failures may cause
> over-zealous purging of connections.
>
> I vaguely recall the "Con" as the reason why we implemented
> fastFailValidation instead of direct close on these failures, but I can't
> find the discussion in the archives.
>
> Phil

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DBCP] Support request boundaries

[Phil Steitz]

On Tue, Jan 23, 2024 at 11:35 AM Phil Steitz  wrote:

> To make it easier to follow and find later, let's move the discussion
> started in [1], [2] here.
>
> The request made in the Jira [1] and implemented in the PR [2]  to send
> beginRequest and endRequest messages to drivers seems reasonable to me, but
> just implementing unilaterally by default is probably not the best thing to
> do.
>
> Summarizing discussion so far (Gary, Bernd, meedbak, pls fix any errors):
>
> 0) The spec is vague and drivers seem to do different kinds of things or
> make different kinds of assumptions based on these messages.  There are
> some references in
> [2] .
>
> 1) There is potential to reduce the activate/passivate overhead when we
> can safely rely on these messages to maintain connection attributes.
>
> 2) It's not obvious when we should be send the messages.  Borrow and
> return are kind of obvious, but what about when a connection is idle but
> under maintenance?  Might be better to put the calls in
> PoolableConnectionFactory's activate/passivate.
>
> 3) This raises the adjacent concern that it might be good to allow PCF
> activate/passivate to be pluggable.
>
> 4) The spec has been around since 2017, but behaviors do not appear to
> have been standardized.  Making sure that what we do is safe for all
> implementations may be tricky.
>
> Based on above, the following options seem reasonable and not too
> difficult to me.
>
> a) do nothing
> b) add a configuration property that makes dbcp send the messages on
> activate/passivate or borrow/return (need to decide which)
>

After more research and listening to comments, I think this is the best
approach, with beginRequest sent on PCF activate and endRequest sent on PCF
passivate.  Using activate/passivate instead of getConnection and close on
the datasources enables us to make a single change and also prevents
conflicts with pool maintenance (testWhileIdle).

I would be happy to review a PR with tests for this if there are no
objections.

Phil


> c) add another configuration property that tells PCF to let the driver
> manage connection properties, so when used with b, fewer calls might be
> needed to manage connection properties.
>
> Options b) and c) would have to consider potential conflicts with current
> properties cacheState, enableAutoCommitOnReturn and rollbackOnReturn.
>
> Phil
>
> [1] https://issues.apache.org/jira/browse/DBCP-592
> [2] https://github.com/apache/commons-dbcp/pull/324
>
>
>
>
>

[dbcp] Force close connections on fatal SQL Exceptions

[Phil Steitz]

In DBCP-595, a change is suggested to force close connections when a fatal
SQL exception has occurred.  As of Version 2.2 of DBCP, fatal exceptions
are tracked and the fastFailValidation property can be set to fast fail
validations when a fatal exception has occurred on a connection.  This
change would obsolete that property, as it would make the pool close the
connection immediately.

I see two pros for this change and one con.

Pros:
0) Bad connection is destroyed immediately
1) Works when validation is turned off

Con:
Incorrect SQL states returned by drivers or transient failures may cause
over-zealous purging of connections.

I vaguely recall the "Con" as the reason why we implemented
fastFailValidation instead of direct close on these failures, but I can't
find the discussion in the archives.

Phil

[DBCP] Support request boundaries

[Phil Steitz]

To make it easier to follow and find later, let's move the discussion
started in [1], [2] here.

The request made in the Jira [1] and implemented in the PR [2]  to send
beginRequest and endRequest messages to drivers seems reasonable to me, but
just implementing unilaterally by default is probably not the best thing to
do.

Summarizing discussion so far (Gary, Bernd, meedbak, pls fix any errors):

0) The spec is vague and drivers seem to do different kinds of things or
make different kinds of assumptions based on these messages.  There are
some references in
[2] .

1) There is potential to reduce the activate/passivate overhead when we can
safely rely on these messages to maintain connection attributes.

2) It's not obvious when we should be send the messages.  Borrow and return
are kind of obvious, but what about when a connection is idle but under
maintenance?  Might be better to put the calls in
PoolableConnectionFactory's activate/passivate.

3) This raises the adjacent concern that it might be good to allow PCF
activate/passivate to be pluggable.

4) The spec has been around since 2017, but behaviors do not appear to have
been standardized.  Making sure that what we do is safe for all
implementations may be tricky.

Based on above, the following options seem reasonable and not too difficult
to me.

a) do nothing
b) add a configuration property that makes dbcp send the messages on
activate/passivate or borrow/return (need to decide which)
c) add another configuration property that tells PCF to let the driver
manage connection properties, so when used with b, fewer calls might be
needed to manage connection properties.

Options b) and c) would have to consider potential conflicts with current
properties cacheState, enableAutoCommitOnReturn and rollbackOnReturn.

Phil

[1] https://issues.apache.org/jira/browse/DBCP-592
[2] https://github.com/apache/commons-dbcp/pull/324

[RESULT][VOTE] Release Apache Commons DBCP 2.11.0 based on RC1

[Gary Gregory]

This vote thread passes with the following binding +1 votes:

- Bruno Kinoshita
- Gary Gregory
- Rob Tompkins

Gary


On Sat, Oct 28, 2023 at 7:42 AM Rob Tompkins  wrote:
>
> +1
>
> > On Oct 27, 2023, at 11:13 AM, Gary Gregory  wrote:
> >
> > My +1
> >
> > Gary
> >
> >> On Wed, Oct 25, 2023 at 6:26 AM Bruno Kinoshita  
> >> wrote:
> >>
> >>   [x] +1 Release these artifacts
> >>
> >> Site reports OK, building fine on
> >>
> >> Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> >> Maven home: /opt/apache-maven-3.8.5
> >> Java version: 17.0.8.1, vendor: Private Build, runtime:
> >> /usr/lib/jvm/java-17-openjdk-amd64
> >> Default locale: en_US, platform encoding: UTF-8
> >> OS name: "linux", version: "5.15.0-87-generic", arch: "amd64", family:
> >> "unix"
> >>
> >>> On Mon, 23 Oct 2023 at 19:55, Gary Gregory  wrote:
> >>>
> >>> We have fixed a few bugs and added some enhancements since Apache
> >>> Commons DBCP 2.9.0 was released, so I would like to release Apache
> >>> Commons DBCP 2.11.0.
> >>>
> >>> Apache Commons DBCP 2.11.0 RC1 is available for review here:
> >>>https://dist.apache.org/repos/dist/dev/commons/dbcp/2.11.0-RC1
> >>> (svn revision 64680)
> >>>
> >>> The Git tag commons-dbcp-2.11.0-RC1 commit for this RC is
> >>> e57ce3cf019ffa9534b88735c454c54afbe9849f which you can browse here:
> >>>
> >>> https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=e57ce3cf019ffa9534b88735c454c54afbe9849f
> >>> You may checkout this tag using:
> >>>git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
> >>> --branch <https://gitbox.apache.org/repos/asf/commons-dbcp.git--branch>
> >>> commons-dbcp-2.11.0-RC1 commons-dbcp-2.11.0-RC1
> >>>
> >>> Maven artifacts are here:
> >>>
> >>> https://repository.apache.org/content/repositories/orgapachecommons-1668/org/apache/commons/commons-dbcp2/2.11.0/
> >>>
> >>> These are the artifacts and their hashes:
> >>>
> >>> #Release SHA-512s
> >>> #Mon Oct 23 13:37:23 EDT 2023
> >>> Apache\ Commons\
> >>>
> >>> DBCP-2.11.0.spdx.rdf.xml=3d02a79fc5cfcb453195efe4a045f7b37ded7ba0fb0eadb301f7800e86019e3d7d9824e47f3db04ce530936cb770ad0c39cff2801070d9171c862085a79416c3
> >>>
> >>> commons-dbcp2-2.11.0-bin.tar.gz=34432889d6d973c6ff662c1189713fb48fdb431433a969b11186501fab338b6fe1ec3c402454dfebb7a16f8fb5e8e7c67633868a1a796faafb322d7a8215a527
> >>>
> >>> commons-dbcp2-2.11.0-bin.zip=b82e9e8e2c9df52424e59a0fbb2b1bd1cacd9f37686a237392d0801ab4bf69c7d0fe8b886442cc1a0613e04bb96039bf77e093bb0cd861d809ba9761d3a74359
> >>>
> >>> commons-dbcp2-2.11.0-bom.json=2c338fc5cea7e3210c4c489316b30c4313ae20139593b29e5d3970b01f17e094f2880e13230c83ac02373b8b8e30c162835bbcf85502084eab40f87b94bf4560
> >>>
> >>> commons-dbcp2-2.11.0-bom.xml=93a1d28bfa6e2f3d99452be23e02aae107b32a9cf7bdd5547c76f3bcb93a7f536a7a2f71231975e794e096c335618e14c43c52e53fd34bc12c626d10e6efb72b
> >>>
> >>> commons-dbcp2-2.11.0-javadoc.jar=bb4235fb91a74934ef408439019091a2f9938d3297fa932aa58f104532aab02911be77a674c945ea62b1d7dc1713466c375bedd87d0395db44f3a9aa3cf47870
> >>>
> >>> commons-dbcp2-2.11.0-sources.jar=a4f5f86a281853191a526d53dc05551cb7a72a83078d521c6e7a06e92a607db3a7627af4d819d90bbc168c20228f4e2e55a1763c77a4c7e085171964b692810b
> >>>
> >>> commons-dbcp2-2.11.0-src.tar.gz=2f73c4637a098925f7cf56fc49ee390a471f1f3faa50e8ee1595c762644437ea85683fa1c3ee44bf89b2f821716f6ee344ea09839cda6dee173b59dc49ba524b
> >>>
> >>> commons-dbcp2-2.11.0-src.zip=212e84f4a31a7b192ae4d534292b4d5c6dd48f3650c1caf844dad34b97c498d027266f5d3fae220efee1bbdb75df95adc9d6f58f35bb445b653dbbee3c485de2
> >>>
> >>> commons-dbcp2-2.11.0-test-sources.jar=78107b2437aa4b7232522f8c9791085da2f8421056208f7df220e327d7b45efb222da0eb2d1add99aa3d0d4c15e934d3a81f9cc6a5aa13bbd2f96370ca4d3365
> >>>
> >>> commons-dbcp2-2.11.0-tests.jar=553de32da56551a221fd7f974a6b704fc82a130546469ccb9de857504be4e4db3a8fde0911602270ca2c66b8dd61f5066c72ea935f39c1555ae5b7adc7b2af15
> >>>
> >>> I have tested this with:
> >>>
> >>> mvn -V -Ptest-deploy -P jacoco -P japicmp clean package site deploy
> >>>
> >>> Using:
> >>>
> >>> pache Maven 3.9.5 (57804f

Re: [VOTE] Release Apache Commons DBCP 2.11.0 based on RC1

[Rob Tompkins]

+1

> On Oct 27, 2023, at 11:13 AM, Gary Gregory  wrote:
> 
> My +1
> 
> Gary
> 
>> On Wed, Oct 25, 2023 at 6:26 AM Bruno Kinoshita  
>> wrote:
>> 
>>   [x] +1 Release these artifacts
>> 
>> Site reports OK, building fine on
>> 
>> Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
>> Maven home: /opt/apache-maven-3.8.5
>> Java version: 17.0.8.1, vendor: Private Build, runtime:
>> /usr/lib/jvm/java-17-openjdk-amd64
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "linux", version: "5.15.0-87-generic", arch: "amd64", family:
>> "unix"
>> 
>>> On Mon, 23 Oct 2023 at 19:55, Gary Gregory  wrote:
>>> 
>>> We have fixed a few bugs and added some enhancements since Apache
>>> Commons DBCP 2.9.0 was released, so I would like to release Apache
>>> Commons DBCP 2.11.0.
>>> 
>>> Apache Commons DBCP 2.11.0 RC1 is available for review here:
>>>https://dist.apache.org/repos/dist/dev/commons/dbcp/2.11.0-RC1
>>> (svn revision 64680)
>>> 
>>> The Git tag commons-dbcp-2.11.0-RC1 commit for this RC is
>>> e57ce3cf019ffa9534b88735c454c54afbe9849f which you can browse here:
>>> 
>>> https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=e57ce3cf019ffa9534b88735c454c54afbe9849f
>>> You may checkout this tag using:
>>>git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
>>> --branch <https://gitbox.apache.org/repos/asf/commons-dbcp.git--branch>
>>> commons-dbcp-2.11.0-RC1 commons-dbcp-2.11.0-RC1
>>> 
>>> Maven artifacts are here:
>>> 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1668/org/apache/commons/commons-dbcp2/2.11.0/
>>> 
>>> These are the artifacts and their hashes:
>>> 
>>> #Release SHA-512s
>>> #Mon Oct 23 13:37:23 EDT 2023
>>> Apache\ Commons\
>>> 
>>> DBCP-2.11.0.spdx.rdf.xml=3d02a79fc5cfcb453195efe4a045f7b37ded7ba0fb0eadb301f7800e86019e3d7d9824e47f3db04ce530936cb770ad0c39cff2801070d9171c862085a79416c3
>>> 
>>> commons-dbcp2-2.11.0-bin.tar.gz=34432889d6d973c6ff662c1189713fb48fdb431433a969b11186501fab338b6fe1ec3c402454dfebb7a16f8fb5e8e7c67633868a1a796faafb322d7a8215a527
>>> 
>>> commons-dbcp2-2.11.0-bin.zip=b82e9e8e2c9df52424e59a0fbb2b1bd1cacd9f37686a237392d0801ab4bf69c7d0fe8b886442cc1a0613e04bb96039bf77e093bb0cd861d809ba9761d3a74359
>>> 
>>> commons-dbcp2-2.11.0-bom.json=2c338fc5cea7e3210c4c489316b30c4313ae20139593b29e5d3970b01f17e094f2880e13230c83ac02373b8b8e30c162835bbcf85502084eab40f87b94bf4560
>>> 
>>> commons-dbcp2-2.11.0-bom.xml=93a1d28bfa6e2f3d99452be23e02aae107b32a9cf7bdd5547c76f3bcb93a7f536a7a2f71231975e794e096c335618e14c43c52e53fd34bc12c626d10e6efb72b
>>> 
>>> commons-dbcp2-2.11.0-javadoc.jar=bb4235fb91a74934ef408439019091a2f9938d3297fa932aa58f104532aab02911be77a674c945ea62b1d7dc1713466c375bedd87d0395db44f3a9aa3cf47870
>>> 
>>> commons-dbcp2-2.11.0-sources.jar=a4f5f86a281853191a526d53dc05551cb7a72a83078d521c6e7a06e92a607db3a7627af4d819d90bbc168c20228f4e2e55a1763c77a4c7e085171964b692810b
>>> 
>>> commons-dbcp2-2.11.0-src.tar.gz=2f73c4637a098925f7cf56fc49ee390a471f1f3faa50e8ee1595c762644437ea85683fa1c3ee44bf89b2f821716f6ee344ea09839cda6dee173b59dc49ba524b
>>> 
>>> commons-dbcp2-2.11.0-src.zip=212e84f4a31a7b192ae4d534292b4d5c6dd48f3650c1caf844dad34b97c498d027266f5d3fae220efee1bbdb75df95adc9d6f58f35bb445b653dbbee3c485de2
>>> 
>>> commons-dbcp2-2.11.0-test-sources.jar=78107b2437aa4b7232522f8c9791085da2f8421056208f7df220e327d7b45efb222da0eb2d1add99aa3d0d4c15e934d3a81f9cc6a5aa13bbd2f96370ca4d3365
>>> 
>>> commons-dbcp2-2.11.0-tests.jar=553de32da56551a221fd7f974a6b704fc82a130546469ccb9de857504be4e4db3a8fde0911602270ca2c66b8dd61f5066c72ea935f39c1555ae5b7adc7b2af15
>>> 
>>> I have tested this with:
>>> 
>>> mvn -V -Ptest-deploy -P jacoco -P japicmp clean package site deploy
>>> 
>>> Using:
>>> 
>>> pache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
>>> Maven home: /usr/local/Cellar/maven/3.9.5/libexec
>>> Java version: 21, vendor: Homebrew, runtime:
>>> /usr/local/Cellar/openjdk/21/libexec/openjdk.jdk/Contents/Home
>>> Default locale: en_US, platform encoding: UTF-8
>>> OS name: "mac os x", version: "14.0", arch: "x86_64", family: "mac"
>>> Darwin gdg-mac-mini.local 23.0.0 Darwin Kernel Version 23.0.0: Fri Sep
>>> 15 14:42:42 PDT 2023; root:xnu-1000

Re: [VOTE] Release Apache Commons DBCP 2.11.0 based on RC1

[Gary Gregory]

My +1

Gary

On Wed, Oct 25, 2023 at 6:26 AM Bruno Kinoshita  wrote:
>
>[x] +1 Release these artifacts
>
> Site reports OK, building fine on
>
> Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> Maven home: /opt/apache-maven-3.8.5
> Java version: 17.0.8.1, vendor: Private Build, runtime:
> /usr/lib/jvm/java-17-openjdk-amd64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-87-generic", arch: "amd64", family:
> "unix"
>
> On Mon, 23 Oct 2023 at 19:55, Gary Gregory  wrote:
>
> > We have fixed a few bugs and added some enhancements since Apache
> > Commons DBCP 2.9.0 was released, so I would like to release Apache
> > Commons DBCP 2.11.0.
> >
> > Apache Commons DBCP 2.11.0 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/dbcp/2.11.0-RC1
> > (svn revision 64680)
> >
> > The Git tag commons-dbcp-2.11.0-RC1 commit for this RC is
> > e57ce3cf019ffa9534b88735c454c54afbe9849f which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=e57ce3cf019ffa9534b88735c454c54afbe9849f
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
> > --branch <https://gitbox.apache.org/repos/asf/commons-dbcp.git--branch>
> > commons-dbcp-2.11.0-RC1 commons-dbcp-2.11.0-RC1
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1668/org/apache/commons/commons-dbcp2/2.11.0/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Mon Oct 23 13:37:23 EDT 2023
> > Apache\ Commons\
> >
> > DBCP-2.11.0.spdx.rdf.xml=3d02a79fc5cfcb453195efe4a045f7b37ded7ba0fb0eadb301f7800e86019e3d7d9824e47f3db04ce530936cb770ad0c39cff2801070d9171c862085a79416c3
> >
> > commons-dbcp2-2.11.0-bin.tar.gz=34432889d6d973c6ff662c1189713fb48fdb431433a969b11186501fab338b6fe1ec3c402454dfebb7a16f8fb5e8e7c67633868a1a796faafb322d7a8215a527
> >
> > commons-dbcp2-2.11.0-bin.zip=b82e9e8e2c9df52424e59a0fbb2b1bd1cacd9f37686a237392d0801ab4bf69c7d0fe8b886442cc1a0613e04bb96039bf77e093bb0cd861d809ba9761d3a74359
> >
> > commons-dbcp2-2.11.0-bom.json=2c338fc5cea7e3210c4c489316b30c4313ae20139593b29e5d3970b01f17e094f2880e13230c83ac02373b8b8e30c162835bbcf85502084eab40f87b94bf4560
> >
> > commons-dbcp2-2.11.0-bom.xml=93a1d28bfa6e2f3d99452be23e02aae107b32a9cf7bdd5547c76f3bcb93a7f536a7a2f71231975e794e096c335618e14c43c52e53fd34bc12c626d10e6efb72b
> >
> > commons-dbcp2-2.11.0-javadoc.jar=bb4235fb91a74934ef408439019091a2f9938d3297fa932aa58f104532aab02911be77a674c945ea62b1d7dc1713466c375bedd87d0395db44f3a9aa3cf47870
> >
> > commons-dbcp2-2.11.0-sources.jar=a4f5f86a281853191a526d53dc05551cb7a72a83078d521c6e7a06e92a607db3a7627af4d819d90bbc168c20228f4e2e55a1763c77a4c7e085171964b692810b
> >
> > commons-dbcp2-2.11.0-src.tar.gz=2f73c4637a098925f7cf56fc49ee390a471f1f3faa50e8ee1595c762644437ea85683fa1c3ee44bf89b2f821716f6ee344ea09839cda6dee173b59dc49ba524b
> >
> > commons-dbcp2-2.11.0-src.zip=212e84f4a31a7b192ae4d534292b4d5c6dd48f3650c1caf844dad34b97c498d027266f5d3fae220efee1bbdb75df95adc9d6f58f35bb445b653dbbee3c485de2
> >
> > commons-dbcp2-2.11.0-test-sources.jar=78107b2437aa4b7232522f8c9791085da2f8421056208f7df220e327d7b45efb222da0eb2d1add99aa3d0d4c15e934d3a81f9cc6a5aa13bbd2f96370ca4d3365
> >
> > commons-dbcp2-2.11.0-tests.jar=553de32da56551a221fd7f974a6b704fc82a130546469ccb9de857504be4e4db3a8fde0911602270ca2c66b8dd61f5066c72ea935f39c1555ae5b7adc7b2af15
> >
> > I have tested this with:
> >
> > mvn -V -Ptest-deploy -P jacoco -P japicmp clean package site deploy
> >
> > Using:
> >
> > pache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
> > Maven home: /usr/local/Cellar/maven/3.9.5/libexec
> > Java version: 21, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk/21/libexec/openjdk.jdk/Contents/Home
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "14.0", arch: "x86_64", family: "mac"
> > Darwin gdg-mac-mini.local 23.0.0 Darwin Kernel Version 23.0.0: Fri Sep
> > 15 14:42:42 PDT 2023; root:xnu-10002.1.13~1/RELEASE_X86_64 x86_64
> >
> > Details of changes since 2.9.0 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/dbcp/2.11.0-RC1/RELEASE-NOTES.txt
> >
> > https://dist.apache.org/repos/dist/dev/commons/dbcp/2.11.0-RC1/site/changes-report.html
> >
> > Site:
> >
> > https://dist.apache.org/repos

Re: [VOTE] Release Apache Commons DBCP 2.11.0 based on RC1

[Bruno Kinoshita]

   [x] +1 Release these artifacts

Site reports OK, building fine on

Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
Maven home: /opt/apache-maven-3.8.5
Java version: 17.0.8.1, vendor: Private Build, runtime:
/usr/lib/jvm/java-17-openjdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.15.0-87-generic", arch: "amd64", family:
"unix"

On Mon, 23 Oct 2023 at 19:55, Gary Gregory  wrote:

> We have fixed a few bugs and added some enhancements since Apache
> Commons DBCP 2.9.0 was released, so I would like to release Apache
> Commons DBCP 2.11.0.
>
> Apache Commons DBCP 2.11.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.11.0-RC1
> (svn revision 64680)
>
> The Git tag commons-dbcp-2.11.0-RC1 commit for this RC is
> e57ce3cf019ffa9534b88735c454c54afbe9849f which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=e57ce3cf019ffa9534b88735c454c54afbe9849f
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
> --branch <https://gitbox.apache.org/repos/asf/commons-dbcp.git--branch>
> commons-dbcp-2.11.0-RC1 commons-dbcp-2.11.0-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1668/org/apache/commons/commons-dbcp2/2.11.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Mon Oct 23 13:37:23 EDT 2023
> Apache\ Commons\
>
> DBCP-2.11.0.spdx.rdf.xml=3d02a79fc5cfcb453195efe4a045f7b37ded7ba0fb0eadb301f7800e86019e3d7d9824e47f3db04ce530936cb770ad0c39cff2801070d9171c862085a79416c3
>
> commons-dbcp2-2.11.0-bin.tar.gz=34432889d6d973c6ff662c1189713fb48fdb431433a969b11186501fab338b6fe1ec3c402454dfebb7a16f8fb5e8e7c67633868a1a796faafb322d7a8215a527
>
> commons-dbcp2-2.11.0-bin.zip=b82e9e8e2c9df52424e59a0fbb2b1bd1cacd9f37686a237392d0801ab4bf69c7d0fe8b886442cc1a0613e04bb96039bf77e093bb0cd861d809ba9761d3a74359
>
> commons-dbcp2-2.11.0-bom.json=2c338fc5cea7e3210c4c489316b30c4313ae20139593b29e5d3970b01f17e094f2880e13230c83ac02373b8b8e30c162835bbcf85502084eab40f87b94bf4560
>
> commons-dbcp2-2.11.0-bom.xml=93a1d28bfa6e2f3d99452be23e02aae107b32a9cf7bdd5547c76f3bcb93a7f536a7a2f71231975e794e096c335618e14c43c52e53fd34bc12c626d10e6efb72b
>
> commons-dbcp2-2.11.0-javadoc.jar=bb4235fb91a74934ef408439019091a2f9938d3297fa932aa58f104532aab02911be77a674c945ea62b1d7dc1713466c375bedd87d0395db44f3a9aa3cf47870
>
> commons-dbcp2-2.11.0-sources.jar=a4f5f86a281853191a526d53dc05551cb7a72a83078d521c6e7a06e92a607db3a7627af4d819d90bbc168c20228f4e2e55a1763c77a4c7e085171964b692810b
>
> commons-dbcp2-2.11.0-src.tar.gz=2f73c4637a098925f7cf56fc49ee390a471f1f3faa50e8ee1595c762644437ea85683fa1c3ee44bf89b2f821716f6ee344ea09839cda6dee173b59dc49ba524b
>
> commons-dbcp2-2.11.0-src.zip=212e84f4a31a7b192ae4d534292b4d5c6dd48f3650c1caf844dad34b97c498d027266f5d3fae220efee1bbdb75df95adc9d6f58f35bb445b653dbbee3c485de2
>
> commons-dbcp2-2.11.0-test-sources.jar=78107b2437aa4b7232522f8c9791085da2f8421056208f7df220e327d7b45efb222da0eb2d1add99aa3d0d4c15e934d3a81f9cc6a5aa13bbd2f96370ca4d3365
>
> commons-dbcp2-2.11.0-tests.jar=553de32da56551a221fd7f974a6b704fc82a130546469ccb9de857504be4e4db3a8fde0911602270ca2c66b8dd61f5066c72ea935f39c1555ae5b7adc7b2af15
>
> I have tested this with:
>
> mvn -V -Ptest-deploy -P jacoco -P japicmp clean package site deploy
>
> Using:
>
> pache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
> Maven home: /usr/local/Cellar/maven/3.9.5/libexec
> Java version: 21, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk/21/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.0", arch: "x86_64", family: "mac"
> Darwin gdg-mac-mini.local 23.0.0 Darwin Kernel Version 23.0.0: Fri Sep
> 15 14:42:42 PDT 2023; root:xnu-10002.1.13~1/RELEASE_X86_64 x86_64
>
> Details of changes since 2.9.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.11.0-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.11.0-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.11.0-RC1/site/index.html
> (note some *relative* links are broken and the 2.11.0 directories
> are not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 2.9.0):
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.11.0-RC1/site/japicmp.html
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.11.0-RC1/site/rat-report.html
>
> KEYS:
>   https://downloads.apache.o

[VOTE] Release Apache Commons DBCP 2.11.0 based on RC1

[Gary Gregory]

We have fixed a few bugs and added some enhancements since Apache
Commons DBCP 2.9.0 was released, so I would like to release Apache
Commons DBCP 2.11.0.

Apache Commons DBCP 2.11.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/dbcp/2.11.0-RC1
(svn revision 64680)

The Git tag commons-dbcp-2.11.0-RC1 commit for this RC is
e57ce3cf019ffa9534b88735c454c54afbe9849f which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=e57ce3cf019ffa9534b88735c454c54afbe9849f
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
--branch commons-dbcp-2.11.0-RC1 commons-dbcp-2.11.0-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1668/org/apache/commons/commons-dbcp2/2.11.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Mon Oct 23 13:37:23 EDT 2023
Apache\ Commons\
DBCP-2.11.0.spdx.rdf.xml=3d02a79fc5cfcb453195efe4a045f7b37ded7ba0fb0eadb301f7800e86019e3d7d9824e47f3db04ce530936cb770ad0c39cff2801070d9171c862085a79416c3
commons-dbcp2-2.11.0-bin.tar.gz=34432889d6d973c6ff662c1189713fb48fdb431433a969b11186501fab338b6fe1ec3c402454dfebb7a16f8fb5e8e7c67633868a1a796faafb322d7a8215a527
commons-dbcp2-2.11.0-bin.zip=b82e9e8e2c9df52424e59a0fbb2b1bd1cacd9f37686a237392d0801ab4bf69c7d0fe8b886442cc1a0613e04bb96039bf77e093bb0cd861d809ba9761d3a74359
commons-dbcp2-2.11.0-bom.json=2c338fc5cea7e3210c4c489316b30c4313ae20139593b29e5d3970b01f17e094f2880e13230c83ac02373b8b8e30c162835bbcf85502084eab40f87b94bf4560
commons-dbcp2-2.11.0-bom.xml=93a1d28bfa6e2f3d99452be23e02aae107b32a9cf7bdd5547c76f3bcb93a7f536a7a2f71231975e794e096c335618e14c43c52e53fd34bc12c626d10e6efb72b
commons-dbcp2-2.11.0-javadoc.jar=bb4235fb91a74934ef408439019091a2f9938d3297fa932aa58f104532aab02911be77a674c945ea62b1d7dc1713466c375bedd87d0395db44f3a9aa3cf47870
commons-dbcp2-2.11.0-sources.jar=a4f5f86a281853191a526d53dc05551cb7a72a83078d521c6e7a06e92a607db3a7627af4d819d90bbc168c20228f4e2e55a1763c77a4c7e085171964b692810b
commons-dbcp2-2.11.0-src.tar.gz=2f73c4637a098925f7cf56fc49ee390a471f1f3faa50e8ee1595c762644437ea85683fa1c3ee44bf89b2f821716f6ee344ea09839cda6dee173b59dc49ba524b
commons-dbcp2-2.11.0-src.zip=212e84f4a31a7b192ae4d534292b4d5c6dd48f3650c1caf844dad34b97c498d027266f5d3fae220efee1bbdb75df95adc9d6f58f35bb445b653dbbee3c485de2
commons-dbcp2-2.11.0-test-sources.jar=78107b2437aa4b7232522f8c9791085da2f8421056208f7df220e327d7b45efb222da0eb2d1add99aa3d0d4c15e934d3a81f9cc6a5aa13bbd2f96370ca4d3365
commons-dbcp2-2.11.0-tests.jar=553de32da56551a221fd7f974a6b704fc82a130546469ccb9de857504be4e4db3a8fde0911602270ca2c66b8dd61f5066c72ea935f39c1555ae5b7adc7b2af15

I have tested this with:

mvn -V -Ptest-deploy -P jacoco -P japicmp clean package site deploy

Using:

pache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
Maven home: /usr/local/Cellar/maven/3.9.5/libexec
Java version: 21, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk/21/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.0", arch: "x86_64", family: "mac"
Darwin gdg-mac-mini.local 23.0.0 Darwin Kernel Version 23.0.0: Fri Sep
15 14:42:42 PDT 2023; root:xnu-10002.1.13~1/RELEASE_X86_64 x86_64

Details of changes since 2.9.0 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.11.0-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.11.0-RC1/site/changes-report.html

Site:

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.11.0-RC1/site/index.html
(note some *relative* links are broken and the 2.11.0 directories
are not yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 2.9.0):

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.11.0-RC1/site/japicmp.html

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.11.0-RC1/site/rat-report.html

KEYS:
  https://downloads.apache.org/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Gary Gregory,
Release Manager (using key 86fdc7e2a11262cb)

For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1a) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
--branch commons-dbcp-2.11.0-RC1 commons-dbcp-2.11.0-RC1
cd commons-dbcp-2.11.0-RC1

1b) Download and unpack the source archive from:

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.11.0-RC1/source

2) Check Apache licenses

This step is

[ANNOUNCEMENT] Apache Commons DBCP 2.10.0

[Gary Gregory]

The Apache Commons DBCP team is pleased to announce the release of
Apache Commons DBCP 2.10.0.

Apache Commons DBCP software implements Database Connection Pooling.

This is a minor release, including bug fixes and enhancements:
https://commons.apache.org/proper/commons-dbcp/changes-report.html#a2.10.0

For complete information on Apache Commons DBCP, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Commons DBCP website:

https://commons.apache.org/dbcp/

Download page: https://commons.apache.org/dbcp/download_dbcp.cgi

Gary Gregory
Apache Commons

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[RESULT][VOTE] Release Apache Commons DBCP 2.10.0 based on RC1

[Gary Gregory]

This vote passes with the following binding +1s:

- Henri Biestro
- Rob Tompkins
- Gary Gregory

Thank you,
Gary

On Sun, Sep 3, 2023 at 7:05 AM Gary Gregory  wrote:

> My +1
>
> Gary
>
>
> On Mon, Aug 28, 2023 at 9:34 AM Gary Gregory 
> wrote:
>
>> We have fixed a few bugs and added some enhancements since Apache
>> Commons DBCP 2.9.0 was released, so I would like to release Apache
>> Commons DBCP 2.10.0.
>>
>> Apache Commons DBCP 2.10.0 RC1 is available for review here:
>> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1
>> (svn revision 63672)
>>
>> The Git tag commons-dbcp-2.10.0-RC1 commit for this RC is
>> f612e2f0830f459fc5d2a2fa6004e7c8d2ebf03f which you can browse here:
>>
>> https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=f612e2f0830f459fc5d2a2fa6004e7c8d2ebf03f
>> You may checkout this tag using:
>> git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
>> --branch <https://gitbox.apache.org/repos/asf/commons-dbcp.git--branch>
>> commons-dbcp-2.10.0-RC1 commons-dbcp-2.10.0-RC1
>>
>> Maven artifacts are here:
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1652/org/apache/commons/commons-dbcp2/2.10.0/
>>
>> These are the artifacts and their hashes:
>>
>> #Release SHA-512s
>> #Mon Aug 28 09:24:09 EDT 2023
>>
>> commons-dbcp2-2.10.0-javadoc.jar=fe6bc24f091f69142a59a414a6a5a9ad10f998cbab4723a108ad84cd5eef392cc838fd172e25d0432aa18fba316f10d8a28eb50e0a60403798529cf760327e56
>>
>> commons-dbcp2-2.10.0-test-sources.jar=4a4dffef71d9ff4ad877966ddc6797587f48a87fecbac8d7fda684d26f4c72c3998400df74fabe4cd2143a442c774e6722216e7e0bb00adfd2a3593e0812b3fc
>>
>> commons-dbcp2-2.10.0-src.tar.gz=73cc7227b576bb574221509eb6000ebff320a58de4b0efa7360630d0888c7b14eb35b7887310781723417731fedc767c4d011d55eee7bd12810a9cd50296e287
>>
>> commons-dbcp2-2.10.0-bom.xml=657ca0014b744ca030c40b4f779752da768c6f4e5075d6505f1c943b0406122a8256582eb08e425302fad58ec411f24353ddd28206e063fbf4ada323985efca2
>>
>> commons-dbcp2-2.10.0-bin.tar.gz=e16e9e51eacad44314da770b1f150afab99d887a9c03e37114706aa55ba1b790c5ad0b5de4cc444b777036696c258d102b56b9158907b8e5e21b30edc54cf381
>>
>> commons-dbcp2-2.10.0-sources.jar=01f2e5713e3f1c291fc8393639d0ace7e9d7a9ee4784a124a2452fc4fc4ad11ee27f570c0538f484f4038aca893da4e44f9d17bca83b4e7945bb419b31233bb8
>>
>> commons-dbcp2-2.10.0-bin.zip=65376d2049bcf0418fc1af456d83c6dd1af738913bb7678f6847a51c84c3aa3630216cef81ce7346f34728a2e54c99c611df3be9dc0994c537d755997c92a177
>>
>> commons-dbcp2-2.10.0-tests.jar=e13b9aab48f31e65277afa2c149c9b6f754c2f47b1eca13ab0eb246ce7ef4cb6a267bba4b2a1a2051dd05620f3783cde64a31513b821dfe6276f01f2235b099c
>> Apache\ Commons\
>>
>> DBCP-2.10.0.spdx.rdf.xml=a8ecf26b2961de5d653a86fe5282772b1bbef41e6c928df3830e34898a10c9afbe444e82fc0950278c8d6889caf909e3d80221994a75eac95c7c44ab6e84decc
>>
>> commons-dbcp2-2.10.0-bom.json=9a908537ecebaae63c471a1826bb9d304e36db4a81e8a7d8b9dc4400779a5a0a0282405a593f39018cc79489eac93d323382932209745915f7a0c864cde4883a
>>
>> commons-dbcp2-2.10.0-src.zip=631eea5d36f00d2c648b023057bea55edea174418283769310321f4851a49ccafbb101a6a4f835a396b6c3b1d34b6e284f26038dafc3686be3a9dd3690cf41c7
>>
>> I have tested this with:
>>
>> mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site
>> deploy
>>
>> Using:
>>
>> pache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
>> Maven home: /usr/local/Cellar/maven/3.9.4/libexec
>> Java version: 11.0.20.1, vendor: Homebrew, runtime:
>> /usr/local/Cellar/openjdk@11/11.0.20.1/libexec/openjdk.jdk/Contents/Home
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "mac os x", version: "13.5.1", arch: "x86_64", family: "mac"
>> Darwin  22.6.0 Darwin Kernel Version 22.6.0: Wed Jul  5 22:21:56
>> PDT 2023; root:xnu-8796.141.3~6/RELEASE_X86_64 x86_64
>>
>> Details of changes since 2.9.0 are in the release notes:
>>
>> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/RELEASE-NOTES.txt
>>
>> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/site/changes-report.html
>>
>> Site:
>>
>> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/site/index.html
>> (note some *relative* links are broken and the 2.10.0 directories
>> are not yet created - these will be OK once the site is deployed.)
>>
>> JApiCmp Report (compared to 2.9.0):
>>
>> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/site/japicmp.html
>>
>> RAT Report:
&

Re: [VOTE] Release Apache Commons DBCP 2.10.0 based on RC1

[Gary Gregory]

My +1

Gary


On Mon, Aug 28, 2023 at 9:34 AM Gary Gregory  wrote:

> We have fixed a few bugs and added some enhancements since Apache
> Commons DBCP 2.9.0 was released, so I would like to release Apache
> Commons DBCP 2.10.0.
>
> Apache Commons DBCP 2.10.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1
> (svn revision 63672)
>
> The Git tag commons-dbcp-2.10.0-RC1 commit for this RC is
> f612e2f0830f459fc5d2a2fa6004e7c8d2ebf03f which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=f612e2f0830f459fc5d2a2fa6004e7c8d2ebf03f
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
> --branch <https://gitbox.apache.org/repos/asf/commons-dbcp.git--branch>
> commons-dbcp-2.10.0-RC1 commons-dbcp-2.10.0-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1652/org/apache/commons/commons-dbcp2/2.10.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Mon Aug 28 09:24:09 EDT 2023
>
> commons-dbcp2-2.10.0-javadoc.jar=fe6bc24f091f69142a59a414a6a5a9ad10f998cbab4723a108ad84cd5eef392cc838fd172e25d0432aa18fba316f10d8a28eb50e0a60403798529cf760327e56
>
> commons-dbcp2-2.10.0-test-sources.jar=4a4dffef71d9ff4ad877966ddc6797587f48a87fecbac8d7fda684d26f4c72c3998400df74fabe4cd2143a442c774e6722216e7e0bb00adfd2a3593e0812b3fc
>
> commons-dbcp2-2.10.0-src.tar.gz=73cc7227b576bb574221509eb6000ebff320a58de4b0efa7360630d0888c7b14eb35b7887310781723417731fedc767c4d011d55eee7bd12810a9cd50296e287
>
> commons-dbcp2-2.10.0-bom.xml=657ca0014b744ca030c40b4f779752da768c6f4e5075d6505f1c943b0406122a8256582eb08e425302fad58ec411f24353ddd28206e063fbf4ada323985efca2
>
> commons-dbcp2-2.10.0-bin.tar.gz=e16e9e51eacad44314da770b1f150afab99d887a9c03e37114706aa55ba1b790c5ad0b5de4cc444b777036696c258d102b56b9158907b8e5e21b30edc54cf381
>
> commons-dbcp2-2.10.0-sources.jar=01f2e5713e3f1c291fc8393639d0ace7e9d7a9ee4784a124a2452fc4fc4ad11ee27f570c0538f484f4038aca893da4e44f9d17bca83b4e7945bb419b31233bb8
>
> commons-dbcp2-2.10.0-bin.zip=65376d2049bcf0418fc1af456d83c6dd1af738913bb7678f6847a51c84c3aa3630216cef81ce7346f34728a2e54c99c611df3be9dc0994c537d755997c92a177
>
> commons-dbcp2-2.10.0-tests.jar=e13b9aab48f31e65277afa2c149c9b6f754c2f47b1eca13ab0eb246ce7ef4cb6a267bba4b2a1a2051dd05620f3783cde64a31513b821dfe6276f01f2235b099c
> Apache\ Commons\
>
> DBCP-2.10.0.spdx.rdf.xml=a8ecf26b2961de5d653a86fe5282772b1bbef41e6c928df3830e34898a10c9afbe444e82fc0950278c8d6889caf909e3d80221994a75eac95c7c44ab6e84decc
>
> commons-dbcp2-2.10.0-bom.json=9a908537ecebaae63c471a1826bb9d304e36db4a81e8a7d8b9dc4400779a5a0a0282405a593f39018cc79489eac93d323382932209745915f7a0c864cde4883a
>
> commons-dbcp2-2.10.0-src.zip=631eea5d36f00d2c648b023057bea55edea174418283769310321f4851a49ccafbb101a6a4f835a396b6c3b1d34b6e284f26038dafc3686be3a9dd3690cf41c7
>
> I have tested this with:
>
> mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site
> deploy
>
> Using:
>
> pache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> Maven home: /usr/local/Cellar/maven/3.9.4/libexec
> Java version: 11.0.20.1, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@11/11.0.20.1/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "13.5.1", arch: "x86_64", family: "mac"
> Darwin  22.6.0 Darwin Kernel Version 22.6.0: Wed Jul  5 22:21:56
> PDT 2023; root:xnu-8796.141.3~6/RELEASE_X86_64 x86_64
>
> Details of changes since 2.9.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/site/changes-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/site/index.html
> (note some *relative* links are broken and the 2.10.0 directories
> are not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 2.9.0):
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/site/japicmp.html
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/site/rat-report.html
>
> KEYS:
>   https://downloads.apache.org/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> Gary Gregory,
> Release Manager (using key 86fdc7e2a11262cb)
&g

Re: [VOTE] Release Apache Commons DBCP 2.10.0 based on RC1

[Rob Tompkins]

+1 signatures good, reports good

mvn clean test package install works

nit mvn site doesn’t work for me on my machine


> On Aug 28, 2023, at 9:34 AM, Gary Gregory  wrote:
> 
> We have fixed a few bugs and added some enhancements since Apache
> Commons DBCP 2.9.0 was released, so I would like to release Apache
> Commons DBCP 2.10.0.
> 
> Apache Commons DBCP 2.10.0 RC1 is available for review here:
>https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1
> (svn revision 63672)
> 
> The Git tag commons-dbcp-2.10.0-RC1 commit for this RC is
> f612e2f0830f459fc5d2a2fa6004e7c8d2ebf03f which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=f612e2f0830f459fc5d2a2fa6004e7c8d2ebf03f
> You may checkout this tag using:
>git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
> --branch commons-dbcp-2.10.0-RC1 commons-dbcp-2.10.0-RC1
> 
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1652/org/apache/commons/commons-dbcp2/2.10.0/
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> #Mon Aug 28 09:24:09 EDT 2023
> commons-dbcp2-2.10.0-javadoc.jar=fe6bc24f091f69142a59a414a6a5a9ad10f998cbab4723a108ad84cd5eef392cc838fd172e25d0432aa18fba316f10d8a28eb50e0a60403798529cf760327e56
> commons-dbcp2-2.10.0-test-sources.jar=4a4dffef71d9ff4ad877966ddc6797587f48a87fecbac8d7fda684d26f4c72c3998400df74fabe4cd2143a442c774e6722216e7e0bb00adfd2a3593e0812b3fc
> commons-dbcp2-2.10.0-src.tar.gz=73cc7227b576bb574221509eb6000ebff320a58de4b0efa7360630d0888c7b14eb35b7887310781723417731fedc767c4d011d55eee7bd12810a9cd50296e287
> commons-dbcp2-2.10.0-bom.xml=657ca0014b744ca030c40b4f779752da768c6f4e5075d6505f1c943b0406122a8256582eb08e425302fad58ec411f24353ddd28206e063fbf4ada323985efca2
> commons-dbcp2-2.10.0-bin.tar.gz=e16e9e51eacad44314da770b1f150afab99d887a9c03e37114706aa55ba1b790c5ad0b5de4cc444b777036696c258d102b56b9158907b8e5e21b30edc54cf381
> commons-dbcp2-2.10.0-sources.jar=01f2e5713e3f1c291fc8393639d0ace7e9d7a9ee4784a124a2452fc4fc4ad11ee27f570c0538f484f4038aca893da4e44f9d17bca83b4e7945bb419b31233bb8
> commons-dbcp2-2.10.0-bin.zip=65376d2049bcf0418fc1af456d83c6dd1af738913bb7678f6847a51c84c3aa3630216cef81ce7346f34728a2e54c99c611df3be9dc0994c537d755997c92a177
> commons-dbcp2-2.10.0-tests.jar=e13b9aab48f31e65277afa2c149c9b6f754c2f47b1eca13ab0eb246ce7ef4cb6a267bba4b2a1a2051dd05620f3783cde64a31513b821dfe6276f01f2235b099c
> Apache\ Commons\
> DBCP-2.10.0.spdx.rdf.xml=a8ecf26b2961de5d653a86fe5282772b1bbef41e6c928df3830e34898a10c9afbe444e82fc0950278c8d6889caf909e3d80221994a75eac95c7c44ab6e84decc
> commons-dbcp2-2.10.0-bom.json=9a908537ecebaae63c471a1826bb9d304e36db4a81e8a7d8b9dc4400779a5a0a0282405a593f39018cc79489eac93d323382932209745915f7a0c864cde4883a
> commons-dbcp2-2.10.0-src.zip=631eea5d36f00d2c648b023057bea55edea174418283769310321f4851a49ccafbb101a6a4f835a396b6c3b1d34b6e284f26038dafc3686be3a9dd3690cf41c7
> 
> I have tested this with:
> 
> mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy
> 
> Using:
> 
> pache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> Maven home: /usr/local/Cellar/maven/3.9.4/libexec
> Java version: 11.0.20.1, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@11/11.0.20.1/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "13.5.1", arch: "x86_64", family: "mac"
> Darwin  22.6.0 Darwin Kernel Version 22.6.0: Wed Jul  5 22:21:56
> PDT 2023; root:xnu-8796.141.3~6/RELEASE_X86_64 x86_64
> 
> Details of changes since 2.9.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/site/changes-report.html
> 
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/site/index.html
>    (note some *relative* links are broken and the 2.10.0 directories
> are not yet created - these will be OK once the site is deployed.)
> 
> JApiCmp Report (compared to 2.9.0):
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/site/japicmp.html
> 
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/site/rat-report.html
> 
> KEYS:
>  https://downloads.apache.org/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
> 
>  [ ] +1 Release these artifacts
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [ ] -1 I oppose this release because...
> 
> Thank you,
> 
> Gary Gregory,
> Release Manager (using key 86fdc7e2a11262

Re: [VOTE] Release Apache Commons DBCP 2.10.0 based on RC1

[Rob Tompkins]

will look at this, this evening.

-Rob

> On Sep 1, 2023, at 10:59 AM, Henri Biestro  wrote:
> 
> 
> [ +1] Release these artifacts
> 
> Built on:
> 22.5.0 Darwin Kernel Version 22.5.0: Thu Jun  8 22:22:20 PDT 2023; 
> root:xnu-8796.121.3~7/RELEASE_ARM64_T6000 arm64
> 
> With:
> openjdk version "1.8.0_352"
> OpenJDK Runtime Environment (Zulu 8.66.0.15-CA-macos-aarch64) (build 
> 1.8.0_352-b08)
> OpenJDK 64-Bit Server VM (Zulu 8.66.0.15-CA-macos-aarch64) (build 25.352-b08, 
> mixed mode)
> 
> Running:
> mvn clean install; mvn site;
> 
> Build and tests ok, site is ok; no warnings of any kind in reports (japicmp, 
> pmd, checkstyle, spotbugs). 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons DBCP 2.10.0 based on RC1

[Henri Biestro]

[ +1] Release these artifacts

Built on:
22.5.0 Darwin Kernel Version 22.5.0: Thu Jun  8 22:22:20 PDT 2023; 
root:xnu-8796.121.3~7/RELEASE_ARM64_T6000 arm64

With:
openjdk version "1.8.0_352"
OpenJDK Runtime Environment (Zulu 8.66.0.15-CA-macos-aarch64) (build 
1.8.0_352-b08)
OpenJDK 64-Bit Server VM (Zulu 8.66.0.15-CA-macos-aarch64) (build 25.352-b08, 
mixed mode)

Running:
mvn clean install; mvn site;

Build and tests ok, site is ok; no warnings of any kind in reports (japicmp, 
pmd, checkstyle, spotbugs). 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release Apache Commons DBCP 2.10.0 based on RC1

[Gary Gregory]

We have fixed a few bugs and added some enhancements since Apache
Commons DBCP 2.9.0 was released, so I would like to release Apache
Commons DBCP 2.10.0.

Apache Commons DBCP 2.10.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1
(svn revision 63672)

The Git tag commons-dbcp-2.10.0-RC1 commit for this RC is
f612e2f0830f459fc5d2a2fa6004e7c8d2ebf03f which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=f612e2f0830f459fc5d2a2fa6004e7c8d2ebf03f
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
--branch commons-dbcp-2.10.0-RC1 commons-dbcp-2.10.0-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1652/org/apache/commons/commons-dbcp2/2.10.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Mon Aug 28 09:24:09 EDT 2023
commons-dbcp2-2.10.0-javadoc.jar=fe6bc24f091f69142a59a414a6a5a9ad10f998cbab4723a108ad84cd5eef392cc838fd172e25d0432aa18fba316f10d8a28eb50e0a60403798529cf760327e56
commons-dbcp2-2.10.0-test-sources.jar=4a4dffef71d9ff4ad877966ddc6797587f48a87fecbac8d7fda684d26f4c72c3998400df74fabe4cd2143a442c774e6722216e7e0bb00adfd2a3593e0812b3fc
commons-dbcp2-2.10.0-src.tar.gz=73cc7227b576bb574221509eb6000ebff320a58de4b0efa7360630d0888c7b14eb35b7887310781723417731fedc767c4d011d55eee7bd12810a9cd50296e287
commons-dbcp2-2.10.0-bom.xml=657ca0014b744ca030c40b4f779752da768c6f4e5075d6505f1c943b0406122a8256582eb08e425302fad58ec411f24353ddd28206e063fbf4ada323985efca2
commons-dbcp2-2.10.0-bin.tar.gz=e16e9e51eacad44314da770b1f150afab99d887a9c03e37114706aa55ba1b790c5ad0b5de4cc444b777036696c258d102b56b9158907b8e5e21b30edc54cf381
commons-dbcp2-2.10.0-sources.jar=01f2e5713e3f1c291fc8393639d0ace7e9d7a9ee4784a124a2452fc4fc4ad11ee27f570c0538f484f4038aca893da4e44f9d17bca83b4e7945bb419b31233bb8
commons-dbcp2-2.10.0-bin.zip=65376d2049bcf0418fc1af456d83c6dd1af738913bb7678f6847a51c84c3aa3630216cef81ce7346f34728a2e54c99c611df3be9dc0994c537d755997c92a177
commons-dbcp2-2.10.0-tests.jar=e13b9aab48f31e65277afa2c149c9b6f754c2f47b1eca13ab0eb246ce7ef4cb6a267bba4b2a1a2051dd05620f3783cde64a31513b821dfe6276f01f2235b099c
Apache\ Commons\
DBCP-2.10.0.spdx.rdf.xml=a8ecf26b2961de5d653a86fe5282772b1bbef41e6c928df3830e34898a10c9afbe444e82fc0950278c8d6889caf909e3d80221994a75eac95c7c44ab6e84decc
commons-dbcp2-2.10.0-bom.json=9a908537ecebaae63c471a1826bb9d304e36db4a81e8a7d8b9dc4400779a5a0a0282405a593f39018cc79489eac93d323382932209745915f7a0c864cde4883a
commons-dbcp2-2.10.0-src.zip=631eea5d36f00d2c648b023057bea55edea174418283769310321f4851a49ccafbb101a6a4f835a396b6c3b1d34b6e284f26038dafc3686be3a9dd3690cf41c7

I have tested this with:

mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy

Using:

pache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
Maven home: /usr/local/Cellar/maven/3.9.4/libexec
Java version: 11.0.20.1, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@11/11.0.20.1/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "13.5.1", arch: "x86_64", family: "mac"
Darwin  22.6.0 Darwin Kernel Version 22.6.0: Wed Jul  5 22:21:56
PDT 2023; root:xnu-8796.141.3~6/RELEASE_X86_64 x86_64

Details of changes since 2.9.0 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/site/changes-report.html

Site:

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/site/index.html
(note some *relative* links are broken and the 2.10.0 directories
are not yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 2.9.0):

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/site/japicmp.html

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/site/rat-report.html

KEYS:
  https://downloads.apache.org/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Gary Gregory,
Release Manager (using key 86fdc7e2a11262cb)

For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1a) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
--branch commons-dbcp-2.10.0-RC1 commons-dbcp-2.10.0-RC1
cd commons-dbcp-2.10.0-RC1

1b) Download and unpack the source archive from:

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.10.0-RC1/source

2) Check Apache license

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

@Emmanuel: tomee does not use tomcat-dbcp, it facade any JDBC pool library
with its own code so any managed package usage is really legacy since ~10
years.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 19 juin 2023 à 14:18, Richard Zowalla  a écrit :

> David wrote something similar on the tomee dev@ list [1].
> So perhaps it would be worth to just provide a jakarta capable package?
>
> [1] https://lists.apache.org/thread/gkmrdlwo1gpbzogqvrdyq1zqqt6pompc
>
> Am Montag, dem 19.06.2023 um 14:09 +0200 schrieb Emmanuel Bourg:
> > On 26/05/2023 12:20, Romain Manni-Bucau wrote:
> >
> > > TomEE can drop managed package legacy dependency now, was kept
> > > while the
> > > replacement was in test in 1.x version but makes years it is no
> > > more
> > > relevant and no more the default (since we switched to tomcat-
> > > jdbc).
> > > So no big deal if dbcp wants to drop it on TomEE side IMHO.
> >
> > Ok but tomcat-jdbc contains a modified copy of DBCP. Does TomEE use
> > the
> > managed package from tomcat-jdbc? If so we can't simply drop this
> > package from DBCP.
> >
> > Emmanuel Bourg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

David wrote something similar on the tomee dev@ list [1].
So perhaps it would be worth to just provide a jakarta capable package?

[1] https://lists.apache.org/thread/gkmrdlwo1gpbzogqvrdyq1zqqt6pompc

Am Montag, dem 19.06.2023 um 14:09 +0200 schrieb Emmanuel Bourg:
> On 26/05/2023 12:20, Romain Manni-Bucau wrote:
> 
> > TomEE can drop managed package legacy dependency now, was kept
> > while the
> > replacement was in test in 1.x version but makes years it is no
> > more
> > relevant and no more the default (since we switched to tomcat-
> > jdbc).
> > So no big deal if dbcp wants to drop it on TomEE side IMHO.
> 
> Ok but tomcat-jdbc contains a modified copy of DBCP. Does TomEE use
> the 
> managed package from tomcat-jdbc? If so we can't simply drop this 
> package from DBCP.
> 
> Emmanuel Bourg
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Emmanuel Bourg]

On 26/05/2023 12:20, Romain Manni-Bucau wrote:


TomEE can drop managed package legacy dependency now, was kept while the
replacement was in test in 1.x version but makes years it is no more
relevant and no more the default (since we switched to tomcat-jdbc).
So no big deal if dbcp wants to drop it on TomEE side IMHO.


Ok but tomcat-jdbc contains a modified copy of DBCP. Does TomEE use the 
managed package from tomcat-jdbc? If so we can't simply drop this 
package from DBCP.


Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

Hey Romain,

thanks for the info regarding the historic back story ;)
So perhaps time to drop it, i will take that on the TomEE list.

Gruß
Richard

Am Freitag, dem 26.05.2023 um 12:20 +0200 schrieb Romain Manni-Bucau:
> Hi Richard,
> 
> TomEE can drop managed package legacy dependency now, was kept while
> the
> replacement was in test in 1.x version but makes years it is no more
> relevant and no more the default (since we switched to tomcat-jdbc).
> So no big deal if dbcp wants to drop it on TomEE side IMHO.
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-perfor
> mance>
> 
> 
> Le ven. 26 mai 2023 à 12:19, Richard Zowalla  a
> écrit :
> 
> > The current TomEE codebase still uses classes from the "managed"
> > package of dbcp2. (Thus, we are shading it for TomEE 9 / 10)
> > 
> > We might be able to drop that integration at some point but
> > currently
> > our focus is on getting a EE10 milestone out of the door, so I
> > don't
> > think, that it is a theoretical issue.
> > 
> > Gruß
> > Richard
> > 
> > 
> > Am Freitag, dem 26.05.2023 um 12:08 +0200 schrieb Emmanuel Bourg:
> > > Le 11/05/2023 à 15:56, Richard Zowalla a écrit :
> > > > Hi,
> > > > 
> > > > do we have any updates?
> > > > 
> > > > How can I help to get a dbcp version supporting Jakarta
> > > > namespace?
> > > > 
> > > > Emmanuel outlined a possible appraoch. How can we move forward
> > > > with
> > > > it?
> > > 
> > > I'm tempted to merge the dual-javax-jakarta branch, but Romain's
> > > comment
> > > about TomEE no longer using the managed package made me wonder if
> > > we
> > > really need to bother at all.
> > > 
> > > Are we trying to fix a theoretical issue or are there actual
> > > users of
> > > these classes expecting a fix?
> > > 
> > > Emmanuel Bourg
> > > 
> > > 
> > > -
> > > 
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > 
> > 
> > 
> > ---
> > --
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> > 
> > 



signature.asc
Description: This is a digitally signed message part

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

Hi Richard,

TomEE can drop managed package legacy dependency now, was kept while the
replacement was in test in 1.x version but makes years it is no more
relevant and no more the default (since we switched to tomcat-jdbc).
So no big deal if dbcp wants to drop it on TomEE side IMHO.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 26 mai 2023 à 12:19, Richard Zowalla  a écrit :

> The current TomEE codebase still uses classes from the "managed"
> package of dbcp2. (Thus, we are shading it for TomEE 9 / 10)
>
> We might be able to drop that integration at some point but currently
> our focus is on getting a EE10 milestone out of the door, so I don't
> think, that it is a theoretical issue.
>
> Gruß
> Richard
>
>
> Am Freitag, dem 26.05.2023 um 12:08 +0200 schrieb Emmanuel Bourg:
> > Le 11/05/2023 à 15:56, Richard Zowalla a écrit :
> > > Hi,
> > >
> > > do we have any updates?
> > >
> > > How can I help to get a dbcp version supporting Jakarta namespace?
> > >
> > > Emmanuel outlined a possible appraoch. How can we move forward with
> > > it?
> >
> > I'm tempted to merge the dual-javax-jakarta branch, but Romain's
> > comment
> > about TomEE no longer using the managed package made me wonder if we
> > really need to bother at all.
> >
> > Are we trying to fix a theoretical issue or are there actual users of
> > these classes expecting a fix?
> >
> > Emmanuel Bourg
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

The current TomEE codebase still uses classes from the "managed"
package of dbcp2. (Thus, we are shading it for TomEE 9 / 10)

We might be able to drop that integration at some point but currently
our focus is on getting a EE10 milestone out of the door, so I don't
think, that it is a theoretical issue.

Gruß
Richard


Am Freitag, dem 26.05.2023 um 12:08 +0200 schrieb Emmanuel Bourg:
> Le 11/05/2023 à 15:56, Richard Zowalla a écrit :
> > Hi,
> > 
> > do we have any updates?
> > 
> > How can I help to get a dbcp version supporting Jakarta namespace?
> > 
> > Emmanuel outlined a possible appraoch. How can we move forward with
> > it?
> 
> I'm tempted to merge the dual-javax-jakarta branch, but Romain's
> comment 
> about TomEE no longer using the managed package made me wonder if we 
> really need to bother at all.
> 
> Are we trying to fix a theoretical issue or are there actual users of
> these classes expecting a fix?
> 
> Emmanuel Bourg
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Emmanuel Bourg]

Le 11/05/2023 à 15:56, Richard Zowalla a écrit :

Hi,

do we have any updates?

How can I help to get a dbcp version supporting Jakarta namespace?

Emmanuel outlined a possible appraoch. How can we move forward with it?


I'm tempted to merge the dual-javax-jakarta branch, but Romain's comment 
about TomEE no longer using the managed package made me wonder if we 
really need to bother at all.


Are we trying to fix a theoretical issue or are there actual users of 
these classes expecting a fix?


Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

Hi,

do we have any updates? 

How can I help to get a dbcp version supporting Jakarta namespace? 

Emmanuel outlined a possible appraoch. How can we move forward with it?

Thanks & Gruß
Richard


On 2022/12/30 12:52:45 Richard Zowalla wrote:
> Thanks a lot, Emmanuel! 
> 
> It looks good to me!
> 
> Gruß
> Richard
> 
> 
> Am Donnerstag, dem 29.12.2022 um 22:02 +0100 schrieb Emmanuel Bourg:
> > Thank you, it works perfectly now.
> > 
> > I've pushed the changes to:
> > 
> >  https://github.com/ebourg/commons-dbcp/tree/jakarta
> > 
> > Comments are welcome before I create a dbcp3 branch on the ASF
> > repository.
> > 
> > I think the API should be kept identical to dbcp2 to ease porting 
> > changes and facilitate migrations. So no removal of deprecated
> > methods 
> > before dbcp4.
> > 
> > Emmanuel Bourg
> > 
> > 
> > On 28/12/2022 19:22, Romain Manni-Bucau wrote:
> > > Hi Emmanuel,
> > > 
> > > You have
> > > https://repo1.maven.org/maven2/org/apache/geronimo/components/geronimo-transaction/3.1.5/geronimo-transaction-3.1.5-jakarta.jar
> > > which is usable if you exclude transitive deps.
> > > 
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > > https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> > 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-dbcp] branch master updated: Correct a regression introduced in d69e6a5

[Gary Gregory]

Shouldn't we have a unit test that validates the expected names to
avoid this type of issue?

Gary

On Wed, Mar 8, 2023 at 8:18 AM  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> markt pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-dbcp.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new b1e0c86d Correct a regression introduced in d69e6a5
> b1e0c86d is described below
>
> commit b1e0c86d101aa43029625eb191aaee4306911702
> Author: Mark Thomas 
> AuthorDate: Wed Mar 8 13:17:58 2023 +
>
> Correct a regression introduced in d69e6a5
>
> Can't change the public name of configuration property in a point
> release.
> ---
>  .../java/org/apache/commons/dbcp2/cpdsadapter/DriverAdapterCPDS.java  | 4 
> ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git 
> a/src/main/java/org/apache/commons/dbcp2/cpdsadapter/DriverAdapterCPDS.java 
> b/src/main/java/org/apache/commons/dbcp2/cpdsadapter/DriverAdapterCPDS.java
> index 6f56f645..1c7ee353 100644
> --- 
> a/src/main/java/org/apache/commons/dbcp2/cpdsadapter/DriverAdapterCPDS.java
> +++ 
> b/src/main/java/org/apache/commons/dbcp2/cpdsadapter/DriverAdapterCPDS.java
> @@ -288,7 +288,7 @@ public class DriverAdapterCPDS implements 
> ConnectionPoolDataSource, Referenceabl
>  if (isNotEmpty(ra)) {
>  setDriver(getStringContent(ra));
>  }
> -ra = ref.get("connectionString");
> +ra = ref.get("url");
>  if (isNotEmpty(ra)) {
>  setUrl(getStringContent(ra));
>  }
> @@ -449,7 +449,7 @@ public class DriverAdapterCPDS implements 
> ConnectionPoolDataSource, Referenceabl
>  ref.add(new StringRefAddr("loginTimeout", 
> String.valueOf(getLoginTimeout(;
>  ref.add(new StringRefAddr(Constants.KEY_PASSWORD, getPassword()));
>  ref.add(new StringRefAddr(Constants.KEY_USER, getUser()));
> -ref.add(new StringRefAddr("connectionString", getUrl()));
> +ref.add(new StringRefAddr("url", getUrl()));
>
>  ref.add(new StringRefAddr("poolPreparedStatements", 
> String.valueOf(isPoolPreparedStatements(;
>  ref.add(new StringRefAddr("maxIdle", String.valueOf(getMaxIdle(;
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

Great news, Gary!

Very much appreciated.

Gruß
Richard

Am Donnerstag, dem 19.01.2023 um 06:11 -0500 schrieb Gary Gregory:
> Patience ;-) I am in the middle of releasing Commons Crypto. I can
> take a
> look this weekend and see what our options are...
> 
> Gary
> 
> On Thu, Jan 19, 2023, 04:42 Richard Zowalla  wrote:
> 
> > So what do we need to move forward with this once? :-)
> > 
> > Gruß
> > Richard
> > 
> > Am Sonntag, dem 01.01.2023 um 17:09 +0100 schrieb Jean-Baptiste
> > Onofré:
> > > It looks good to me.
> > > 
> > > Thanks,
> > > Regards
> > > JB
> > > 
> > > On Sat, Dec 31, 2022 at 12:15 PM Emmanuel Bourg <
> > > ebo...@apache.org>
> > > wrote:
> > > > I've experimented with another approach, a single version
> > > > supporting both javax.transaction and jakarta.transaction:
> > > > 
> > > >  
> > > > https://github.com/ebourg/commons-dbcp/tree/dual-javax-jakarta
> > > > 
> > > > The only classes using javax.transaction are in the
> > > > org.apache.commons.dbcp2.managed
> > > > package. This package is copied at build time to
> > > > org.apache.commons.dbcp2.managed.jakarta
> > > > with the javax imports replaced.
> > > > 
> > > > This solution is easier than maintaining two versions is
> > > > parallel.
> > > > 
> > > > What do you think?
> > > > 
> > > > Emmanuel Bourg
> > > > 
> > > > -
> > > > 
> > > > 
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > 
> > > 
> > > ---
> > > --
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > 


signature.asc
Description: This is a digitally signed message part

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Gary Gregory]

Patience ;-) I am in the middle of releasing Commons Crypto. I can take a
look this weekend and see what our options are...

Gary

On Thu, Jan 19, 2023, 04:42 Richard Zowalla  wrote:

> So what do we need to move forward with this once? :-)
>
> Gruß
> Richard
>
> Am Sonntag, dem 01.01.2023 um 17:09 +0100 schrieb Jean-Baptiste Onofré:
> > It looks good to me.
> >
> > Thanks,
> > Regards
> > JB
> >
> > On Sat, Dec 31, 2022 at 12:15 PM Emmanuel Bourg 
> > wrote:
> > > I've experimented with another approach, a single version
> > > supporting both javax.transaction and jakarta.transaction:
> > >
> > >  https://github.com/ebourg/commons-dbcp/tree/dual-javax-jakarta
> > >
> > > The only classes using javax.transaction are in the
> > > org.apache.commons.dbcp2.managed
> > > package. This package is copied at build time to
> > > org.apache.commons.dbcp2.managed.jakarta
> > > with the javax imports replaced.
> > >
> > > This solution is easier than maintaining two versions is parallel.
> > >
> > > What do you think?
> > >
> > > Emmanuel Bourg
> > >
> > > -
> > > 
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

So what do we need to move forward with this once? :-)

Gruß
Richard

Am Sonntag, dem 01.01.2023 um 17:09 +0100 schrieb Jean-Baptiste Onofré:
> It looks good to me.
> 
> Thanks,
> Regards
> JB
> 
> On Sat, Dec 31, 2022 at 12:15 PM Emmanuel Bourg 
> wrote:
> > I've experimented with another approach, a single version
> > supporting both javax.transaction and jakarta.transaction:
> > 
> >  https://github.com/ebourg/commons-dbcp/tree/dual-javax-jakarta
> > 
> > The only classes using javax.transaction are in the
> > org.apache.commons.dbcp2.managed
> > package. This package is copied at build time to
> > org.apache.commons.dbcp2.managed.jakarta
> > with the javax imports replaced.
> > 
> > This solution is easier than maintaining two versions is parallel.
> > 
> > What do you think?
> > 
> > Emmanuel Bourg
> > 
> > -
> > 
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> > 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


signature.asc
Description: This is a digitally signed message part

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Jean-Baptiste Onofré]

It looks good to me.

Thanks,
Regards
JB

On Sat, Dec 31, 2022 at 12:15 PM Emmanuel Bourg  wrote:
>
> I've experimented with another approach, a single version
> supporting both javax.transaction and jakarta.transaction:
>
>  https://github.com/ebourg/commons-dbcp/tree/dual-javax-jakarta
>
> The only classes using javax.transaction are in the 
> org.apache.commons.dbcp2.managed
> package. This package is copied at build time to 
> org.apache.commons.dbcp2.managed.jakarta
> with the javax imports replaced.
>
> This solution is easier than maintaining two versions is parallel.
>
> What do you think?
>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

Sounds good to me. Ultilately this managed package could also disappear I
guess since it was mainly for geronimo and tomee which disappeared or dont
use it anymore.

Le sam. 31 déc. 2022 à 12:25, Richard Zowalla  a écrit :

> I guess, that it would need some tests to show, that it is working
> correctly? Otherwise it would raise similar concerns as for the PR
> using Maven Shading to achieve the transition.
>
> Gruß
> Richard
>
> P.S. Build is currently failing for that one.
>
>
> Am Samstag, dem 31.12.2022 um 12:15 +0100 schrieb Emmanuel Bourg:
> > I've experimented with another approach, a single version
> > supporting both javax.transaction and jakarta.transaction:
> >
> >  https://github.com/ebourg/commons-dbcp/tree/dual-javax-jakarta
> >
> > The only classes using javax.transaction are in the
> > org.apache.commons.dbcp2.managed
> > package. This package is copied at build time to
> > org.apache.commons.dbcp2.managed.jakarta
> > with the javax imports replaced.
> >
> > This solution is easier than maintaining two versions is parallel.
> >
> > What do you think?
> >
> > Emmanuel Bourg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

I guess, that it would need some tests to show, that it is working
correctly? Otherwise it would raise similar concerns as for the PR
using Maven Shading to achieve the transition. 

Gruß
Richard

P.S. Build is currently failing for that one.


Am Samstag, dem 31.12.2022 um 12:15 +0100 schrieb Emmanuel Bourg:
> I've experimented with another approach, a single version
> supporting both javax.transaction and jakarta.transaction:
> 
>  https://github.com/ebourg/commons-dbcp/tree/dual-javax-jakarta
> 
> The only classes using javax.transaction are in the
> org.apache.commons.dbcp2.managed
> package. This package is copied at build time to
> org.apache.commons.dbcp2.managed.jakarta
> with the javax imports replaced.
> 
> This solution is easier than maintaining two versions is parallel.
> 
> What do you think?
> 
> Emmanuel Bourg
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Emmanuel Bourg]

I've experimented with another approach, a single version
supporting both javax.transaction and jakarta.transaction:

https://github.com/ebourg/commons-dbcp/tree/dual-javax-jakarta

The only classes using javax.transaction are in the 
org.apache.commons.dbcp2.managed
package. This package is copied at build time to 
org.apache.commons.dbcp2.managed.jakarta
with the javax imports replaced.

This solution is easier than maintaining two versions is parallel.

What do you think?

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

Thanks a lot, Emmanuel! 

It looks good to me!

Gruß
Richard


Am Donnerstag, dem 29.12.2022 um 22:02 +0100 schrieb Emmanuel Bourg:
> Thank you, it works perfectly now.
> 
> I've pushed the changes to:
> 
>  https://github.com/ebourg/commons-dbcp/tree/jakarta
> 
> Comments are welcome before I create a dbcp3 branch on the ASF
> repository.
> 
> I think the API should be kept identical to dbcp2 to ease porting 
> changes and facilitate migrations. So no removal of deprecated
> methods 
> before dbcp4.
> 
> Emmanuel Bourg
> 
> 
> On 28/12/2022 19:22, Romain Manni-Bucau wrote:
> > Hi Emmanuel,
> > 
> > You have
> > https://repo1.maven.org/maven2/org/apache/geronimo/components/geronimo-transaction/3.1.5/geronimo-transaction-3.1.5-jakarta.jar
> > which is usable if you exclude transitive deps.
> > 
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> > https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

Le jeu. 29 déc. 2022 à 22:02, Emmanuel Bourg  a écrit :

> Thank you, it works perfectly now.
>
> I've pushed the changes to:
>
>  https://github.com/ebourg/commons-dbcp/tree/jakarta





>
> Comments are welcome before I create a dbcp3 branch on the ASF repository.
>
> I think the API should be kept identical to dbcp2 to ease porting
> changes and facilitate migrations. So no removal of deprecated methods
> before dbcp4.
>

If it helps: jakarta broke its api anyway so apps are rarely 1-1 so can be
the opportunity to do it anyway if you have changes in minds?


> Emmanuel Bourg
>
>
> On 28/12/2022 19:22, Romain Manni-Bucau wrote:
> > Hi Emmanuel,
> >
> > You have
> >
> https://repo1.maven.org/maven2/org/apache/geronimo/components/geronimo-transaction/3.1.5/geronimo-transaction-3.1.5-jakarta.jar
> > which is usable if you exclude transitive deps.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Emmanuel Bourg]

Thank you, it works perfectly now.

I've pushed the changes to:

https://github.com/ebourg/commons-dbcp/tree/jakarta

Comments are welcome before I create a dbcp3 branch on the ASF repository.

I think the API should be kept identical to dbcp2 to ease porting 
changes and facilitate migrations. So no removal of deprecated methods 
before dbcp4.


Emmanuel Bourg


On 28/12/2022 19:22, Romain Manni-Bucau wrote:

Hi Emmanuel,

You have
https://repo1.maven.org/maven2/org/apache/geronimo/components/geronimo-transaction/3.1.5/geronimo-transaction-3.1.5-jakarta.jar
which is usable if you exclude transitive deps.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

Hi Emmanuel,

You have
https://repo1.maven.org/maven2/org/apache/geronimo/components/geronimo-transaction/3.1.5/geronimo-transaction-3.1.5-jakarta.jar
which is usable if you exclude transitive deps.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 28 déc. 2022 à 19:09, Emmanuel Bourg  a écrit :

> Thank you for the pointers, the Narayana and JBoss artifacts look good,
> but I haven't found a replacement for geronimo-transaction. I tried
> replacing the Geronimo Transaction implementation with the one from
> Narayana but got 4 test failures.
>
> I'll try to process the geronimo-transaction jar at build time and see
> how it works.
>
> Emmanuel Bourg
>
> Le 28/12/2022 à 07:24, Richard Zowalla a écrit :
> > There is a Jakarta artifact available for Narayana: narayana-jta-jakarta
> >
> > For the SPI: jboss-transaction-spi-jakarta
> >
> > (because JBoss plays the namespace game with their app server ;-) )
> >
> > Geronimo most likely also provides a Jakarta version or (if it is only
> API) can be replaced by the Jakarta artifact.
> >
> > Gruß
> > Richard
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Emmanuel Bourg]

Thank you for the pointers, the Narayana and JBoss artifacts look good, 
but I haven't found a replacement for geronimo-transaction. I tried 
replacing the Geronimo Transaction implementation with the one from 
Narayana but got 4 test failures.


I'll try to process the geronimo-transaction jar at build time and see 
how it works.


Emmanuel Bourg

Le 28/12/2022 à 07:24, Richard Zowalla a écrit :

There is a Jakarta artifact available for Narayana: narayana-jta-jakarta

For the SPI: jboss-transaction-spi-jakarta

(because JBoss plays the namespace game with their app server ;-) )

Geronimo most likely also provides a Jakarta version or (if it is only API) can 
be replaced by the Jakarta artifact.

Gruß
Richard




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

@Gary as mentionned there are matches but also notice several vendors
(most) abandonned the game due to the new governance so dont expect as much
choices as before.

Le mer. 28 déc. 2022 à 07:24, Richard Zowalla  a
écrit :

> There is a Jakarta artifact available for Narayana: narayana-jta-jakarta
>
> For the SPI: jboss-transaction-spi-jakarta
>
> (because JBoss plays the namespace game with their app server ;-) )
>
> Geronimo most likely also provides a Jakarta version or (if it is only
> API) can be replaced by the Jakarta artifact.
>
> Gruß
> Richard
>
>
> Am 27. Dezember 2022 22:54:40 MEZ schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>>
>> @Emmanuel Bourg  you can use jakarta artifacts directly
>> for dbcp or tomee ones which provides jakarta namespace.
>>
>> Le mar. 27 déc. 2022 à 22:28, Emmanuel Bourg  a écrit :
>>
>>  I tried to replace javax with jakarta in DBCP, the less trivial part is
>>>  to find a replacement for the test dependencies:
>>>  - org.apache.geronimo.modules:geronimo-transaction
>>>  - org.jboss.narayana.jta:narayana-jta
>>>  - and maybe org.jboss:jboss-transaction-spi
>>>
>>>  Or we disable the transaction tests temporarily to publish quickly a
>>>  Jakarta variant.
>>>
>>>  Emmanuel Bourg
>>> --
>>>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>  For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

There is a Jakarta artifact available for Narayana: narayana-jta-jakarta

For the SPI: jboss-transaction-spi-jakarta

(because JBoss plays the namespace game with their app server ;-) )

Geronimo most likely also provides a Jakarta version or (if it is only API) can 
be replaced by the Jakarta artifact.

Gruß
Richard 


Am 27. Dezember 2022 22:54:40 MEZ schrieb Romain Manni-Bucau 
:
>@Emmanuel Bourg  you can use jakarta artifacts directly
>for dbcp or tomee ones which provides jakarta namespace.
>
>Le mar. 27 déc. 2022 à 22:28, Emmanuel Bourg  a écrit :
>
>> I tried to replace javax with jakarta in DBCP, the less trivial part is
>> to find a replacement for the test dependencies:
>> - org.apache.geronimo.modules:geronimo-transaction
>> - org.jboss.narayana.jta:narayana-jta
>> - and maybe org.jboss:jboss-transaction-spi
>>
>> Or we disable the transaction tests temporarily to publish quickly a
>> Jakarta variant.
>>
>> Emmanuel Bourg
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Gary Gregory]

There is non point in doing this "quickly", if there is no match in the
namespace game for the test dependencies, it only goes to prove that the
whole ecosystem has not progressed far enough or is mature enough.

Gary

On Tue, Dec 27, 2022, 16:28 Emmanuel Bourg  wrote:

> I tried to replace javax with jakarta in DBCP, the less trivial part is
> to find a replacement for the test dependencies:
> - org.apache.geronimo.modules:geronimo-transaction
> - org.jboss.narayana.jta:narayana-jta
> - and maybe org.jboss:jboss-transaction-spi
>
> Or we disable the transaction tests temporarily to publish quickly a
> Jakarta variant.
>
> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

@Emmanuel Bourg  you can use jakarta artifacts directly
for dbcp or tomee ones which provides jakarta namespace.

Le mar. 27 déc. 2022 à 22:28, Emmanuel Bourg  a écrit :

> I tried to replace javax with jakarta in DBCP, the less trivial part is
> to find a replacement for the test dependencies:
> - org.apache.geronimo.modules:geronimo-transaction
> - org.jboss.narayana.jta:narayana-jta
> - and maybe org.jboss:jboss-transaction-spi
>
> Or we disable the transaction tests temporarily to publish quickly a
> Jakarta variant.
>
> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Emmanuel Bourg]

I tried to replace javax with jakarta in DBCP, the less trivial part is 
to find a replacement for the test dependencies:

- org.apache.geronimo.modules:geronimo-transaction
- org.jboss.narayana.jta:narayana-jta
- and maybe org.jboss:jboss-transaction-spi

Or we disable the transaction tests temporarily to publish quickly a 
Jakarta variant.


Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

@Gary: I agree with the plan but as Romain outlined, it requires some
details / perspective.

Am Montag, dem 19.12.2022 um 21:33 +0100 schrieb Romain Manni-Bucau:
> @gary: you likely need to refine your plan to make it a plan and not
> a
> discussion proposal, ie put some date. If you want to release dbcp2
> this
> year and move to dbcp3 in january for a 1.0.0 (or whatever version)
> in
> early february I guess it works for everyone. If it is about waiting
> 1-2
> months to get 2 out, 3-4 months to get 3 out it means we loose one
> more
> year in terms of adoption and I guess we would be closer to my point
> that
> dbcp will never met jakarta as of today where hikaricp and tomcat-
> jdbc are
> used by default when upgrading stacks since jakarta adoption will
> accelerate next year with spring 6 hard move and related migrations.
> If it
> is the kind of time frame I guess the relocation - shade or tomcat
> tool -
> will be a better option for commons and the project (it is the option
> geronimo/openwebbeans/meecrowave/tomee adopted with success to ensure
> a
> single branch was to maintain before the final switch which should
> occur
> when javax branch is definitively dead for end users - should happen
> in a
> few years, maybe 2-3 due to first jakarta release time and usual
> adoption
> rate).
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-perfor
> mance>
> 
> 
> Le lun. 19 déc. 2022 à 21:23, Gary Gregory  a
> écrit :
> 
> > I feel like we're going around in circles. Do you not agree my the
> > path I previously outlined?
> > 
> > Gary
> > 
> > On Mon, Dec 19, 2022 at 2:12 PM Richard Zowalla 
> > wrote:
> > > 
> > > I can only say, that I fully agree with Romain here.
> > > 
> > > For example, we are shading dbcp2 with jakarta.* relocations in
> > > TomEE 9
> > (targeting EE9.1 / jakarta.*). I don't think, that it is a good
> > thing to
> > let the users fork/relocate or abandon dbcp2 in order to be able to
> > use the
> > jakarta.* namespace.
> > > 
> > > The EE ecosystem is moving and if we want to play a role in it,
> > > we need
> > to adapt a bit. That said, it isn't a huge effort to migrate /
> > create a
> > version to support jakarta.*
> > > 
> > > IMHO it is only a matter of available resources / time and
> > people/volunteers who want to contribute / help to make it happen.
> > If it
> > requires to make a dbcp3 due to commons rule set (binary compat)
> > and
> > relocation isn't an option, so be it.
> > > 
> > > Nevertheless, I would appreciate some perspective, so we can deal
> > > with
> > it on our side :-) (and as already said: I am happy to help /
> > contribute,
> > if needed)
> > > 
> > > Gruß
> > > Richard
> > > 
> > > 
> > > 
> > > On 2022/12/18 16:08:57 Romain Manni-Bucau wrote:
> > > > Le dim. 18 déc. 2022 à 12:04, Gary Gregory
> > > >  a
> > > > écrit :
> > > > 
> > > > > What's the rush? Commons has never been on the bleeding edge
> > > > > of
> > anything.
> > > > > 
> > > > 
> > > > 
> > > > Java and EE release rates changed - as well as spring baseline.
> > > > If
> > commons
> > > > sticks to the old one it is harder (impossible) to use
> > > > directly.
> > > > Today dbcp is either forked/relocated or abandonned for that
> > > > reason so
> > > > guess we should either adapt the release rate and testing
> > > > coverage to
> > these
> > > > changes or freeze the project if it is no more matching end
> > > > users envs.
> > > > 
> > > > 
> > > > You saw the plan I proposed I presume.
> > > > > 
> > > > 
> > > > Yep but with no (even vague) date it does not mean much to me,
> > > > just "we
> > > > dont care of last two majors of EE" until something happens.
> > > > This is why I ask what does mean a little and when dbcp3 would
> > > > be a
> > thing.
> > > > Would also be important to document it and maybe reco

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

@gary: you likely need to refine your plan to make it a plan and not a
discussion proposal, ie put some date. If you want to release dbcp2 this
year and move to dbcp3 in january for a 1.0.0 (or whatever version) in
early february I guess it works for everyone. If it is about waiting 1-2
months to get 2 out, 3-4 months to get 3 out it means we loose one more
year in terms of adoption and I guess we would be closer to my point that
dbcp will never met jakarta as of today where hikaricp and tomcat-jdbc are
used by default when upgrading stacks since jakarta adoption will
accelerate next year with spring 6 hard move and related migrations. If it
is the kind of time frame I guess the relocation - shade or tomcat tool -
will be a better option for commons and the project (it is the option
geronimo/openwebbeans/meecrowave/tomee adopted with success to ensure a
single branch was to maintain before the final switch which should occur
when javax branch is definitively dead for end users - should happen in a
few years, maybe 2-3 due to first jakarta release time and usual adoption
rate).

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 19 déc. 2022 à 21:23, Gary Gregory  a
écrit :

> I feel like we're going around in circles. Do you not agree my the
> path I previously outlined?
>
> Gary
>
> On Mon, Dec 19, 2022 at 2:12 PM Richard Zowalla  wrote:
> >
> > I can only say, that I fully agree with Romain here.
> >
> > For example, we are shading dbcp2 with jakarta.* relocations in TomEE 9
> (targeting EE9.1 / jakarta.*). I don't think, that it is a good thing to
> let the users fork/relocate or abandon dbcp2 in order to be able to use the
> jakarta.* namespace.
> >
> > The EE ecosystem is moving and if we want to play a role in it, we need
> to adapt a bit. That said, it isn't a huge effort to migrate / create a
> version to support jakarta.*
> >
> > IMHO it is only a matter of available resources / time and
> people/volunteers who want to contribute / help to make it happen. If it
> requires to make a dbcp3 due to commons rule set (binary compat) and
> relocation isn't an option, so be it.
> >
> > Nevertheless, I would appreciate some perspective, so we can deal with
> it on our side :-) (and as already said: I am happy to help / contribute,
> if needed)
> >
> > Gruß
> > Richard
> >
> >
> >
> > On 2022/12/18 16:08:57 Romain Manni-Bucau wrote:
> > > Le dim. 18 déc. 2022 à 12:04, Gary Gregory  a
> > > écrit :
> > >
> > > > What's the rush? Commons has never been on the bleeding edge of
> anything.
> > > >
> > >
> > >
> > > Java and EE release rates changed - as well as spring baseline. If
> commons
> > > sticks to the old one it is harder (impossible) to use directly.
> > > Today dbcp is either forked/relocated or abandonned for that reason so
> > > guess we should either adapt the release rate and testing coverage to
> these
> > > changes or freeze the project if it is no more matching end users envs.
> > >
> > >
> > > You saw the plan I proposed I presume.
> > > >
> > >
> > > Yep but with no (even vague) date it does not mean much to me, just "we
> > > dont care of last two majors of EE" until something happens.
> > > This is why I ask what does mean a little and when dbcp3 would be a
> thing.
> > > Would also be important to document it and maybe recommend tomcat-jdbc
> for
> > > user until we support jakarta.
> > >
> > >
> > >
> > > > Gary
> > > >
> > > >
> > > > On Sun, Dec 18, 2022, 04:38 Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > Any idea on when it can occurs? We are quite late to the party
> already
> > > > and
> > > > > shade was a good solution to be in without additional cost in
> terms of
> > > > > maintainance for the project so if not the picked option we should
> target
> > > > > some point not too far in 2023 pby.
> > > > >
> > > > > Le dim. 18 déc. 2022 à 01:44, Gary Gregory 
> a
> > > > > écrit :
> > > > >
> > > > > > Hi Arun,
> > > > > >
> > > > > > T

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Gary Gregory]

I feel like we're going around in circles. Do you not agree my the
path I previously outlined?

Gary

On Mon, Dec 19, 2022 at 2:12 PM Richard Zowalla  wrote:
>
> I can only say, that I fully agree with Romain here.
>
> For example, we are shading dbcp2 with jakarta.* relocations in TomEE 9 
> (targeting EE9.1 / jakarta.*). I don't think, that it is a good thing to let 
> the users fork/relocate or abandon dbcp2 in order to be able to use the 
> jakarta.* namespace.
>
> The EE ecosystem is moving and if we want to play a role in it, we need to 
> adapt a bit. That said, it isn't a huge effort to migrate / create a version 
> to support jakarta.*
>
> IMHO it is only a matter of available resources / time and people/volunteers 
> who want to contribute / help to make it happen. If it requires to make a 
> dbcp3 due to commons rule set (binary compat) and relocation isn't an option, 
> so be it.
>
> Nevertheless, I would appreciate some perspective, so we can deal with it on 
> our side :-) (and as already said: I am happy to help / contribute, if needed)
>
> Gruß
> Richard
>
>
>
> On 2022/12/18 16:08:57 Romain Manni-Bucau wrote:
> > Le dim. 18 déc. 2022 à 12:04, Gary Gregory  a
> > écrit :
> >
> > > What's the rush? Commons has never been on the bleeding edge of anything.
> > >
> >
> >
> > Java and EE release rates changed - as well as spring baseline. If commons
> > sticks to the old one it is harder (impossible) to use directly.
> > Today dbcp is either forked/relocated or abandonned for that reason so
> > guess we should either adapt the release rate and testing coverage to these
> > changes or freeze the project if it is no more matching end users envs.
> >
> >
> > You saw the plan I proposed I presume.
> > >
> >
> > Yep but with no (even vague) date it does not mean much to me, just "we
> > dont care of last two majors of EE" until something happens.
> > This is why I ask what does mean a little and when dbcp3 would be a thing.
> > Would also be important to document it and maybe recommend tomcat-jdbc for
> > user until we support jakarta.
> >
> >
> >
> > > Gary
> > >
> > >
> > > On Sun, Dec 18, 2022, 04:38 Romain Manni-Bucau 
> > > wrote:
> > >
> > > > Any idea on when it can occurs? We are quite late to the party already
> > > and
> > > > shade was a good solution to be in without additional cost in terms of
> > > > maintainance for the project so if not the picked option we should 
> > > > target
> > > > some point not too far in 2023 pby.
> > > >
> > > > Le dim. 18 déc. 2022 à 01:44, Gary Gregory  a
> > > > écrit :
> > > >
> > > > > Hi Arun,
> > > > >
> > > > > There's not going to be anything to pick up for a while ;-)
> > > > >
> > > > > Gary
> > > > >
> > > > > On Sat, Dec 17, 2022, 18:06 Arun Avanathan 
> > > > > wrote:
> > > > >
> > > > > > Gary - if we have a ticket to upgrade DBCP to java 11, I can take it
> > > > up.
> > > > > >
> > > > > > > On Dec 17, 2022, at 1:09 PM, Richard Zowalla 
> > > > > > wrote:
> > > > > > >
> > > > > > > Sure. Sounds like a plan :)
> > > > > > >
> > > > > > > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory <
> > > > > > garydgreg...@gmail.com>:
> > > > > > >> I think we should wait for a little while: I'd want to release
> > > > current
> > > > > > code
> > > > > > >> from git for Commons Pool, then DBCP (which sits on top of Pool),
> > > > make
> > > > > > sure
> > > > > > >> all is well, then see about going to DBCP 3, on Java 8 for now 
> > > > > > >> but
> > > > > > >> considering Java 11 maybe. Do consider that the Commons community
> > > is
> > > > > > small
> > > > > > >> and I would not want to support concurrent support and releases 
> > > > > > >> on
> > > > > bothe
> > > > > > >> DBCP 2 and 3.
> > > > > > >>
> > > > > > >> Gary
> > > > > > >>
> > > > > > >> Gary
> > > > > > >>
> > > >

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

I can only say, that I fully agree with Romain here.

For example, we are shading dbcp2 with jakarta.* relocations in TomEE 9 
(targeting EE9.1 / jakarta.*). I don't think, that it is a good thing to let 
the users fork/relocate or abandon dbcp2 in order to be able to use the 
jakarta.* namespace.

The EE ecosystem is moving and if we want to play a role in it, we need to 
adapt a bit. That said, it isn't a huge effort to migrate / create a version to 
support jakarta.* 

IMHO it is only a matter of available resources / time and people/volunteers 
who want to contribute / help to make it happen. If it requires to make a dbcp3 
due to commons rule set (binary compat) and relocation isn't an option, so be 
it. 

Nevertheless, I would appreciate some perspective, so we can deal with it on 
our side :-) (and as already said: I am happy to help / contribute, if needed)

Gruß
Richard

 

On 2022/12/18 16:08:57 Romain Manni-Bucau wrote:
> Le dim. 18 déc. 2022 à 12:04, Gary Gregory  a
> écrit :
> 
> > What's the rush? Commons has never been on the bleeding edge of anything.
> >
> 
> 
> Java and EE release rates changed - as well as spring baseline. If commons
> sticks to the old one it is harder (impossible) to use directly.
> Today dbcp is either forked/relocated or abandonned for that reason so
> guess we should either adapt the release rate and testing coverage to these
> changes or freeze the project if it is no more matching end users envs.
> 
> 
> You saw the plan I proposed I presume.
> >
> 
> Yep but with no (even vague) date it does not mean much to me, just "we
> dont care of last two majors of EE" until something happens.
> This is why I ask what does mean a little and when dbcp3 would be a thing.
> Would also be important to document it and maybe recommend tomcat-jdbc for
> user until we support jakarta.
> 
> 
> 
> > Gary
> >
> >
> > On Sun, Dec 18, 2022, 04:38 Romain Manni-Bucau 
> > wrote:
> >
> > > Any idea on when it can occurs? We are quite late to the party already
> > and
> > > shade was a good solution to be in without additional cost in terms of
> > > maintainance for the project so if not the picked option we should target
> > > some point not too far in 2023 pby.
> > >
> > > Le dim. 18 déc. 2022 à 01:44, Gary Gregory  a
> > > écrit :
> > >
> > > > Hi Arun,
> > > >
> > > > There's not going to be anything to pick up for a while ;-)
> > > >
> > > > Gary
> > > >
> > > > On Sat, Dec 17, 2022, 18:06 Arun Avanathan 
> > > > wrote:
> > > >
> > > > > Gary - if we have a ticket to upgrade DBCP to java 11, I can take it
> > > up.
> > > > >
> > > > > > On Dec 17, 2022, at 1:09 PM, Richard Zowalla 
> > > > > wrote:
> > > > > >
> > > > > > Sure. Sounds like a plan :)
> > > > > >
> > > > > > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory <
> > > > > garydgreg...@gmail.com>:
> > > > > >> I think we should wait for a little while: I'd want to release
> > > current
> > > > > code
> > > > > >> from git for Commons Pool, then DBCP (which sits on top of Pool),
> > > make
> > > > > sure
> > > > > >> all is well, then see about going to DBCP 3, on Java 8 for now but
> > > > > >> considering Java 11 maybe. Do consider that the Commons community
> > is
> > > > > small
> > > > > >> and I would not want to support concurrent support and releases on
> > > > bothe
> > > > > >> DBCP 2 and 3.
> > > > > >>
> > > > > >> Gary
> > > > > >>
> > > > > >> Gary
> > > > > >>
> > > > > >>> On Sat, Dec 17, 2022, 14:12 Richard Zowalla 
> > > wrote:
> > > > > >>>
> > > > > >>> For DBCP, it basically boils down to
> > > > > >>>
> > > > > >>> BasicManagedDataSource.java
> > > > > >>> DataSourceXAConnectionFactory.java
> > > > > >>> LocalXAConnectionFactory.java
> > > > > >>> SynchronizationAdapter.java
> > > > > >>> TransactionContext.java
> > > > > >>> TransactionRegistry.java
> > > > > >>>
> > > > > >>> Looking at these classes, the 

Re: Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

Le lun. 19 déc. 2022 à 16:25, Eric Bresie  a écrit :

> I’ve not used it so not sure but would this help any in migrating the
> namespace?
>
> https://github.com/apache/tomcat-jakartaee-migration


It is strictly equivalent to the shade option but requires maven build
helper plugin to attach the relocated artifact so not sure since we fall in
the same option categories.


>
>
> Eric Bresie
> ebre...@gmail.com (mailto:ebre...@gmail.com)
>
> > On December 17, 2022 at 3:08:47 PM CST, Richard Zowalla <
> rich...@zowalla.com (mailto:rich...@zowalla.com)> wrote:
> > Sure. Sounds like a plan :)
> >
> > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory <
> garydgreg...@gmail.com (mailto:garydgreg...@gmail.com)>:
> > > I think we should wait for a little while: I'd want to release current
> code
> > > from git for Commons Pool, then DBCP (which sits on top of Pool), make
> sure
> > > all is well, then see about going to DBCP 3, on Java 8 for now but
> > > considering Java 11 maybe. Do consider that the Commons community is
> small
> > > and I would not want to support concurrent support and releases on
> bothe
> > > DBCP 2 and 3.
> > >
> > > Gary
> > >
> > > Gary
> > >
> > > On Sat, Dec 17, 2022, 14:12 Richard Zowalla  r...@apache.org)> wrote:
> > >
> > > > For DBCP, it basically boils down to
> > > >
> > > > BasicManagedDataSource.java
> > > > DataSourceXAConnectionFactory.java
> > > > LocalXAConnectionFactory.java
> > > > SynchronizationAdapter.java
> > > > TransactionContext.java
> > > > TransactionRegistry.java
> > > >
> > > > Looking at these classes, the move to jakarta definitley affects
> binary
> > > > compatibility as we have changes in return types / arguments of
> public
> > > > methods. Given that it breaks binary compatibility, we could even
> > > > increase the java level to 11 and drop deprecated things in a
> potential
> > > > dbcp 3.
> > > >
> > > > In the end, I am happy with everything, which brings DBCP into the
> > > > Jakarta world ;)
> > > >
> > > > If we have consensus for a route, I am happy to work on it / make it
> > > > happen via related PRs but would need some guideance on the best way
> to
> > > > move forward.
> > > >
> > > > Gruß
> > > > Richard
> > > >
> > > > Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain Manni-Bucau:
> > > > > If not done in new classes (both can live in the same lib
> > > > > technically),
> > > > > sadly yes.
> > > > >
> > > > > Le ven. 16 déc. 2022 à 20:14, Richard Zowalla  (mailto:rich...@zowalla.com)> a
> > > > > écrit :
> > > > >
> > > > > > Thanks for your replies.
> > > > > >
> > > > > > I guess, that switching the namespace leads to binary
> > > > > > incompatibility (If
> > > > > > I take the definition from [1]). I cannot drop it in a running
> JVM
> > > > > > / app
> > > > > > and expect no issues with it as the related APIs are breaking
> > > > > > namespace
> > > > > > changes (at least at runtime if they aren't present) :-)
> > > > > >
> > > > > > Aside from that fact, method signatures might also change from
> > > > > > javax ->
> > > > > > jakarta, which would require a short investigation and usage of
> the
> > > > > > existing tooling to see if this happens.
> > > > > >
> > > > > > From a commons point of view that would mean to go for dbcp3,
> > > > > > right?
> > > > > >
> > > > > > Gruß
> > > > > > Richard
> > > > > >
> > > > > > [1]
> > > > > >
> > > >
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> > > > > >
> > > > > > Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
> > > > > > mailto:ma...@apache.org)>:
> > > > > > > On 16/12/2022 13:24, Gary Gregory wrote:
> > > > > > > > Thank you Richard for starting this thread.
> > > > > > > >
> > > > > > > > M

Re: Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Eric Bresie]

I’ve not used it so not sure but would this help any in migrating the namespace?

https://github.com/apache/tomcat-jakartaee-migration

Eric Bresie
ebre...@gmail.com (mailto:ebre...@gmail.com)

> On December 17, 2022 at 3:08:47 PM CST, Richard Zowalla  (mailto:rich...@zowalla.com)> wrote:
> Sure. Sounds like a plan :)
>
> Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory 
> mailto:garydgreg...@gmail.com)>:
> > I think we should wait for a little while: I'd want to release current code
> > from git for Commons Pool, then DBCP (which sits on top of Pool), make sure
> > all is well, then see about going to DBCP 3, on Java 8 for now but
> > considering Java 11 maybe. Do consider that the Commons community is small
> > and I would not want to support concurrent support and releases on bothe
> > DBCP 2 and 3.
> >
> > Gary
> >
> > Gary
> >
> > On Sat, Dec 17, 2022, 14:12 Richard Zowalla  > (mailto:r...@apache.org)> wrote:
> >
> > > For DBCP, it basically boils down to
> > >
> > > BasicManagedDataSource.java
> > > DataSourceXAConnectionFactory.java
> > > LocalXAConnectionFactory.java
> > > SynchronizationAdapter.java
> > > TransactionContext.java
> > > TransactionRegistry.java
> > >
> > > Looking at these classes, the move to jakarta definitley affects binary
> > > compatibility as we have changes in return types / arguments of public
> > > methods. Given that it breaks binary compatibility, we could even
> > > increase the java level to 11 and drop deprecated things in a potential
> > > dbcp 3.
> > >
> > > In the end, I am happy with everything, which brings DBCP into the
> > > Jakarta world ;)
> > >
> > > If we have consensus for a route, I am happy to work on it / make it
> > > happen via related PRs but would need some guideance on the best way to
> > > move forward.
> > >
> > > Gruß
> > > Richard
> > >
> > > Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain Manni-Bucau:
> > > > If not done in new classes (both can live in the same lib
> > > > technically),
> > > > sadly yes.
> > > >
> > > > Le ven. 16 déc. 2022 à 20:14, Richard Zowalla  > > > (mailto:rich...@zowalla.com)> a
> > > > écrit :
> > > >
> > > > > Thanks for your replies.
> > > > >
> > > > > I guess, that switching the namespace leads to binary
> > > > > incompatibility (If
> > > > > I take the definition from [1]). I cannot drop it in a running JVM
> > > > > / app
> > > > > and expect no issues with it as the related APIs are breaking
> > > > > namespace
> > > > > changes (at least at runtime if they aren't present) :-)
> > > > >
> > > > > Aside from that fact, method signatures might also change from
> > > > > javax ->
> > > > > jakarta, which would require a short investigation and usage of the
> > > > > existing tooling to see if this happens.
> > > > >
> > > > > From a commons point of view that would mean to go for dbcp3,
> > > > > right?
> > > > >
> > > > > Gruß
> > > > > Richard
> > > > >
> > > > > [1]
> > > > >
> > > https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> > > > >
> > > > > Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
> > > > > mailto:ma...@apache.org)>:
> > > > > > On 16/12/2022 13:24, Gary Gregory wrote:
> > > > > > > Thank you Richard for starting this thread.
> > > > > > >
> > > > > > > My view is simpler perhaps: I would not make this about the
> > > > > > > javax vs
> > > > > > > Jakarta namespaces.
> > > > > > >
> > > > > > > I don't want to double the numbers of jars we produce from the
> > > > > > > same
> > > > > branch
> > > > > > > for affected components as one of the scheme proposed. It feels
> > > > > > > like a
> > > > > > > burden to maintenance moving forward and a very brittle process
> > > > > > > with
> > > > > some
> > > > > > > unforeseen side effects.
> > > > > > &g

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

Le dim. 18 déc. 2022 à 12:04, Gary Gregory  a
écrit :

> What's the rush? Commons has never been on the bleeding edge of anything.
>


Java and EE release rates changed - as well as spring baseline. If commons
sticks to the old one it is harder (impossible) to use directly.
Today dbcp is either forked/relocated or abandonned for that reason so
guess we should either adapt the release rate and testing coverage to these
changes or freeze the project if it is no more matching end users envs.


You saw the plan I proposed I presume.
>

Yep but with no (even vague) date it does not mean much to me, just "we
dont care of last two majors of EE" until something happens.
This is why I ask what does mean a little and when dbcp3 would be a thing.
Would also be important to document it and maybe recommend tomcat-jdbc for
user until we support jakarta.



> Gary
>
>
> On Sun, Dec 18, 2022, 04:38 Romain Manni-Bucau 
> wrote:
>
> > Any idea on when it can occurs? We are quite late to the party already
> and
> > shade was a good solution to be in without additional cost in terms of
> > maintainance for the project so if not the picked option we should target
> > some point not too far in 2023 pby.
> >
> > Le dim. 18 déc. 2022 à 01:44, Gary Gregory  a
> > écrit :
> >
> > > Hi Arun,
> > >
> > > There's not going to be anything to pick up for a while ;-)
> > >
> > > Gary
> > >
> > > On Sat, Dec 17, 2022, 18:06 Arun Avanathan 
> > > wrote:
> > >
> > > > Gary - if we have a ticket to upgrade DBCP to java 11, I can take it
> > up.
> > > >
> > > > > On Dec 17, 2022, at 1:09 PM, Richard Zowalla 
> > > > wrote:
> > > > >
> > > > > Sure. Sounds like a plan :)
> > > > >
> > > > > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory <
> > > > garydgreg...@gmail.com>:
> > > > >> I think we should wait for a little while: I'd want to release
> > current
> > > > code
> > > > >> from git for Commons Pool, then DBCP (which sits on top of Pool),
> > make
> > > > sure
> > > > >> all is well, then see about going to DBCP 3, on Java 8 for now but
> > > > >> considering Java 11 maybe. Do consider that the Commons community
> is
> > > > small
> > > > >> and I would not want to support concurrent support and releases on
> > > bothe
> > > > >> DBCP 2 and 3.
> > > > >>
> > > > >> Gary
> > > > >>
> > > > >> Gary
> > > > >>
> > > > >>> On Sat, Dec 17, 2022, 14:12 Richard Zowalla 
> > wrote:
> > > > >>>
> > > > >>> For DBCP, it basically boils down to
> > > > >>>
> > > > >>> BasicManagedDataSource.java
> > > > >>> DataSourceXAConnectionFactory.java
> > > > >>> LocalXAConnectionFactory.java
> > > > >>> SynchronizationAdapter.java
> > > > >>> TransactionContext.java
> > > > >>> TransactionRegistry.java
> > > > >>>
> > > > >>> Looking at these classes, the move to jakarta definitley affects
> > > binary
> > > > >>> compatibility as we have changes in return types / arguments of
> > > public
> > > > >>> methods. Given that it breaks binary compatibility, we could even
> > > > >>> increase the java level to 11 and drop deprecated things in a
> > > potential
> > > > >>> dbcp 3.
> > > > >>>
> > > > >>> In the end, I am happy with everything, which brings DBCP into
> the
> > > > >>> Jakarta world ;)
> > > > >>>
> > > > >>> If we have consensus for a route, I am happy to work on it / make
> > it
> > > > >>> happen via related PRs but would need some guideance on the best
> > way
> > > to
> > > > >>> move forward.
> > > > >>>
> > > > >>> Gruß
> > > > >>> Richard
> > > > >>>
> > > > >>> Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain
> > Manni-Bucau:
> > > > >>>> If not done in new classes (both can live in the same lib
> > > > >>>> technically),
> > > > >>>> sadly yes.
> > > &g

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Gary Gregory]

What's the rush? Commons has never been on the bleeding edge of anything.
You saw the plan I proposed I presume.

Gary


On Sun, Dec 18, 2022, 04:38 Romain Manni-Bucau 
wrote:

> Any idea on when it can occurs? We are quite late to the party already and
> shade was a good solution to be in without additional cost in terms of
> maintainance for the project so if not the picked option we should target
> some point not too far in 2023 pby.
>
> Le dim. 18 déc. 2022 à 01:44, Gary Gregory  a
> écrit :
>
> > Hi Arun,
> >
> > There's not going to be anything to pick up for a while ;-)
> >
> > Gary
> >
> > On Sat, Dec 17, 2022, 18:06 Arun Avanathan 
> > wrote:
> >
> > > Gary - if we have a ticket to upgrade DBCP to java 11, I can take it
> up.
> > >
> > > > On Dec 17, 2022, at 1:09 PM, Richard Zowalla 
> > > wrote:
> > > >
> > > > Sure. Sounds like a plan :)
> > > >
> > > > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory <
> > > garydgreg...@gmail.com>:
> > > >> I think we should wait for a little while: I'd want to release
> current
> > > code
> > > >> from git for Commons Pool, then DBCP (which sits on top of Pool),
> make
> > > sure
> > > >> all is well, then see about going to DBCP 3, on Java 8 for now but
> > > >> considering Java 11 maybe. Do consider that the Commons community is
> > > small
> > > >> and I would not want to support concurrent support and releases on
> > bothe
> > > >> DBCP 2 and 3.
> > > >>
> > > >> Gary
> > > >>
> > > >> Gary
> > > >>
> > > >>> On Sat, Dec 17, 2022, 14:12 Richard Zowalla 
> wrote:
> > > >>>
> > > >>> For DBCP, it basically boils down to
> > > >>>
> > > >>> BasicManagedDataSource.java
> > > >>> DataSourceXAConnectionFactory.java
> > > >>> LocalXAConnectionFactory.java
> > > >>> SynchronizationAdapter.java
> > > >>> TransactionContext.java
> > > >>> TransactionRegistry.java
> > > >>>
> > > >>> Looking at these classes, the move to jakarta definitley affects
> > binary
> > > >>> compatibility as we have changes in return types / arguments of
> > public
> > > >>> methods. Given that it breaks binary compatibility, we could even
> > > >>> increase the java level to 11 and drop deprecated things in a
> > potential
> > > >>> dbcp 3.
> > > >>>
> > > >>> In the end, I am happy with everything, which brings DBCP into the
> > > >>> Jakarta world ;)
> > > >>>
> > > >>> If we have consensus for a route, I am happy to work on it / make
> it
> > > >>> happen via related PRs but would need some guideance on the best
> way
> > to
> > > >>> move forward.
> > > >>>
> > > >>> Gruß
> > > >>> Richard
> > > >>>
> > > >>> Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain
> Manni-Bucau:
> > > >>>> If not done in new classes (both can live in the same lib
> > > >>>> technically),
> > > >>>> sadly yes.
> > > >>>>
> > > >>>> Le ven. 16 déc. 2022 à 20:14, Richard Zowalla <
> rich...@zowalla.com>
> > a
> > > >>>> écrit :
> > > >>>>
> > > >>>>> Thanks for your replies.
> > > >>>>>
> > > >>>>> I guess, that switching the namespace leads to binary
> > > >>>>> incompatibility (If
> > > >>>>> I take the definition from [1]). I cannot drop it in a running
> JVM
> > > >>>>> / app
> > > >>>>> and expect no issues with it as the related APIs are breaking
> > > >>>>> namespace
> > > >>>>> changes (at least at runtime if they aren't present) :-)
> > > >>>>>
> > > >>>>> Aside from that fact, method signatures might also change from
> > > >>>>> javax ->
> > > >>>>> jakarta, which would require a short investigation and usage of
> the
> > > >>>>> existing tooling to see if this happens.
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

Any idea on when it can occurs? We are quite late to the party already and
shade was a good solution to be in without additional cost in terms of
maintainance for the project so if not the picked option we should target
some point not too far in 2023 pby.

Le dim. 18 déc. 2022 à 01:44, Gary Gregory  a
écrit :

> Hi Arun,
>
> There's not going to be anything to pick up for a while ;-)
>
> Gary
>
> On Sat, Dec 17, 2022, 18:06 Arun Avanathan 
> wrote:
>
> > Gary - if we have a ticket to upgrade DBCP to java 11, I can take it up.
> >
> > > On Dec 17, 2022, at 1:09 PM, Richard Zowalla 
> > wrote:
> > >
> > > Sure. Sounds like a plan :)
> > >
> > > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory <
> > garydgreg...@gmail.com>:
> > >> I think we should wait for a little while: I'd want to release current
> > code
> > >> from git for Commons Pool, then DBCP (which sits on top of Pool), make
> > sure
> > >> all is well, then see about going to DBCP 3, on Java 8 for now but
> > >> considering Java 11 maybe. Do consider that the Commons community is
> > small
> > >> and I would not want to support concurrent support and releases on
> bothe
> > >> DBCP 2 and 3.
> > >>
> > >> Gary
> > >>
> > >> Gary
> > >>
> > >>> On Sat, Dec 17, 2022, 14:12 Richard Zowalla  wrote:
> > >>>
> > >>> For DBCP, it basically boils down to
> > >>>
> > >>> BasicManagedDataSource.java
> > >>> DataSourceXAConnectionFactory.java
> > >>> LocalXAConnectionFactory.java
> > >>> SynchronizationAdapter.java
> > >>> TransactionContext.java
> > >>> TransactionRegistry.java
> > >>>
> > >>> Looking at these classes, the move to jakarta definitley affects
> binary
> > >>> compatibility as we have changes in return types / arguments of
> public
> > >>> methods. Given that it breaks binary compatibility, we could even
> > >>> increase the java level to 11 and drop deprecated things in a
> potential
> > >>> dbcp 3.
> > >>>
> > >>> In the end, I am happy with everything, which brings DBCP into the
> > >>> Jakarta world ;)
> > >>>
> > >>> If we have consensus for a route, I am happy to work on it / make it
> > >>> happen via related PRs but would need some guideance on the best way
> to
> > >>> move forward.
> > >>>
> > >>> Gruß
> > >>> Richard
> > >>>
> > >>> Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain Manni-Bucau:
> > >>>> If not done in new classes (both can live in the same lib
> > >>>> technically),
> > >>>> sadly yes.
> > >>>>
> > >>>> Le ven. 16 déc. 2022 à 20:14, Richard Zowalla 
> a
> > >>>> écrit :
> > >>>>
> > >>>>> Thanks for your replies.
> > >>>>>
> > >>>>> I guess, that switching the namespace leads to binary
> > >>>>> incompatibility (If
> > >>>>> I take the definition from [1]). I cannot drop it in a running JVM
> > >>>>> / app
> > >>>>> and expect no issues with it as the related APIs are breaking
> > >>>>> namespace
> > >>>>> changes (at least at runtime if they aren't present) :-)
> > >>>>>
> > >>>>> Aside from that fact, method signatures might also change from
> > >>>>> javax ->
> > >>>>> jakarta, which would require a short investigation and usage of the
> > >>>>> existing tooling to see if this happens.
> > >>>>>
> > >>>>> From a commons point of view that would mean to go for dbcp3,
> > >>>>> right?
> > >>>>>
> > >>>>> Gruß
> > >>>>> Richard
> > >>>>>
> > >>>>> [1]
> > >>>>>
> > >>>
> >
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> > >>>>>
> > >>>>> Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
> > >>>>> :
> > >>>>>> On 16/12/2022 13:24, Gary Gregory wrote:
> 

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Gary Gregory]

Hi Arun,

There's not going to be anything to pick up for a while ;-)

Gary

On Sat, Dec 17, 2022, 18:06 Arun Avanathan  wrote:

> Gary - if we have a ticket to upgrade DBCP to java 11, I can take it up.
>
> > On Dec 17, 2022, at 1:09 PM, Richard Zowalla 
> wrote:
> >
> > Sure. Sounds like a plan :)
> >
> > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory <
> garydgreg...@gmail.com>:
> >> I think we should wait for a little while: I'd want to release current
> code
> >> from git for Commons Pool, then DBCP (which sits on top of Pool), make
> sure
> >> all is well, then see about going to DBCP 3, on Java 8 for now but
> >> considering Java 11 maybe. Do consider that the Commons community is
> small
> >> and I would not want to support concurrent support and releases on bothe
> >> DBCP 2 and 3.
> >>
> >> Gary
> >>
> >> Gary
> >>
> >>> On Sat, Dec 17, 2022, 14:12 Richard Zowalla  wrote:
> >>>
> >>> For DBCP, it basically boils down to
> >>>
> >>> BasicManagedDataSource.java
> >>> DataSourceXAConnectionFactory.java
> >>> LocalXAConnectionFactory.java
> >>> SynchronizationAdapter.java
> >>> TransactionContext.java
> >>> TransactionRegistry.java
> >>>
> >>> Looking at these classes, the move to jakarta definitley affects binary
> >>> compatibility as we have changes in return types / arguments of public
> >>> methods. Given that it breaks binary compatibility, we could even
> >>> increase the java level to 11 and drop deprecated things in a potential
> >>> dbcp 3.
> >>>
> >>> In the end, I am happy with everything, which brings DBCP into the
> >>> Jakarta world ;)
> >>>
> >>> If we have consensus for a route, I am happy to work on it / make it
> >>> happen via related PRs but would need some guideance on the best way to
> >>> move forward.
> >>>
> >>> Gruß
> >>> Richard
> >>>
> >>> Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain Manni-Bucau:
> >>>> If not done in new classes (both can live in the same lib
> >>>> technically),
> >>>> sadly yes.
> >>>>
> >>>> Le ven. 16 déc. 2022 à 20:14, Richard Zowalla  a
> >>>> écrit :
> >>>>
> >>>>> Thanks for your replies.
> >>>>>
> >>>>> I guess, that switching the namespace leads to binary
> >>>>> incompatibility (If
> >>>>> I take the definition from [1]). I cannot drop it in a running JVM
> >>>>> / app
> >>>>> and expect no issues with it as the related APIs are breaking
> >>>>> namespace
> >>>>> changes (at least at runtime if they aren't present) :-)
> >>>>>
> >>>>> Aside from that fact, method signatures might also change from
> >>>>> javax ->
> >>>>> jakarta, which would require a short investigation and usage of the
> >>>>> existing tooling to see if this happens.
> >>>>>
> >>>>> From a commons point of view that would mean to go for dbcp3,
> >>>>> right?
> >>>>>
> >>>>> Gruß
> >>>>> Richard
> >>>>>
> >>>>> [1]
> >>>>>
> >>>
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> >>>>>
> >>>>> Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
> >>>>> :
> >>>>>> On 16/12/2022 13:24, Gary Gregory wrote:
> >>>>>>> Thank you Richard for starting this thread.
> >>>>>>>
> >>>>>>> My view is simpler perhaps: I would not make this about the
> >>>>>>> javax vs
> >>>>>>> Jakarta namespaces.
> >>>>>>>
> >>>>>>> I don't want to double the numbers of jars we produce from the
> >>>>>>> same
> >>>>> branch
> >>>>>>> for affected components as one of the scheme proposed. It feels
> >>>>>>> like a
> >>>>>>> burden to maintenance moving forward and a very brittle process
> >>>>>>> with
> >>>>> som

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Arun Avanathan]

Gary - if we have a ticket to upgrade DBCP to java 11, I can take it up.

> On Dec 17, 2022, at 1:09 PM, Richard Zowalla  wrote:
> 
> Sure. Sounds like a plan :)
> 
> Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory 
> :
>> I think we should wait for a little while: I'd want to release current code
>> from git for Commons Pool, then DBCP (which sits on top of Pool), make sure
>> all is well, then see about going to DBCP 3, on Java 8 for now but
>> considering Java 11 maybe. Do consider that the Commons community is small
>> and I would not want to support concurrent support and releases on bothe
>> DBCP 2 and 3.
>> 
>> Gary
>> 
>> Gary
>> 
>>> On Sat, Dec 17, 2022, 14:12 Richard Zowalla  wrote:
>>> 
>>> For DBCP, it basically boils down to
>>> 
>>> BasicManagedDataSource.java
>>> DataSourceXAConnectionFactory.java
>>> LocalXAConnectionFactory.java
>>> SynchronizationAdapter.java
>>> TransactionContext.java
>>> TransactionRegistry.java
>>> 
>>> Looking at these classes, the move to jakarta definitley affects binary
>>> compatibility as we have changes in return types / arguments of public
>>> methods. Given that it breaks binary compatibility, we could even
>>> increase the java level to 11 and drop deprecated things in a potential
>>> dbcp 3.
>>> 
>>> In the end, I am happy with everything, which brings DBCP into the
>>> Jakarta world ;)
>>> 
>>> If we have consensus for a route, I am happy to work on it / make it
>>> happen via related PRs but would need some guideance on the best way to
>>> move forward.
>>> 
>>> Gruß
>>> Richard
>>> 
>>> Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain Manni-Bucau:
>>>> If not done in new classes (both can live in the same lib
>>>> technically),
>>>> sadly yes.
>>>> 
>>>> Le ven. 16 déc. 2022 à 20:14, Richard Zowalla  a
>>>> écrit :
>>>> 
>>>>> Thanks for your replies.
>>>>> 
>>>>> I guess, that switching the namespace leads to binary
>>>>> incompatibility (If
>>>>> I take the definition from [1]). I cannot drop it in a running JVM
>>>>> / app
>>>>> and expect no issues with it as the related APIs are breaking
>>>>> namespace
>>>>> changes (at least at runtime if they aren't present) :-)
>>>>> 
>>>>> Aside from that fact, method signatures might also change from
>>>>> javax ->
>>>>> jakarta, which would require a short investigation and usage of the
>>>>> existing tooling to see if this happens.
>>>>> 
>>>>> From a commons point of view that would mean to go for dbcp3,
>>>>> right?
>>>>> 
>>>>> Gruß
>>>>> Richard
>>>>> 
>>>>> [1]
>>>>> 
>>> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
>>>>> 
>>>>> Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
>>>>> :
>>>>>> On 16/12/2022 13:24, Gary Gregory wrote:
>>>>>>> Thank you Richard for starting this thread.
>>>>>>> 
>>>>>>> My view is simpler perhaps: I would not make this about the
>>>>>>> javax vs
>>>>>>> Jakarta namespaces.
>>>>>>> 
>>>>>>> I don't want to double the numbers of jars we produce from the
>>>>>>> same
>>>>> branch
>>>>>>> for affected components as one of the scheme proposed. It feels
>>>>>>> like a
>>>>>>> burden to maintenance moving forward and a very brittle process
>>>>>>> with
>>>>> some
>>>>>>> unforeseen side effects.
>>>>>>> 
>>>>>>> This is just a code change IMO. For a given component, either
>>>>>>> it is
>>>>> binary
>>>>>>> compatible, or it is not. You don't know until you try it and
>>>>>>> see if
>>>>> public
>>>>>>> and protected elements break, using our existing configuration
>>>>>>> of Maven
>>>>> and
>>>>>>> japicmp (or revapi).
>>>>>>> 
>>>>>>> If it is binary compatible, then let's consider making the
>>>>>>> change. If
>>>>> not,
>>>>>>> then do it in a major version, where the previous major version
>>>>>>> is
>>>>>>> maintained as we do now, as need be.
>>>>>>> 
>>>>>>> A new major version also benefits from the usual dropping of
>>>>>>> deprecated
>>>>>>> elements and making any other changes with seem reasonable.
>>>>>> 
>>>>>> +1. I don't see this as any different to increasing the minimum
>>>>>> version
>>>>> of Java and supported new JDBC methods.
>>>>>> 
>>>>>> Mark
>>>>>> 
>>>>>> -
>>>>>> 
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>> 
>>>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>>> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

Sure. Sounds like a plan :)

Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory :
>I think we should wait for a little while: I'd want to release current code
>from git for Commons Pool, then DBCP (which sits on top of Pool), make sure
>all is well, then see about going to DBCP 3, on Java 8 for now but
>considering Java 11 maybe. Do consider that the Commons community is small
>and I would not want to support concurrent support and releases on bothe
>DBCP 2 and 3.
>
>Gary
>
>Gary
>
>On Sat, Dec 17, 2022, 14:12 Richard Zowalla  wrote:
>
>> For DBCP, it basically boils down to
>>
>> BasicManagedDataSource.java
>> DataSourceXAConnectionFactory.java
>> LocalXAConnectionFactory.java
>> SynchronizationAdapter.java
>> TransactionContext.java
>> TransactionRegistry.java
>>
>> Looking at these classes, the move to jakarta definitley affects binary
>> compatibility as we have changes in return types / arguments of public
>> methods. Given that it breaks binary compatibility, we could even
>> increase the java level to 11 and drop deprecated things in a potential
>> dbcp 3.
>>
>> In the end, I am happy with everything, which brings DBCP into the
>> Jakarta world ;)
>>
>> If we have consensus for a route, I am happy to work on it / make it
>> happen via related PRs but would need some guideance on the best way to
>> move forward.
>>
>> Gruß
>> Richard
>>
>> Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain Manni-Bucau:
>> > If not done in new classes (both can live in the same lib
>> > technically),
>> > sadly yes.
>> >
>> > Le ven. 16 déc. 2022 à 20:14, Richard Zowalla  a
>> > écrit :
>> >
>> > > Thanks for your replies.
>> > >
>> > > I guess, that switching the namespace leads to binary
>> > > incompatibility (If
>> > > I take the definition from [1]). I cannot drop it in a running JVM
>> > > / app
>> > > and expect no issues with it as the related APIs are breaking
>> > > namespace
>> > > changes (at least at runtime if they aren't present) :-)
>> > >
>> > > Aside from that fact, method signatures might also change from
>> > > javax ->
>> > > jakarta, which would require a short investigation and usage of the
>> > > existing tooling to see if this happens.
>> > >
>> > > From a commons point of view that would mean to go for dbcp3,
>> > > right?
>> > >
>> > > Gruß
>> > > Richard
>> > >
>> > > [1]
>> > >
>> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
>> > >
>> > > Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
>> > > :
>> > > > On 16/12/2022 13:24, Gary Gregory wrote:
>> > > > > Thank you Richard for starting this thread.
>> > > > >
>> > > > > My view is simpler perhaps: I would not make this about the
>> > > > > javax vs
>> > > > > Jakarta namespaces.
>> > > > >
>> > > > > I don't want to double the numbers of jars we produce from the
>> > > > > same
>> > > branch
>> > > > > for affected components as one of the scheme proposed. It feels
>> > > > > like a
>> > > > > burden to maintenance moving forward and a very brittle process
>> > > > > with
>> > > some
>> > > > > unforeseen side effects.
>> > > > >
>> > > > > This is just a code change IMO. For a given component, either
>> > > > > it is
>> > > binary
>> > > > > compatible, or it is not. You don't know until you try it and
>> > > > > see if
>> > > public
>> > > > > and protected elements break, using our existing configuration
>> > > > > of Maven
>> > > and
>> > > > > japicmp (or revapi).
>> > > > >
>> > > > > If it is binary compatible, then let's consider making the
>> > > > > change. If
>> > > not,
>> > > > > then do it in a major version, where the previous major version
>> > > > > is
>> > > > > maintained as we do now, as need be.
>> > > > >
>> > > > > A new major version also benefits from the usual dropping of
>> > > > > deprecated
>> > > > > elements and making any other changes with seem reasonable.
>> > > >
>> > > > +1. I don't see this as any different to increasing the minimum
>> > > > version
>> > > of Java and supported new JDBC methods.
>> > > >
>> > > > Mark
>> > > >
>> > > > -
>> > > > 
>> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > > > For additional commands, e-mail: dev-h...@commons.apache.org
>> > > >
>> > >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Gary Gregory]

I think we should wait for a little while: I'd want to release current code
from git for Commons Pool, then DBCP (which sits on top of Pool), make sure
all is well, then see about going to DBCP 3, on Java 8 for now but
considering Java 11 maybe. Do consider that the Commons community is small
and I would not want to support concurrent support and releases on bothe
DBCP 2 and 3.

Gary

Gary

On Sat, Dec 17, 2022, 14:12 Richard Zowalla  wrote:

> For DBCP, it basically boils down to
>
> BasicManagedDataSource.java
> DataSourceXAConnectionFactory.java
> LocalXAConnectionFactory.java
> SynchronizationAdapter.java
> TransactionContext.java
> TransactionRegistry.java
>
> Looking at these classes, the move to jakarta definitley affects binary
> compatibility as we have changes in return types / arguments of public
> methods. Given that it breaks binary compatibility, we could even
> increase the java level to 11 and drop deprecated things in a potential
> dbcp 3.
>
> In the end, I am happy with everything, which brings DBCP into the
> Jakarta world ;)
>
> If we have consensus for a route, I am happy to work on it / make it
> happen via related PRs but would need some guideance on the best way to
> move forward.
>
> Gruß
> Richard
>
> Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain Manni-Bucau:
> > If not done in new classes (both can live in the same lib
> > technically),
> > sadly yes.
> >
> > Le ven. 16 déc. 2022 à 20:14, Richard Zowalla  a
> > écrit :
> >
> > > Thanks for your replies.
> > >
> > > I guess, that switching the namespace leads to binary
> > > incompatibility (If
> > > I take the definition from [1]). I cannot drop it in a running JVM
> > > / app
> > > and expect no issues with it as the related APIs are breaking
> > > namespace
> > > changes (at least at runtime if they aren't present) :-)
> > >
> > > Aside from that fact, method signatures might also change from
> > > javax ->
> > > jakarta, which would require a short investigation and usage of the
> > > existing tooling to see if this happens.
> > >
> > > From a commons point of view that would mean to go for dbcp3,
> > > right?
> > >
> > > Gruß
> > > Richard
> > >
> > > [1]
> > >
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> > >
> > > Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
> > > :
> > > > On 16/12/2022 13:24, Gary Gregory wrote:
> > > > > Thank you Richard for starting this thread.
> > > > >
> > > > > My view is simpler perhaps: I would not make this about the
> > > > > javax vs
> > > > > Jakarta namespaces.
> > > > >
> > > > > I don't want to double the numbers of jars we produce from the
> > > > > same
> > > branch
> > > > > for affected components as one of the scheme proposed. It feels
> > > > > like a
> > > > > burden to maintenance moving forward and a very brittle process
> > > > > with
> > > some
> > > > > unforeseen side effects.
> > > > >
> > > > > This is just a code change IMO. For a given component, either
> > > > > it is
> > > binary
> > > > > compatible, or it is not. You don't know until you try it and
> > > > > see if
> > > public
> > > > > and protected elements break, using our existing configuration
> > > > > of Maven
> > > and
> > > > > japicmp (or revapi).
> > > > >
> > > > > If it is binary compatible, then let's consider making the
> > > > > change. If
> > > not,
> > > > > then do it in a major version, where the previous major version
> > > > > is
> > > > > maintained as we do now, as need be.
> > > > >
> > > > > A new major version also benefits from the usual dropping of
> > > > > deprecated
> > > > > elements and making any other changes with seem reasonable.
> > > >
> > > > +1. I don't see this as any different to increasing the minimum
> > > > version
> > > of Java and supported new JDBC methods.
> > > >
> > > > Mark
> > > >
> > > > -
> > > > 
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

For DBCP, it basically boils down to

BasicManagedDataSource.java
DataSourceXAConnectionFactory.java
LocalXAConnectionFactory.java
SynchronizationAdapter.java
TransactionContext.java
TransactionRegistry.java

Looking at these classes, the move to jakarta definitley affects binary
compatibility as we have changes in return types / arguments of public
methods. Given that it breaks binary compatibility, we could even
increase the java level to 11 and drop deprecated things in a potential
dbcp 3.

In the end, I am happy with everything, which brings DBCP into the
Jakarta world ;)

If we have consensus for a route, I am happy to work on it / make it
happen via related PRs but would need some guideance on the best way to
move forward. 

Gruß
Richard

Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain Manni-Bucau:
> If not done in new classes (both can live in the same lib
> technically),
> sadly yes.
> 
> Le ven. 16 déc. 2022 à 20:14, Richard Zowalla  a
> écrit :
> 
> > Thanks for your replies.
> > 
> > I guess, that switching the namespace leads to binary
> > incompatibility (If
> > I take the definition from [1]). I cannot drop it in a running JVM
> > / app
> > and expect no issues with it as the related APIs are breaking
> > namespace
> > changes (at least at runtime if they aren't present) :-)
> > 
> > Aside from that fact, method signatures might also change from
> > javax ->
> > jakarta, which would require a short investigation and usage of the
> > existing tooling to see if this happens.
> > 
> > From a commons point of view that would mean to go for dbcp3,
> > right?
> > 
> > Gruß
> > Richard
> > 
> > [1]
> > https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> > 
> > Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
> > :
> > > On 16/12/2022 13:24, Gary Gregory wrote:
> > > > Thank you Richard for starting this thread.
> > > > 
> > > > My view is simpler perhaps: I would not make this about the
> > > > javax vs
> > > > Jakarta namespaces.
> > > > 
> > > > I don't want to double the numbers of jars we produce from the
> > > > same
> > branch
> > > > for affected components as one of the scheme proposed. It feels
> > > > like a
> > > > burden to maintenance moving forward and a very brittle process
> > > > with
> > some
> > > > unforeseen side effects.
> > > > 
> > > > This is just a code change IMO. For a given component, either
> > > > it is
> > binary
> > > > compatible, or it is not. You don't know until you try it and
> > > > see if
> > public
> > > > and protected elements break, using our existing configuration
> > > > of Maven
> > and
> > > > japicmp (or revapi).
> > > > 
> > > > If it is binary compatible, then let's consider making the
> > > > change. If
> > not,
> > > > then do it in a major version, where the previous major version
> > > > is
> > > > maintained as we do now, as need be.
> > > > 
> > > > A new major version also benefits from the usual dropping of
> > > > deprecated
> > > > elements and making any other changes with seem reasonable.
> > > 
> > > +1. I don't see this as any different to increasing the minimum
> > > version
> > of Java and supported new JDBC methods.
> > > 
> > > Mark
> > > 
> > > -
> > > 
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > 
> > 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

If not done in new classes (both can live in the same lib technically),
sadly yes.

Le ven. 16 déc. 2022 à 20:14, Richard Zowalla  a
écrit :

> Thanks for your replies.
>
> I guess, that switching the namespace leads to binary incompatibility (If
> I take the definition from [1]). I cannot drop it in a running JVM / app
> and expect no issues with it as the related APIs are breaking namespace
> changes (at least at runtime if they aren't present) :-)
>
> Aside from that fact, method signatures might also change from javax ->
> jakarta, which would require a short investigation and usage of the
> existing tooling to see if this happens.
>
> From a commons point of view that would mean to go for dbcp3, right?
>
> Gruß
> Richard
>
> [1]
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
>
> Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas :
> >On 16/12/2022 13:24, Gary Gregory wrote:
> >> Thank you Richard for starting this thread.
> >>
> >> My view is simpler perhaps: I would not make this about the javax vs
> >> Jakarta namespaces.
> >>
> >> I don't want to double the numbers of jars we produce from the same
> branch
> >> for affected components as one of the scheme proposed. It feels like a
> >> burden to maintenance moving forward and a very brittle process with
> some
> >> unforeseen side effects.
> >>
> >> This is just a code change IMO. For a given component, either it is
> binary
> >> compatible, or it is not. You don't know until you try it and see if
> public
> >> and protected elements break, using our existing configuration of Maven
> and
> >> japicmp (or revapi).
> >>
> >> If it is binary compatible, then let's consider making the change. If
> not,
> >> then do it in a major version, where the previous major version is
> >> maintained as we do now, as need be.
> >>
> >> A new major version also benefits from the usual dropping of deprecated
> >> elements and making any other changes with seem reasonable.
> >
> >+1. I don't see this as any different to increasing the minimum version
> of Java and supported new JDBC methods.
> >
> >Mark
> >
> >-
> >To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >For additional commands, e-mail: dev-h...@commons.apache.org
> >
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

Thanks for your replies. 

I guess, that switching the namespace leads to binary incompatibility (If I 
take the definition from [1]). I cannot drop it in a running JVM / app and 
expect no issues with it as the related APIs are breaking namespace changes (at 
least at runtime if they aren't present) :-) 

Aside from that fact, method signatures might also change from javax -> 
jakarta, which would require a short investigation and usage of the existing 
tooling to see if this happens.

From a commons point of view that would mean to go for dbcp3, right?

Gruß
Richard 

[1] 
https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/

Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas :
>On 16/12/2022 13:24, Gary Gregory wrote:
>> Thank you Richard for starting this thread.
>> 
>> My view is simpler perhaps: I would not make this about the javax vs
>> Jakarta namespaces.
>> 
>> I don't want to double the numbers of jars we produce from the same branch
>> for affected components as one of the scheme proposed. It feels like a
>> burden to maintenance moving forward and a very brittle process with some
>> unforeseen side effects.
>> 
>> This is just a code change IMO. For a given component, either it is binary
>> compatible, or it is not. You don't know until you try it and see if public
>> and protected elements break, using our existing configuration of Maven and
>> japicmp (or revapi).
>> 
>> If it is binary compatible, then let's consider making the change. If not,
>> then do it in a major version, where the previous major version is
>> maintained as we do now, as need be.
>> 
>> A new major version also benefits from the usual dropping of deprecated
>> elements and making any other changes with seem reasonable.
>
>+1. I don't see this as any different to increasing the minimum version of 
>Java and supported new JDBC methods.
>
>Mark
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>For additional commands, e-mail: dev-h...@commons.apache.org
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Mark Thomas]

On 16/12/2022 13:24, Gary Gregory wrote:

Thank you Richard for starting this thread.

My view is simpler perhaps: I would not make this about the javax vs
Jakarta namespaces.

I don't want to double the numbers of jars we produce from the same branch
for affected components as one of the scheme proposed. It feels like a
burden to maintenance moving forward and a very brittle process with some
unforeseen side effects.

This is just a code change IMO. For a given component, either it is binary
compatible, or it is not. You don't know until you try it and see if public
and protected elements break, using our existing configuration of Maven and
japicmp (or revapi).

If it is binary compatible, then let's consider making the change. If not,
then do it in a major version, where the previous major version is
maintained as we do now, as need be.

A new major version also benefits from the usual dropping of deprecated
elements and making any other changes with seem reasonable.


+1. I don't see this as any different to increasing the minimum version 
of Java and supported new JDBC methods.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Gary Gregory]

Thank you Richard for starting this thread.

My view is simpler perhaps: I would not make this about the javax vs
Jakarta namespaces.

I don't want to double the numbers of jars we produce from the same branch
for affected components as one of the scheme proposed. It feels like a
burden to maintenance moving forward and a very brittle process with some
unforeseen side effects.

This is just a code change IMO. For a given component, either it is binary
compatible, or it is not. You don't know until you try it and see if public
and protected elements break, using our existing configuration of Maven and
japicmp (or revapi).

If it is binary compatible, then let's consider making the change. If not,
then do it in a major version, where the previous major version is
maintained as we do now, as need be.

A new major version also benefits from the usual dropping of deprecated
elements and making any other changes with seem reasonable.

Gary


On Fri, Dec 16, 2022, 04:35 Richard Zowalla  wrote:

> Hi all,
>
> based on the discussion [1] for DBCP, I wanted to start a discussion
> whether and how the Apache Commons project might/want to support the
> Jakarta namespace changes.
>
> I know, that not all commons projects are impacted by the namespaces
> change, but we should make sure, that users can use related projects
> like DBCP with the emerging presense of Jakarta EE 9 / 10 in the near
> future.
>
> Other EE-related projects decided to use a relocation approach as shown
> in [1], which might not be a feasable option for every project impacted
> by the change. As suggested by @garydgregory in [1], the sanest way
> would be to change the source code. This might break binary
> compatibility and requires new major versions and effort to maintain
> both worlds (javax, jakarta) as javax will be still around for some
> time.
>
> Ideally, we find some sort of agreement to move on, so depending
> projects like TomEE or users can use jakarta ready artifacts. I am
> happy to contribute / be part of that journey.
>
> So the question boils down to:
>
> (a) Switch to jakarta (and provide javax artifacts via relocation)
> (b) Stay on javax (and provide jakarta artifacts via relocation)
> (c) Maintain two branches (jakarta & javax) and cherry pick changes
> between them.
> (d) Abandon javax and move on
> (e) Something else?
>
>
> Any thoughts, ideas, visions regarding that topic?
>
> Gruß
> Richard
>
>
> [1] https://github.com/apache/commons-dbcp/pull/248
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

-1 for c and d, +1 for a, guess b can still be an option for ~2 years
before switching to a

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 16 déc. 2022 à 10:35, Richard Zowalla  a écrit :

> Hi all,
>
> based on the discussion [1] for DBCP, I wanted to start a discussion
> whether and how the Apache Commons project might/want to support the
> Jakarta namespace changes.
>
> I know, that not all commons projects are impacted by the namespaces
> change, but we should make sure, that users can use related projects
> like DBCP with the emerging presense of Jakarta EE 9 / 10 in the near
> future.
>
> Other EE-related projects decided to use a relocation approach as shown
> in [1], which might not be a feasable option for every project impacted
> by the change. As suggested by @garydgregory in [1], the sanest way
> would be to change the source code. This might break binary
> compatibility and requires new major versions and effort to maintain
> both worlds (javax, jakarta) as javax will be still around for some
> time.
>
> Ideally, we find some sort of agreement to move on, so depending
> projects like TomEE or users can use jakarta ready artifacts. I am
> happy to contribute / be part of that journey.
>
> So the question boils down to:
>
> (a) Switch to jakarta (and provide javax artifacts via relocation)
> (b) Stay on javax (and provide jakarta artifacts via relocation)
> (c) Maintain two branches (jakarta & javax) and cherry pick changes
> between them.
> (d) Abandon javax and move on
> (e) Something else?
>
>
> Any thoughts, ideas, visions regarding that topic?
>
> Gruß
> Richard
>
>
> [1] https://github.com/apache/commons-dbcp/pull/248
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

Hi all,

based on the discussion [1] for DBCP, I wanted to start a discussion
whether and how the Apache Commons project might/want to support the
Jakarta namespace changes.

I know, that not all commons projects are impacted by the namespaces
change, but we should make sure, that users can use related projects
like DBCP with the emerging presense of Jakarta EE 9 / 10 in the near
future.

Other EE-related projects decided to use a relocation approach as shown
in [1], which might not be a feasable option for every project impacted
by the change. As suggested by @garydgregory in [1], the sanest way
would be to change the source code. This might break binary
compatibility and requires new major versions and effort to maintain
both worlds (javax, jakarta) as javax will be still around for some
time. 

Ideally, we find some sort of agreement to move on, so depending
projects like TomEE or users can use jakarta ready artifacts. I am
happy to contribute / be part of that journey.

So the question boils down to:

(a) Switch to jakarta (and provide javax artifacts via relocation) 
(b) Stay on javax (and provide jakarta artifacts via relocation)
(c) Maintain two branches (jakarta & javax) and cherry pick changes
between them.
(d) Abandon javax and move on
(e) Something else?


Any thoughts, ideas, visions regarding that topic?

Gruß
Richard


[1] https://github.com/apache/commons-dbcp/pull/248


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-dbcp] branch master updated: org.apache.commons.dbcp2.datasources.UserPassKey should be Serializable (SpotBugs)

[Gary Gregory]

Could be, I see that my git autocrlf setting is false for that repo on my
Windows box.

Gary

On Mon, Jul 4, 2022, 05:32 Mark Thomas  wrote:

> Gary,
>
> A couple of your DBCP commits seem to be much bigger than they should
> be. Is there some sort of line ending issue going on?
>
> Mark
>
>
>
> On 02/07/2022 14:39, ggreg...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > ggregory pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-dbcp.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> >   new 20b0c930 org.apache.commons.dbcp2.datasources.UserPassKey
> should be Serializable (SpotBugs)
> > 20b0c930 is described below
> >
> > commit 20b0c930e2e329dfb9e318499a7b39dc931cdb9e
> > Author: Gary Gregory 
> > AuthorDate: Sat Jul 2 09:39:30 2022 -0400
> >
> >  org.apache.commons.dbcp2.datasources.UserPassKey should be
> Serializable
> >  (SpotBugs)
> > ---
> >   src/changes/changes.xml|   3 +
> >   .../commons/dbcp2/datasources/CharArray.java   |   5 +-
> >   .../commons/dbcp2/datasources/TestUserPassKey.java | 150
> +++--
> >   3 files changed, 85 insertions(+), 73 deletions(-)
> >
> > diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> > index 858bc0d7..d3971a98 100644
> > --- a/src/changes/changes.xml
> > +++ b/src/changes/changes.xml
> > @@ -83,6 +83,9 @@ The  type attribute can be
> add,update,fix,remove.
> > 
> >   Connection level JMX queries result in concurrent access to
> connection objects, causing errors #179
> > 
> > +  
> > +UserPassKey should be Serializable.
> > +  
> > 
> > 
> >   Add and use AbandonedTrace#setLastUsed(Instant).
> > diff --git
> a/src/main/java/org/apache/commons/dbcp2/datasources/CharArray.java
> b/src/main/java/org/apache/commons/dbcp2/datasources/CharArray.java
> > index f1d9c2aa..6581232e 100644
> > --- a/src/main/java/org/apache/commons/dbcp2/datasources/CharArray.java
> > +++ b/src/main/java/org/apache/commons/dbcp2/datasources/CharArray.java
> > @@ -17,6 +17,7 @@
> >
> >   package org.apache.commons.dbcp2.datasources;
> >
> > +import java.io.Serializable;
> >   import java.util.Arrays;
> >
> >   import org.apache.commons.dbcp2.Utils;
> > @@ -29,7 +30,9 @@ import org.apache.commons.dbcp2.Utils;
> >*
> >* @since 2.9.0
> >*/
> > -final class CharArray {
> > +final class CharArray implements Serializable {
> > +
> > +private static final long serialVersionUID = 1L;
> >
> >   static final CharArray NULL = new CharArray((char[]) null);
> >
> > diff --git
> a/src/test/java/org/apache/commons/dbcp2/datasources/TestUserPassKey.java
> b/src/test/java/org/apache/commons/dbcp2/datasources/TestUserPassKey.java
> > index 899510f2..c8b8555e 100644
> > ---
> a/src/test/java/org/apache/commons/dbcp2/datasources/TestUserPassKey.java
> > +++
> b/src/test/java/org/apache/commons/dbcp2/datasources/TestUserPassKey.java
> > @@ -1,72 +1,78 @@
> > -/*
> > - * Licensed to the Apache Software Foundation (ASF) under one or more
> > - * contributor license agreements.  See the NOTICE file distributed with
> > - * this work for additional information regarding copyright ownership.
> > - * The ASF licenses this file to You under the Apache License, Version
> 2.0
> > - * (the "License"); you may not use this file except in compliance with
> > - * the License.  You may obtain a copy of the License at
> > - *
> > - *  http://www.apache.org/licenses/LICENSE-2.0
> > - *
> > - * Unless required by applicable law or agreed to in writing, software
> > - * distributed under the License is distributed on an "AS IS" BASIS,
> > - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> > - * See the License for the specific language governing permissions and
> > - * limitations under the License.
> > - */
> > -
> > -package org.apache.commons.dbcp2.datasources;
> > -
> > -import static org.junit.jupiter.api.Assertions.assertArrayEquals;
> > -import static org.junit.jupiter.api.Assertions.assertEquals;
> > -import static org.junit.jupiter.api.Assertions.assertNotEquals;
> > -
> > -import org.apache.commons.dbcp2.Utils;
> > -import org.junit.jupiter.api.BeforeEach;
> > -import org.juni

Re: [commons-dbcp] branch master updated: LifetimeExceededException should extend SQLException.

[Gary Gregory]

Fixed, TY!

Gary

On Mon, Jul 4, 2022, 06:05 Mark Thomas  wrote:

> On 03/07/2022 15:37, ggreg...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > ggregory pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-dbcp.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> >   new 09677c3e LifetimeExceededException should extend SQLException.
> > 09677c3e is described below
> >
> > commit 09677c3e674894cffe2f9ebeaa7e562792f658a4
> > Author: Gary Gregory 
> > AuthorDate: Sun Jul 3 10:37:23 2022 -0400
> >
> >  LifetimeExceededException should extend SQLException.
> > ---
> >   src/changes/changes.xml|  1 +
> >   .../commons/dbcp2/LifetimeExceededException.java   | 88
> +++---
> >   2 files changed, 46 insertions(+), 43 deletions(-)
> >
> > diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> > index 117256bf..73226f9c 100644
> > --- a/src/changes/changes.xml
> > +++ b/src/changes/changes.xml
> > @@ -86,6 +86,7 @@ The  type attribute can be
> add,update,fix,remove.
> > 
> >   UserPassKey should be Serializable.
> > 
> > +LifetimeExceededException should extend SQLException.
>
> Gary,
>
> This breaks the XML. You need to add the tags.
>
> Mark
>

Re: [DBCP] archive versions prior to Java 7

[Bruno Kinoshita]

+1 to archiving <7 versions.

Thanks

On Wed, 16 Mar 2022, 00:33 Gary Gregory,  wrote:

> Hi Sebb,
>
> I don't plan on supporting pre-Java 8 versions, others may feel different
> of course. I say: go for it.
>
> Gary
>
> On Tue, Mar 15, 2022, 07:06 sebb  wrote:
>
> > The DBCP versions for Java 6 and earlier are still published via the
> > mirrors.
> >
> > Do we still support them?
> >
> > If not, I think they should be archived and documented as such.
> >
> > That would leave versions for JDBC 4.1 (Java 7) and JDBC 4.2 (Java 8).
> >
> > [The web page needs tidying anyway to remove references to superseded
> > Java 8 versions]
> >
> > I am happy to do the work.
> >
> > Sebb
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [DBCP] archive versions prior to Java 7

[Gary Gregory]

Hi Sebb,

I don't plan on supporting pre-Java 8 versions, others may feel different
of course. I say: go for it.

Gary

On Tue, Mar 15, 2022, 07:06 sebb  wrote:

> The DBCP versions for Java 6 and earlier are still published via the
> mirrors.
>
> Do we still support them?
>
> If not, I think they should be archived and documented as such.
>
> That would leave versions for JDBC 4.1 (Java 7) and JDBC 4.2 (Java 8).
>
> [The web page needs tidying anyway to remove references to superseded
> Java 8 versions]
>
> I am happy to do the work.
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[DBCP] archive versions prior to Java 7

[sebb]

The DBCP versions for Java 6 and earlier are still published via the mirrors.

Do we still support them?

If not, I think they should be archived and documented as such.

That would leave versions for JDBC 4.1 (Java 7) and JDBC 4.2 (Java 8).

[The web page needs tidying anyway to remove references to superseded
Java 8 versions]

I am happy to do the work.

Sebb

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-dbcp] branch master updated: Update MXBean for use of Duration with BasicDataSource

[Mark Thomas]

XxxxMXBean interfaces are (arguably) a special case since they exist to 
expose methods via JMX.


I wouldn't expect any users of DBCP to be implementing this interface.

If we think there is a real risk that users have implemented this 
interface (for what use case?) then I can add default implementations 
for those methods.


Mark



On 05/01/2022 19:36, Gary Gregory wrote:

If you add methods to an existing interface, this will break binary
compatibility unless you add them as default methods. Or am i missing
something?

Gary

On Wed, Jan 5, 2022, 14:10  wrote:


This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/commons-dbcp.git


The following commit(s) were added to refs/heads/master by this push:
  new 28eb33b  Update MXBean for use of Duration with BasicDataSource
28eb33b is described below

commit 28eb33b5b3551de2e630a4cb59dc3bc5506f8114
Author: Mark Thomas 
AuthorDate: Wed Jan 5 19:07:51 2022 +

 Update MXBean for use of Duration with BasicDataSource
---
  .../org/apache/commons/dbcp2/BasicDataSource.java  |  7 ++
  .../org/apache/commons/dbcp2/DataSourceMXBean.java | 77
++
  .../commons/dbcp2/TestBasicDataSourceMXBean.java   | 37 +++
  3 files changed, 121 insertions(+)

diff --git a/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
b/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
index 07615d2..bb451cd 100644
--- a/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
+++ b/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
@@ -1064,6 +1064,7 @@ public class BasicDataSource implements DataSource,
BasicDataSourceMXBean, MBean
   * @return the maximum permitted duration of a connection.
   * @since 2.10.0
   */
+@Override
  public Duration getMaxConnDuration() {
  return maxConnDuration;
  }
@@ -1123,6 +1124,7 @@ public class BasicDataSource implements DataSource,
BasicDataSourceMXBean, MBean
   * @return the maxWaitDuration property value.
   * @since 2.10.0
   */
+@Override
  public synchronized Duration getMaxWaitDuration() {
  return this.maxWaitDuration;
  }
@@ -1147,6 +1149,7 @@ public class BasicDataSource implements DataSource,
BasicDataSourceMXBean, MBean
   * @see #setMinEvictableIdle(Duration)
   * @since 2.10.0
   */
+@Override
  public synchronized Duration getMinEvictableIdleDuration() {
  return this.minEvictableIdleDuration;
  }
@@ -1324,6 +1327,7 @@ public class BasicDataSource implements DataSource,
BasicDataSourceMXBean, MBean
   * @return Timeout before an abandoned connection can be removed.
   * @since 2.10.0
   */
+@Override
  public Duration getRemoveAbandonedTimeoutDuration() {
  return abandonedConfig == null ? Duration.ofSeconds(300) :
abandonedConfig.getRemoveAbandonedTimeoutDuration();
  }
@@ -1353,6 +1357,7 @@ public class BasicDataSource implements DataSource,
BasicDataSourceMXBean, MBean
   * there are minIdle idle connections in the pool
   * @since 2.10.0
   */
+@Override
  public synchronized Duration getSoftMinEvictableIdleDuration() {
  return softMinEvictableIdleDuration;
  }
@@ -1429,6 +1434,7 @@ public class BasicDataSource implements DataSource,
BasicDataSourceMXBean, MBean
   * @see #setDurationBetweenEvictionRuns(Duration)
   * @since 2.10.0
   */
+@Override
  public synchronized Duration getDurationBetweenEvictionRuns() {
  return this.durationBetweenEvictionRuns;
  }
@@ -1482,6 +1488,7 @@ public class BasicDataSource implements DataSource,
BasicDataSourceMXBean, MBean
   *
   * @return the timeout in seconds before connection validation
queries fail.
   */
+@Override
  public Duration getValidationQueryTimeoutDuration() {
  return validationQueryTimeoutDuration;
  }
diff --git a/src/main/java/org/apache/commons/dbcp2/DataSourceMXBean.java
b/src/main/java/org/apache/commons/dbcp2/DataSourceMXBean.java
index 56fb5c8..9922542 100644
--- a/src/main/java/org/apache/commons/dbcp2/DataSourceMXBean.java
+++ b/src/main/java/org/apache/commons/dbcp2/DataSourceMXBean.java
@@ -17,6 +17,7 @@
  package org.apache.commons.dbcp2;

  import java.sql.SQLException;
+import java.time.Duration;

  /**
   * Defines the methods that will be made available via
@@ -138,10 +139,21 @@ public interface DataSourceMXBean {
  boolean getLogExpiredConnections();

  /**
+ * See {@link BasicDataSource#getMaxConnDuration()}.
+ *
+ * @return {@link BasicDataSource#getMaxConnDuration()}.
+ * @since 2.10.0
+ */
+Duration getMaxConnDuration();
+
+/**
   * See {@link BasicDataSource#getMaxConnLifetimeMillis()}.
   *
   * @return {@link BasicDataSource#getMaxConnLifetimeMillis()}.
+ *
+ * @deprecated Use {@link

Re: [commons-dbcp] branch master updated: Update MXBean for use of Duration with BasicDataSource

[Gary Gregory]

If you add methods to an existing interface, this will break binary
compatibility unless you add them as default methods. Or am i missing
something?

Gary

On Wed, Jan 5, 2022, 14:10  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> markt pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-dbcp.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 28eb33b  Update MXBean for use of Duration with BasicDataSource
> 28eb33b is described below
>
> commit 28eb33b5b3551de2e630a4cb59dc3bc5506f8114
> Author: Mark Thomas 
> AuthorDate: Wed Jan 5 19:07:51 2022 +
>
> Update MXBean for use of Duration with BasicDataSource
> ---
>  .../org/apache/commons/dbcp2/BasicDataSource.java  |  7 ++
>  .../org/apache/commons/dbcp2/DataSourceMXBean.java | 77
> ++
>  .../commons/dbcp2/TestBasicDataSourceMXBean.java   | 37 +++
>  3 files changed, 121 insertions(+)
>
> diff --git a/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
> b/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
> index 07615d2..bb451cd 100644
> --- a/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
> +++ b/src/main/java/org/apache/commons/dbcp2/BasicDataSource.java
> @@ -1064,6 +1064,7 @@ public class BasicDataSource implements DataSource,
> BasicDataSourceMXBean, MBean
>   * @return the maximum permitted duration of a connection.
>   * @since 2.10.0
>   */
> +@Override
>  public Duration getMaxConnDuration() {
>  return maxConnDuration;
>  }
> @@ -1123,6 +1124,7 @@ public class BasicDataSource implements DataSource,
> BasicDataSourceMXBean, MBean
>   * @return the maxWaitDuration property value.
>   * @since 2.10.0
>   */
> +@Override
>  public synchronized Duration getMaxWaitDuration() {
>  return this.maxWaitDuration;
>  }
> @@ -1147,6 +1149,7 @@ public class BasicDataSource implements DataSource,
> BasicDataSourceMXBean, MBean
>   * @see #setMinEvictableIdle(Duration)
>   * @since 2.10.0
>   */
> +@Override
>  public synchronized Duration getMinEvictableIdleDuration() {
>  return this.minEvictableIdleDuration;
>  }
> @@ -1324,6 +1327,7 @@ public class BasicDataSource implements DataSource,
> BasicDataSourceMXBean, MBean
>   * @return Timeout before an abandoned connection can be removed.
>   * @since 2.10.0
>   */
> +@Override
>  public Duration getRemoveAbandonedTimeoutDuration() {
>  return abandonedConfig == null ? Duration.ofSeconds(300) :
> abandonedConfig.getRemoveAbandonedTimeoutDuration();
>  }
> @@ -1353,6 +1357,7 @@ public class BasicDataSource implements DataSource,
> BasicDataSourceMXBean, MBean
>   * there are minIdle idle connections in the pool
>   * @since 2.10.0
>   */
> +@Override
>  public synchronized Duration getSoftMinEvictableIdleDuration() {
>  return softMinEvictableIdleDuration;
>  }
> @@ -1429,6 +1434,7 @@ public class BasicDataSource implements DataSource,
> BasicDataSourceMXBean, MBean
>   * @see #setDurationBetweenEvictionRuns(Duration)
>   * @since 2.10.0
>   */
> +@Override
>  public synchronized Duration getDurationBetweenEvictionRuns() {
>  return this.durationBetweenEvictionRuns;
>  }
> @@ -1482,6 +1488,7 @@ public class BasicDataSource implements DataSource,
> BasicDataSourceMXBean, MBean
>   *
>   * @return the timeout in seconds before connection validation
> queries fail.
>   */
> +@Override
>  public Duration getValidationQueryTimeoutDuration() {
>  return validationQueryTimeoutDuration;
>  }
> diff --git a/src/main/java/org/apache/commons/dbcp2/DataSourceMXBean.java
> b/src/main/java/org/apache/commons/dbcp2/DataSourceMXBean.java
> index 56fb5c8..9922542 100644
> --- a/src/main/java/org/apache/commons/dbcp2/DataSourceMXBean.java
> +++ b/src/main/java/org/apache/commons/dbcp2/DataSourceMXBean.java
> @@ -17,6 +17,7 @@
>  package org.apache.commons.dbcp2;
>
>  import java.sql.SQLException;
> +import java.time.Duration;
>
>  /**
>   * Defines the methods that will be made available via
> @@ -138,10 +139,21 @@ public interface DataSourceMXBean {
>  boolean getLogExpiredConnections();
>
>  /**
> + * See {@link BasicDataSource#getMaxConnDuration()}.
> + *
> + * @return {@link BasicDataSource#getMaxConnDuration()}.
> + * @since 2.10.0
> + */
> +Duration getMaxConnDuration();
> +
> +/**
>   * See {@link BasicDataSource#getMaxConnLifetimeMillis()}.
>   *
>   * @return {@link BasicDataSource#getMaxConnLifetimeMillis()}.
> + *
> + * @deprecated Use {@link #getMaxConnDuration()}.
>   */
> +@Deprecated
>  long getMaxConnLifetimeMillis();
>
>  /**
> @@ -166,17 +178,39 @@ public interface DataSourceMXBean {
>  int getMaxTotal();
>
>  /**
> + * See 

Re: [commons-dbcp] branch master updated: Trivial format fix. Use consistent formatting for all classes.

[Mark Thomas]

On 02/09/2021 16:16, Gary Gregory wrote:

The space after the license is on purpose, it is NOT like a Javadoc
comment, so I do not see why the change is needed. I add that space when it
is missing!



The code formatting was inconsistent. I went with what looked to be the 
majority format for DBCP although it wasn't far off a 50/50 split (maybe 
55/45).


I made the same change to Pool where only 1 file had the (arguably 
unnecessary) space.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[ANNOUNCE] Apache Commons DBCP 2.9.0

[Gary Gregory]

The Apache Commons DBCP team is pleased to announce the release of Apache
Apache Commons DBCP 2.9.0.

Apache Commons DBCP software implements Database Connection Pooling.

This is a minor release, including bug fixes and enhancements.

For complete information on Apache Commons DBCP, including instructions on
how to submit bug reports,
patches, or suggestions for improvement, see the Apache Apache Commons DBCP
website:

https://commons.apache.org/dbcp/

Download page: https://commons.apache.org/dbcp/download_dbcp.cgi

Gary Gregory,
Apache Commons Team

[ANNOUNCE] Apache Commons DBCP 2.9.0

[Gary Gregory]

The Apache Commons DBCP team is pleased to announce the release of
Apache Commons DBCP 2.9.0.

Apache Commons DBCP software implements Database Connection Pooling.

This is a minor release, including bug fixes and enhancements.

Changes in this version:
https://commons.apache.org/proper/commons-dbcp/changes-report.html#a2.9.0

For complete information on Apache Commons DBCP, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Apache Commons DBCP website:

https://commons.apache.org/dbcp/

Download page: https://commons.apache.org/dbcp/download_dbcp.cgi

Have fun!
Gary Gregory,
for the Apache Commons Team

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons DBCP 2.9.0 based on RC1

[Gary Gregory]

This VOTE passes with the following +1 votes:

- Matt Sicker, binding
- Arturo Bernal, non-binding
- Bruno P. Kinoshita, binding
- Rob Tompkins, binding
- Gary Gregory, binding

Thank you all for your time,
Gary

On Tue, Aug 3, 2021 at 4:37 PM Gary Gregory  wrote:

> My +1
>
> Gary
>
>
> On Tue, Aug 3, 2021 at 12:06 PM Rob Tompkins  wrote:
>
>> +1 signatures, reports (ioncluding RAT), and build look good for java8
>> and java11.
>>
>> Few nits in the SpotBugs, PMD, and CPD reports (nothing of consequence)
>>
>> Send it!
>>
>> -Rob
>>
>>
>>
>> > On Jul 31, 2021, at 11:19 AM, Gary Gregory 
>> wrote:
>> >
>> > We have fixed a few bugs and added some enhancements since Apache
>> > Commons DBCP 2.8.0 was released, so I would like to release Apache
>> > Commons DBCP 2.9.0.
>> >
>> > Apache Commons DBCP 2.9.0 RC1 is available for review here:
>> >https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1 (svn
>> > revision 49104)
>> >
>> > The Git tag commons-dbcp-2.9.0-RC1 commit for this RC is
>> > 2abdb498d0aa7b65d668fc5661795bc83844d8fa which you can browse here:
>> >
>> https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=2abdb498d0aa7b65d668fc5661795bc83844d8fa
>> > You may checkout this tag using:
>> >git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
>> > --branch commons-dbcp-2.9.0-RC1 commons-dbcp-2.9.0-RC1
>> >
>> > Maven artifacts are here:
>> >
>> https://repository.apache.org/content/repositories/orgapachecommons-1559/org/apache/commons/commons-dbcp2/2.9.0/
>> >
>> > These are the artifacts and their hashes:
>> >
>> > #Release SHA-512s
>> > #Sat Jul 31 11:10:11 EDT 2021
>> >
>> commons-dbcp2-2.9.0-bin.tar.gz=3d910565aefae7db7e659078dca9b5b82dc16522be88783a9362b2f26b39bf6e9a8f1bddcdf37b6d5839abff03a8b0934643a08a0d5685da8d20ccfd8a9d4164
>> >
>> commons-dbcp2-2.9.0-bin.zip=cdd212b8740b6a5a4ae34f03cf8a205be7a56c62c7a12b6fa8f8c48a05ecd813ecf566fcf6b5d4b03d7e6c81d2ac77f00f8ad4f222bbb7a45e677a566f681f25
>> >
>> commons-dbcp2-2.9.0-javadoc.jar=f8ddb21b3f5e43988befe868e777c00f7a5295b1954fa377d91575a2edbf394d0d1d87563615b34915f4128d00264d402a28aa26c08011e328b2f5b94d20df50
>> >
>> commons-dbcp2-2.9.0-sources.jar=54f65de7f5223081588c84a124843a0e4937fc81696599e27bf736122aaa589b71f707121704cd6ef2fd17316363b3db22a76bae63de5f0df184dffe7b95
>> >
>> commons-dbcp2-2.9.0-src.tar.gz=8f3d47030b71606af4113f09d80f681dc7882d9636cea453a650705582d1a9043397024042e42811eff0a69025965e60d11c578296062f4f05e7a49066344d9a
>> >
>> commons-dbcp2-2.9.0-src.zip=b0354f0e9c7d154095ffa1a2a736c606c8fc168146ffbab27614c9e297dd8e5b7d5719f92899dd51b23b63b7fa2c97786d2fae7f48d6b8ff357e742ef8ad097f
>> >
>> commons-dbcp2-2.9.0-test-sources.jar=c17bfd92f1dd7f9f6e074a69fed15827ad4e7d98210bf0d430e91e3842fd2a09c99c1ffb30d51b4c4745cd24925d52313c1215fadeb5bf414b094ccd256d6ae5
>> >
>> commons-dbcp2-2.9.0-tests.jar=a4484612e3f11c7b73b96aa6668bccd8dfa9d7dc3cb5a22821709b658ce3568dfff239cb1c168bc513bc88062389e137d95fd5ce206a8d2479aa1b3195255bfe
>> >
>> > I have tested this with
>> >
>> > mvn -V -Duser.name=$my_apache_id
>> > -Dcommons.release-plugin.version=$commons_release_plugin_version
>> > -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy
>> >
>> > using:
>> >
>> > Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
>> > Maven home: /usr/local/Cellar/maven/3.8.1/libexec
>> > Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
>> > /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
>> > Default locale: en_US, platform encoding: UTF-8
>> > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
>> >
>> > Darwin gdg-mac-mini.local 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun
>> > 23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 x86_64
>> >
>> > Details of changes since 2.8.0 are in the release notes:
>> >
>> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/RELEASE-NOTES.txt
>> >
>> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/changes-report.html
>> >
>> > Site:
>> >
>> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/index.html
>> >(note some *relative* links are broken and the 2.9.0 directories
>> > are not yet created - these will be OK once the site is 

Re: [VOTE] Release Apache Commons DBCP 2.9.0 based on RC1

[Gary Gregory]

My +1

Gary


On Tue, Aug 3, 2021 at 12:06 PM Rob Tompkins  wrote:

> +1 signatures, reports (ioncluding RAT), and build look good for java8 and
> java11.
>
> Few nits in the SpotBugs, PMD, and CPD reports (nothing of consequence)
>
> Send it!
>
> -Rob
>
>
>
> > On Jul 31, 2021, at 11:19 AM, Gary Gregory 
> wrote:
> >
> > We have fixed a few bugs and added some enhancements since Apache
> > Commons DBCP 2.8.0 was released, so I would like to release Apache
> > Commons DBCP 2.9.0.
> >
> > Apache Commons DBCP 2.9.0 RC1 is available for review here:
> >https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1 (svn
> > revision 49104)
> >
> > The Git tag commons-dbcp-2.9.0-RC1 commit for this RC is
> > 2abdb498d0aa7b65d668fc5661795bc83844d8fa which you can browse here:
> >
> https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=2abdb498d0aa7b65d668fc5661795bc83844d8fa
> > You may checkout this tag using:
> >git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
> > --branch commons-dbcp-2.9.0-RC1 commons-dbcp-2.9.0-RC1
> >
> > Maven artifacts are here:
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1559/org/apache/commons/commons-dbcp2/2.9.0/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Sat Jul 31 11:10:11 EDT 2021
> >
> commons-dbcp2-2.9.0-bin.tar.gz=3d910565aefae7db7e659078dca9b5b82dc16522be88783a9362b2f26b39bf6e9a8f1bddcdf37b6d5839abff03a8b0934643a08a0d5685da8d20ccfd8a9d4164
> >
> commons-dbcp2-2.9.0-bin.zip=cdd212b8740b6a5a4ae34f03cf8a205be7a56c62c7a12b6fa8f8c48a05ecd813ecf566fcf6b5d4b03d7e6c81d2ac77f00f8ad4f222bbb7a45e677a566f681f25
> >
> commons-dbcp2-2.9.0-javadoc.jar=f8ddb21b3f5e43988befe868e777c00f7a5295b1954fa377d91575a2edbf394d0d1d87563615b34915f4128d00264d402a28aa26c08011e328b2f5b94d20df50
> >
> commons-dbcp2-2.9.0-sources.jar=54f65de7f5223081588c84a124843a0e4937fc81696599e27bf736122aaa589b71f707121704cd6ef2fd17316363b3db22a76bae63de5f0df184dffe7b95
> >
> commons-dbcp2-2.9.0-src.tar.gz=8f3d47030b71606af4113f09d80f681dc7882d9636cea453a650705582d1a9043397024042e42811eff0a69025965e60d11c578296062f4f05e7a49066344d9a
> >
> commons-dbcp2-2.9.0-src.zip=b0354f0e9c7d154095ffa1a2a736c606c8fc168146ffbab27614c9e297dd8e5b7d5719f92899dd51b23b63b7fa2c97786d2fae7f48d6b8ff357e742ef8ad097f
> >
> commons-dbcp2-2.9.0-test-sources.jar=c17bfd92f1dd7f9f6e074a69fed15827ad4e7d98210bf0d430e91e3842fd2a09c99c1ffb30d51b4c4745cd24925d52313c1215fadeb5bf414b094ccd256d6ae5
> >
> commons-dbcp2-2.9.0-tests.jar=a4484612e3f11c7b73b96aa6668bccd8dfa9d7dc3cb5a22821709b658ce3568dfff239cb1c168bc513bc88062389e137d95fd5ce206a8d2479aa1b3195255bfe
> >
> > I have tested this with
> >
> > mvn -V -Duser.name=$my_apache_id
> > -Dcommons.release-plugin.version=$commons_release_plugin_version
> > -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy
> >
> > using:
> >
> > Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
> > Maven home: /usr/local/Cellar/maven/3.8.1/libexec
> > Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
> > /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
> >
> > Darwin gdg-mac-mini.local 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun
> > 23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 x86_64
> >
> > Details of changes since 2.8.0 are in the release notes:
> >
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/RELEASE-NOTES.txt
> >
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/changes-report.html
> >
> > Site:
> >
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/index.html
> >(note some *relative* links are broken and the 2.9.0 directories
> > are not yet created - these will be OK once the site is deployed.)
> >
> > JApiCmp Report (compared to 2.8.0):
> >
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/japicmp.html
> >Note that the above report contains text in red but nothing is
> > broken, just moved, and binary compatibility is maintained.
> >
> > RAT Report:
> >
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/rat-report.html
> >
> > KEYS:
> >  https://www.apache.org/dist/commons/KEYS
> >
> > Please review the release candidate and vote.
> > This vote will close no sooner than

Re: [VOTE] Release Apache Commons DBCP 2.9.0 based on RC1

[Rob Tompkins]

+1 signatures, reports (ioncluding RAT), and build look good for java8 and 
java11.

Few nits in the SpotBugs, PMD, and CPD reports (nothing of consequence)

Send it!

-Rob



> On Jul 31, 2021, at 11:19 AM, Gary Gregory  wrote:
> 
> We have fixed a few bugs and added some enhancements since Apache
> Commons DBCP 2.8.0 was released, so I would like to release Apache
> Commons DBCP 2.9.0.
> 
> Apache Commons DBCP 2.9.0 RC1 is available for review here:
>https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1 (svn
> revision 49104)
> 
> The Git tag commons-dbcp-2.9.0-RC1 commit for this RC is
> 2abdb498d0aa7b65d668fc5661795bc83844d8fa which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=2abdb498d0aa7b65d668fc5661795bc83844d8fa
> You may checkout this tag using:
>git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
> --branch commons-dbcp-2.9.0-RC1 commons-dbcp-2.9.0-RC1
> 
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1559/org/apache/commons/commons-dbcp2/2.9.0/
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> #Sat Jul 31 11:10:11 EDT 2021
> commons-dbcp2-2.9.0-bin.tar.gz=3d910565aefae7db7e659078dca9b5b82dc16522be88783a9362b2f26b39bf6e9a8f1bddcdf37b6d5839abff03a8b0934643a08a0d5685da8d20ccfd8a9d4164
> commons-dbcp2-2.9.0-bin.zip=cdd212b8740b6a5a4ae34f03cf8a205be7a56c62c7a12b6fa8f8c48a05ecd813ecf566fcf6b5d4b03d7e6c81d2ac77f00f8ad4f222bbb7a45e677a566f681f25
> commons-dbcp2-2.9.0-javadoc.jar=f8ddb21b3f5e43988befe868e777c00f7a5295b1954fa377d91575a2edbf394d0d1d87563615b34915f4128d00264d402a28aa26c08011e328b2f5b94d20df50
> commons-dbcp2-2.9.0-sources.jar=54f65de7f5223081588c84a124843a0e4937fc81696599e27bf736122aaa589b71f707121704cd6ef2fd17316363b3db22a76bae63de5f0df184dffe7b95
> commons-dbcp2-2.9.0-src.tar.gz=8f3d47030b71606af4113f09d80f681dc7882d9636cea453a650705582d1a9043397024042e42811eff0a69025965e60d11c578296062f4f05e7a49066344d9a
> commons-dbcp2-2.9.0-src.zip=b0354f0e9c7d154095ffa1a2a736c606c8fc168146ffbab27614c9e297dd8e5b7d5719f92899dd51b23b63b7fa2c97786d2fae7f48d6b8ff357e742ef8ad097f
> commons-dbcp2-2.9.0-test-sources.jar=c17bfd92f1dd7f9f6e074a69fed15827ad4e7d98210bf0d430e91e3842fd2a09c99c1ffb30d51b4c4745cd24925d52313c1215fadeb5bf414b094ccd256d6ae5
> commons-dbcp2-2.9.0-tests.jar=a4484612e3f11c7b73b96aa6668bccd8dfa9d7dc3cb5a22821709b658ce3568dfff239cb1c168bc513bc88062389e137d95fd5ce206a8d2479aa1b3195255bfe
> 
> I have tested this with
> 
> mvn -V -Duser.name=$my_apache_id
> -Dcommons.release-plugin.version=$commons_release_plugin_version
> -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy
> 
> using:
> 
> Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
> Maven home: /usr/local/Cellar/maven/3.8.1/libexec
> Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
> 
> Darwin gdg-mac-mini.local 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun
> 23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 x86_64
> 
> Details of changes since 2.8.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/changes-report.html
> 
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/index.html
>(note some *relative* links are broken and the 2.9.0 directories
> are not yet created - these will be OK once the site is deployed.)
> 
> JApiCmp Report (compared to 2.8.0):
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/japicmp.html
>Note that the above report contains text in red but nothing is
> broken, just moved, and binary compatibility is maintained.
> 
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/rat-report.html
> 
> KEYS:
>  https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
> 
>  [ ] +1 Release these artifacts
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [ ] -1 I oppose this release because...
> 
> Thank you,
> 
> Gary Gregory,
> Release Manager (using key 86fdc7e2a11262cb)
> 
> For following is intended as a helper and refresher for reviewers.
> 
> Validating a release candidate
> ==
> 
> These guidelines are NOT complete.
>

Re: [VOTE] Release Apache Commons DBCP 2.9.0 based on RC1

[Bruno P. Kinoshita]

 
  [x] +1 Release these artifacts

Build OK from tag with

Maven home: /opt/apache-maven-3.6.3
Java version: 11.0.11, vendor: Ubuntu, runtime: 
/usr/lib/jvm/java-11-openjdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-80-generic", arch: "amd64", family: "unix"

Site reports look good.


Thanks!
Bruno


On Sunday, 1 August 2021, 3:19:42 am NZST, Gary Gregory 
 wrote:  
 
 We have fixed a few bugs and added some enhancements since Apache
Commons DBCP 2.8.0 was released, so I would like to release Apache
Commons DBCP 2.9.0.

Apache Commons DBCP 2.9.0 RC1 is available for review here:
    https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1 (svn
revision 49104)

The Git tag commons-dbcp-2.9.0-RC1 commit for this RC is
2abdb498d0aa7b65d668fc5661795bc83844d8fa which you can browse here:
    
https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=2abdb498d0aa7b65d668fc5661795bc83844d8fa
You may checkout this tag using:
    git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
--branch commons-dbcp-2.9.0-RC1 commons-dbcp-2.9.0-RC1

Maven artifacts are here:
    
https://repository.apache.org/content/repositories/orgapachecommons-1559/org/apache/commons/commons-dbcp2/2.9.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Sat Jul 31 11:10:11 EDT 2021
commons-dbcp2-2.9.0-bin.tar.gz=3d910565aefae7db7e659078dca9b5b82dc16522be88783a9362b2f26b39bf6e9a8f1bddcdf37b6d5839abff03a8b0934643a08a0d5685da8d20ccfd8a9d4164
commons-dbcp2-2.9.0-bin.zip=cdd212b8740b6a5a4ae34f03cf8a205be7a56c62c7a12b6fa8f8c48a05ecd813ecf566fcf6b5d4b03d7e6c81d2ac77f00f8ad4f222bbb7a45e677a566f681f25
commons-dbcp2-2.9.0-javadoc.jar=f8ddb21b3f5e43988befe868e777c00f7a5295b1954fa377d91575a2edbf394d0d1d87563615b34915f4128d00264d402a28aa26c08011e328b2f5b94d20df50
commons-dbcp2-2.9.0-sources.jar=54f65de7f5223081588c84a124843a0e4937fc81696599e27bf736122aaa589b71f707121704cd6ef2fd17316363b3db22a76bae63de5f0df184dffe7b95
commons-dbcp2-2.9.0-src.tar.gz=8f3d47030b71606af4113f09d80f681dc7882d9636cea453a650705582d1a9043397024042e42811eff0a69025965e60d11c578296062f4f05e7a49066344d9a
commons-dbcp2-2.9.0-src.zip=b0354f0e9c7d154095ffa1a2a736c606c8fc168146ffbab27614c9e297dd8e5b7d5719f92899dd51b23b63b7fa2c97786d2fae7f48d6b8ff357e742ef8ad097f
commons-dbcp2-2.9.0-test-sources.jar=c17bfd92f1dd7f9f6e074a69fed15827ad4e7d98210bf0d430e91e3842fd2a09c99c1ffb30d51b4c4745cd24925d52313c1215fadeb5bf414b094ccd256d6ae5
commons-dbcp2-2.9.0-tests.jar=a4484612e3f11c7b73b96aa6668bccd8dfa9d7dc3cb5a22821709b658ce3568dfff239cb1c168bc513bc88062389e137d95fd5ce206a8d2479aa1b3195255bfe

I have tested this with

mvn -V -Duser.name=$my_apache_id
-Dcommons.release-plugin.version=$commons_release_plugin_version
-Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy

 using:

Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
Maven home: /usr/local/Cellar/maven/3.8.1/libexec
Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"

Darwin gdg-mac-mini.local 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun
23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 x86_64

Details of changes since 2.8.0 are in the release notes:
    
https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/RELEASE-NOTES.txt
    
https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/changes-report.html

Site:
    
https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/index.html
    (note some *relative* links are broken and the 2.9.0 directories
are not yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 2.8.0):
    
https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/japicmp.html
    Note that the above report contains text in red but nothing is
broken, just moved, and binary compatibility is maintained.

RAT Report:
    
https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Gary Gregory,
Release Manager (using key 86fdc7e2a11262cb)

For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
--branch commons-dbcp-2.9.0-RC1 commo

Re: [VOTE] Release Apache Commons DBCP 2.9.0 based on RC1

[Arturo Bernal]

[x] +1 Release these artifacts


Building OK from tag, with `clean test install` targets.
Building OK from tag, with `site:site` targets
Browsed site, Javadoc and reports, looks ok. 



Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
Maven home: /opt/apache-maven-3.8.1
Java version: 16, vendor: Oracle Corporation, runtime: 
/Users/abernal/Library/Java/JavaVirtualMachines/openjdk-16/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: “mac"





Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
Maven home: /opt/apache-maven-3.8.1
Java version: 1.8.0_275, vendor: AdoptOpenJDK, runtime: 
/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: “mac"


Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
Maven home: /opt/apache-maven-3.8.1
Java version: 11.0.5, vendor: Oracle Corporation, runtime: 
/Library/Java/JavaVirtualMachines/jdk-11.0.5.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"


Arturo Bernal
arturobern...@yahoo.com



> On 31 Jul 2021, at 20:54, Matt Sicker  wrote:
> 
> +1
> 
> Signatures, reports, etc. validated.
> Built and tested on:
> 
> Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
> Maven home: /usr/local/Cellar/maven/3.8.1/libexec
> Java version: 16.0.1, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk/16.0.1/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "11.4", arch: "x86_64", family: "mac"
> 
> Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
> Maven home: /usr/local/Cellar/maven/3.8.1/libexec
> Java version: 11.0.10, vendor: Oracle Corporation, runtime:
> /usr/local/Cellar/openjdk@11/11.0.10/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "11.4", arch: "x86_64", family: "mac"
> 
> Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
> Maven home: /usr/local/Cellar/maven/3.8.1/libexec
> Java version: 17-ea, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "11.4", arch: "x86_64", family: "mac"
> 
> On Sat, Jul 31, 2021 at 10:19 AM Gary Gregory  wrote:
>> 
>> We have fixed a few bugs and added some enhancements since Apache
>> Commons DBCP 2.8.0 was released, so I would like to release Apache
>> Commons DBCP 2.9.0.
>> 
>> Apache Commons DBCP 2.9.0 RC1 is available for review here:
>>https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1 (svn
>> revision 49104)
>> 
>> The Git tag commons-dbcp-2.9.0-RC1 commit for this RC is
>> 2abdb498d0aa7b65d668fc5661795bc83844d8fa which you can browse here:
>>
>> https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=2abdb498d0aa7b65d668fc5661795bc83844d8fa
>> You may checkout this tag using:
>>git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
>> --branch commons-dbcp-2.9.0-RC1 commons-dbcp-2.9.0-RC1
>> 
>> Maven artifacts are here:
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1559/org/apache/commons/commons-dbcp2/2.9.0/
>> 
>> These are the artifacts and their hashes:
>> 
>> #Release SHA-512s
>> #Sat Jul 31 11:10:11 EDT 2021
>> commons-dbcp2-2.9.0-bin.tar.gz=3d910565aefae7db7e659078dca9b5b82dc16522be88783a9362b2f26b39bf6e9a8f1bddcdf37b6d5839abff03a8b0934643a08a0d5685da8d20ccfd8a9d4164
>> commons-dbcp2-2.9.0-bin.zip=cdd212b8740b6a5a4ae34f03cf8a205be7a56c62c7a12b6fa8f8c48a05ecd813ecf566fcf6b5d4b03d7e6c81d2ac77f00f8ad4f222bbb7a45e677a566f681f25
>> commons-dbcp2-2.9.0-javadoc.jar=f8ddb21b3f5e43988befe868e777c00f7a5295b1954fa377d91575a2edbf394d0d1d87563615b34915f4128d00264d402a28aa26c08011e328b2f5b94d20df50
>> commons-dbcp2-2.9.0-sources.jar=54f65de7f5223081588c84a124843a0e4937fc81696599e27bf736122aaa589b71f707121704cd6ef2fd17316363b3db22a76bae63de5f0df184dffe7b95
>> commons-dbcp2-2.9.0-src.tar.gz=8f3d47030b71606af4113f09d80f681dc7882d9636cea453a650705582d1a9043397024042e42811eff0a69025965e60d11c578296062f4f05e7a49066344d9a
>> commons-dbcp2-2.9.0-src.zip=b0354f0e9c7d154095ffa1a2a736c606c8fc168146ffbab27614c9e297dd8e5b7d5719f92899dd51b23b63b7fa2c97786d2fae7f48d6

Re: [VOTE] Release Apache Commons DBCP 2.9.0 based on RC1

[Matt Sicker]

+1

Signatures, reports, etc. validated.
Built and tested on:

Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
Maven home: /usr/local/Cellar/maven/3.8.1/libexec
Java version: 16.0.1, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk/16.0.1/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "11.4", arch: "x86_64", family: "mac"

Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
Maven home: /usr/local/Cellar/maven/3.8.1/libexec
Java version: 11.0.10, vendor: Oracle Corporation, runtime:
/usr/local/Cellar/openjdk@11/11.0.10/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "11.4", arch: "x86_64", family: "mac"

Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
Maven home: /usr/local/Cellar/maven/3.8.1/libexec
Java version: 17-ea, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "11.4", arch: "x86_64", family: "mac"

On Sat, Jul 31, 2021 at 10:19 AM Gary Gregory  wrote:
>
> We have fixed a few bugs and added some enhancements since Apache
> Commons DBCP 2.8.0 was released, so I would like to release Apache
> Commons DBCP 2.9.0.
>
> Apache Commons DBCP 2.9.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1 (svn
> revision 49104)
>
> The Git tag commons-dbcp-2.9.0-RC1 commit for this RC is
> 2abdb498d0aa7b65d668fc5661795bc83844d8fa which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=2abdb498d0aa7b65d668fc5661795bc83844d8fa
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
> --branch commons-dbcp-2.9.0-RC1 commons-dbcp-2.9.0-RC1
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1559/org/apache/commons/commons-dbcp2/2.9.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Sat Jul 31 11:10:11 EDT 2021
> commons-dbcp2-2.9.0-bin.tar.gz=3d910565aefae7db7e659078dca9b5b82dc16522be88783a9362b2f26b39bf6e9a8f1bddcdf37b6d5839abff03a8b0934643a08a0d5685da8d20ccfd8a9d4164
> commons-dbcp2-2.9.0-bin.zip=cdd212b8740b6a5a4ae34f03cf8a205be7a56c62c7a12b6fa8f8c48a05ecd813ecf566fcf6b5d4b03d7e6c81d2ac77f00f8ad4f222bbb7a45e677a566f681f25
> commons-dbcp2-2.9.0-javadoc.jar=f8ddb21b3f5e43988befe868e777c00f7a5295b1954fa377d91575a2edbf394d0d1d87563615b34915f4128d00264d402a28aa26c08011e328b2f5b94d20df50
> commons-dbcp2-2.9.0-sources.jar=54f65de7f5223081588c84a124843a0e4937fc81696599e27bf736122aaa589b71f707121704cd6ef2fd17316363b3db22a76bae63de5f0df184dffe7b95
> commons-dbcp2-2.9.0-src.tar.gz=8f3d47030b71606af4113f09d80f681dc7882d9636cea453a650705582d1a9043397024042e42811eff0a69025965e60d11c578296062f4f05e7a49066344d9a
> commons-dbcp2-2.9.0-src.zip=b0354f0e9c7d154095ffa1a2a736c606c8fc168146ffbab27614c9e297dd8e5b7d5719f92899dd51b23b63b7fa2c97786d2fae7f48d6b8ff357e742ef8ad097f
> commons-dbcp2-2.9.0-test-sources.jar=c17bfd92f1dd7f9f6e074a69fed15827ad4e7d98210bf0d430e91e3842fd2a09c99c1ffb30d51b4c4745cd24925d52313c1215fadeb5bf414b094ccd256d6ae5
> commons-dbcp2-2.9.0-tests.jar=a4484612e3f11c7b73b96aa6668bccd8dfa9d7dc3cb5a22821709b658ce3568dfff239cb1c168bc513bc88062389e137d95fd5ce206a8d2479aa1b3195255bfe
>
> I have tested this with
>
> mvn -V -Duser.name=$my_apache_id
> -Dcommons.release-plugin.version=$commons_release_plugin_version
> -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy
>
>  using:
>
> Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
> Maven home: /usr/local/Cellar/maven/3.8.1/libexec
> Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
>
> Darwin gdg-mac-mini.local 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun
> 23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 x86_64
>
> Details of changes since 2.8.0 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/changes-report.html
>
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/index.html
> (note some *relative* links are broken and the 2.9.0 directories
> are not yet created - these will be OK once the site is depl

[VOTE] Release Apache Commons DBCP 2.9.0 based on RC1

[Gary Gregory]

We have fixed a few bugs and added some enhancements since Apache
Commons DBCP 2.8.0 was released, so I would like to release Apache
Commons DBCP 2.9.0.

Apache Commons DBCP 2.9.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1 (svn
revision 49104)

The Git tag commons-dbcp-2.9.0-RC1 commit for this RC is
2abdb498d0aa7b65d668fc5661795bc83844d8fa which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=2abdb498d0aa7b65d668fc5661795bc83844d8fa
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
--branch commons-dbcp-2.9.0-RC1 commons-dbcp-2.9.0-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1559/org/apache/commons/commons-dbcp2/2.9.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Sat Jul 31 11:10:11 EDT 2021
commons-dbcp2-2.9.0-bin.tar.gz=3d910565aefae7db7e659078dca9b5b82dc16522be88783a9362b2f26b39bf6e9a8f1bddcdf37b6d5839abff03a8b0934643a08a0d5685da8d20ccfd8a9d4164
commons-dbcp2-2.9.0-bin.zip=cdd212b8740b6a5a4ae34f03cf8a205be7a56c62c7a12b6fa8f8c48a05ecd813ecf566fcf6b5d4b03d7e6c81d2ac77f00f8ad4f222bbb7a45e677a566f681f25
commons-dbcp2-2.9.0-javadoc.jar=f8ddb21b3f5e43988befe868e777c00f7a5295b1954fa377d91575a2edbf394d0d1d87563615b34915f4128d00264d402a28aa26c08011e328b2f5b94d20df50
commons-dbcp2-2.9.0-sources.jar=54f65de7f5223081588c84a124843a0e4937fc81696599e27bf736122aaa589b71f707121704cd6ef2fd17316363b3db22a76bae63de5f0df184dffe7b95
commons-dbcp2-2.9.0-src.tar.gz=8f3d47030b71606af4113f09d80f681dc7882d9636cea453a650705582d1a9043397024042e42811eff0a69025965e60d11c578296062f4f05e7a49066344d9a
commons-dbcp2-2.9.0-src.zip=b0354f0e9c7d154095ffa1a2a736c606c8fc168146ffbab27614c9e297dd8e5b7d5719f92899dd51b23b63b7fa2c97786d2fae7f48d6b8ff357e742ef8ad097f
commons-dbcp2-2.9.0-test-sources.jar=c17bfd92f1dd7f9f6e074a69fed15827ad4e7d98210bf0d430e91e3842fd2a09c99c1ffb30d51b4c4745cd24925d52313c1215fadeb5bf414b094ccd256d6ae5
commons-dbcp2-2.9.0-tests.jar=a4484612e3f11c7b73b96aa6668bccd8dfa9d7dc3cb5a22821709b658ce3568dfff239cb1c168bc513bc88062389e137d95fd5ce206a8d2479aa1b3195255bfe

I have tested this with

mvn -V -Duser.name=$my_apache_id
-Dcommons.release-plugin.version=$commons_release_plugin_version
-Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy

 using:

Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
Maven home: /usr/local/Cellar/maven/3.8.1/libexec
Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"

Darwin gdg-mac-mini.local 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun
23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 x86_64

Details of changes since 2.8.0 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/changes-report.html

Site:

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/index.html
(note some *relative* links are broken and the 2.9.0 directories
are not yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 2.8.0):

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/japicmp.html
Note that the above report contains text in red but nothing is
broken, just moved, and binary compatibility is maintained.

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Gary Gregory,
Release Manager (using key 86fdc7e2a11262cb)

For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
--branch commons-dbcp-2.9.0-RC1 commons-dbcp-2.9.0-RC1
cd commons-dbcp-2.9.0-RC1

2) Check Apache licenses

This step is not required if the site includes a RAT report page which
you then must check.

mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

This step is not required if the site includes a Clirr report page
which you then must check.

mvn clirr:check

Newer components use JApiCmp with the japicmp Maven Profile:

This step is not required if the s

Re: [DBCP] TestSynchronizationOrder failure, random or bug

[Florent Guillaume]

Here it is:
https://github.com/apache/commons-dbcp/pull/84
associated to ticket:
https://issues.apache.org/jira/browse/DBCP-569

Florent

On Mon, Jan 4, 2021 at 12:24 AM Gary Gregory  wrote:

> On Sat, Jan 2, 2021 at 2:39 PM Florent Guillaume 
> wrote:
>
> > Hi Gary,
> >
> > I reproduce it too in my Eclipse. I think it's a bug in the test.
> >
> > The TransactionContext.transactionRef and the TransactionRegistry.caches
> > are holding onto the Transaction (acquired in
> > TransactionRegistry.getActiveTransactionContext()) only using weak refs.
> > However in TestSynchronizationOrder the fake TransactionManager returns a
> > Transaction (that's an instance of an anonymous class) but nobody holds a
> > strong reference to that. I think that the fake TransactionManager should
> > create the fake Transaction at begin() time, and hold onto it using a
> > strong reference until commit() time.
> >
>
> Florent,
>
> Thank you for your analysis.
>
> May you please create a PR to bulletproof the test as you described?
>
> Gary
>
>
> > Florent
> >
> >
> > On Tue, Dec 29, 2020 at 7:56 PM Gary Gregory 
> > wrote:
> >
> > > Hi All:
> > >
> > > I just saw on
> > >
> > >
> >
> https://github.com/apache/commons-dbcp/runs/1622526568?check_suite_focus=true
> > >
> > > [INFO] Running
> org.apache.commons.dbcp2.managed.TestSynchronizationOrder
> > > Error:  Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> > > 0.088 s <<< FAILURE! - in
> > > org.apache.commons.dbcp2.managed.TestSynchronizationOrder
> > > Error:  testInterposedSynchronization  Time elapsed: 0.077 s  <<<
> ERROR!
> > > java.sql.SQLException: Unable to enlist connection because the
> > transaction
> > > has been garbage collected
> > > at
> > >
> > >
> >
> org.apache.commons.dbcp2.managed.TestSynchronizationOrder.testInterposedSynchronization(TestSynchronizationOrder.java:118)
> > >
> > > Is this random or a bug?
> > >
> > > Gary
> > >
> >
> >
> > --
> > [image: Nuxeo Logo] <https://www.nuxeo.com/>
> >
> > Florent Guillaume  Head of R  [image: LinkedIn]
> > <https://www.linkedin.com/in/fguillaume/> [image: Twitter]
> > <https://twitter.com/efge> [image: Github] <https://github.com/efge>
> >
> > Nuxeo Content Services Platform. Stay ahead.
> >
>


-- 
[image: Nuxeo Logo] <https://www.nuxeo.com/>

Florent Guillaume  Head of R  [image: LinkedIn]
<https://www.linkedin.com/in/fguillaume/> [image: Twitter]
<https://twitter.com/efge> [image: Github] <https://github.com/efge>

Nuxeo Content Services Platform. Stay ahead.

Re: [DBCP] TestSynchronizationOrder failure, random or bug

[Gary Gregory]

On Sat, Jan 2, 2021 at 2:39 PM Florent Guillaume 
wrote:

> Hi Gary,
>
> I reproduce it too in my Eclipse. I think it's a bug in the test.
>
> The TransactionContext.transactionRef and the TransactionRegistry.caches
> are holding onto the Transaction (acquired in
> TransactionRegistry.getActiveTransactionContext()) only using weak refs.
> However in TestSynchronizationOrder the fake TransactionManager returns a
> Transaction (that's an instance of an anonymous class) but nobody holds a
> strong reference to that. I think that the fake TransactionManager should
> create the fake Transaction at begin() time, and hold onto it using a
> strong reference until commit() time.
>

Florent,

Thank you for your analysis.

May you please create a PR to bulletproof the test as you described?

Gary


> Florent
>
>
> On Tue, Dec 29, 2020 at 7:56 PM Gary Gregory 
> wrote:
>
> > Hi All:
> >
> > I just saw on
> >
> >
> https://github.com/apache/commons-dbcp/runs/1622526568?check_suite_focus=true
> >
> > [INFO] Running org.apache.commons.dbcp2.managed.TestSynchronizationOrder
> > Error:  Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> > 0.088 s <<< FAILURE! - in
> > org.apache.commons.dbcp2.managed.TestSynchronizationOrder
> > Error:  testInterposedSynchronization  Time elapsed: 0.077 s  <<< ERROR!
> > java.sql.SQLException: Unable to enlist connection because the
> transaction
> > has been garbage collected
> > at
> >
> >
> org.apache.commons.dbcp2.managed.TestSynchronizationOrder.testInterposedSynchronization(TestSynchronizationOrder.java:118)
> >
> > Is this random or a bug?
> >
> > Gary
> >
>
>
> --
> [image: Nuxeo Logo] <https://www.nuxeo.com/>
>
> Florent Guillaume  Head of R  [image: LinkedIn]
> <https://www.linkedin.com/in/fguillaume/> [image: Twitter]
> <https://twitter.com/efge> [image: Github] <https://github.com/efge>
>
> Nuxeo Content Services Platform. Stay ahead.
>

Re: [DBCP] TestSynchronizationOrder failure, random or bug

[Florent Guillaume]

Hi Gary,

I reproduce it too in my Eclipse. I think it's a bug in the test.

The TransactionContext.transactionRef and the TransactionRegistry.caches
are holding onto the Transaction (acquired in
TransactionRegistry.getActiveTransactionContext()) only using weak refs.
However in TestSynchronizationOrder the fake TransactionManager returns a
Transaction (that's an instance of an anonymous class) but nobody holds a
strong reference to that. I think that the fake TransactionManager should
create the fake Transaction at begin() time, and hold onto it using a
strong reference until commit() time.

Florent


On Tue, Dec 29, 2020 at 7:56 PM Gary Gregory  wrote:

> Hi All:
>
> I just saw on
>
> https://github.com/apache/commons-dbcp/runs/1622526568?check_suite_focus=true
>
> [INFO] Running org.apache.commons.dbcp2.managed.TestSynchronizationOrder
> Error:  Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 0.088 s <<< FAILURE! - in
> org.apache.commons.dbcp2.managed.TestSynchronizationOrder
> Error:  testInterposedSynchronization  Time elapsed: 0.077 s  <<< ERROR!
> java.sql.SQLException: Unable to enlist connection because the transaction
> has been garbage collected
> at
>
> org.apache.commons.dbcp2.managed.TestSynchronizationOrder.testInterposedSynchronization(TestSynchronizationOrder.java:118)
>
> Is this random or a bug?
>
> Gary
>


-- 
[image: Nuxeo Logo] <https://www.nuxeo.com/>

Florent Guillaume  Head of R  [image: LinkedIn]
<https://www.linkedin.com/in/fguillaume/> [image: Twitter]
<https://twitter.com/efge> [image: Github] <https://github.com/efge>

Nuxeo Content Services Platform. Stay ahead.

[DBCP] TestSynchronizationOrder failure, random or bug

[Gary Gregory]

Hi All:

I just saw on
https://github.com/apache/commons-dbcp/runs/1622526568?check_suite_focus=true

[INFO] Running org.apache.commons.dbcp2.managed.TestSynchronizationOrder
Error:  Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
0.088 s <<< FAILURE! - in
org.apache.commons.dbcp2.managed.TestSynchronizationOrder
Error:  testInterposedSynchronization  Time elapsed: 0.077 s  <<< ERROR!
java.sql.SQLException: Unable to enlist connection because the transaction
has been garbage collected
at
org.apache.commons.dbcp2.managed.TestSynchronizationOrder.testInterposedSynchronization(TestSynchronizationOrder.java:118)

Is this random or a bug?

Gary

Re: [DBCP] ManagedConnection must clear its cached state after transaction completes

[Florent Guillaume]

Hi,

You're right. I've now added a test in the PR.

Thanks,
Florent


On Thu, Dec 10, 2020 at 8:55 PM Gary Gregory  wrote:

> Hi Florent,
>
> There has to be a way to test SOMETHING about this, using H2 for example,
> or mocking, otherwise, this is just a regression bug waiting to happen.
>
> Gary
>
> On Tue, Dec 8, 2020 at 7:19 PM Florent Guillaume 
> wrote:
>
> > Hi,
> >
> > A few weeks ago I opened the ticket
> > https://issues.apache.org/jira/browse/DBCP-568 (ManagedConnection must
> > clear its cached state after transaction completes)
> > with an associated proposed fix at
> > https://github.com/apache/commons-dbcp/pull/75.
> > Would anyone be interested in reviewing this?
> >
> > Thanks,
> > Florent
> >
> > --
> > [image: Nuxeo Logo] <https://www.nuxeo.com/>
> >
> > Florent Guillaume  Head of R  [image: LinkedIn]
> > <https://www.linkedin.com/in/fguillaume/> [image: Twitter]
> > <https://twitter.com/efge> [image: Github] <https://github.com/efge>
> >
> > Nuxeo Content Services Platform. Stay ahead.
> >
>


-- 
[image: Nuxeo Logo] <https://www.nuxeo.com/>

Florent Guillaume  Head of R  [image: LinkedIn]
<https://www.linkedin.com/in/fguillaume/> [image: Twitter]
<https://twitter.com/efge> [image: Github] <https://github.com/efge>

Nuxeo Content Services Platform. Stay ahead.

Re: [DBCP] ManagedConnection must clear its cached state after transaction completes

[Gary Gregory]

Hi Florent,

There has to be a way to test SOMETHING about this, using H2 for example,
or mocking, otherwise, this is just a regression bug waiting to happen.

Gary

On Tue, Dec 8, 2020 at 7:19 PM Florent Guillaume 
wrote:

> Hi,
>
> A few weeks ago I opened the ticket
> https://issues.apache.org/jira/browse/DBCP-568 (ManagedConnection must
> clear its cached state after transaction completes)
> with an associated proposed fix at
> https://github.com/apache/commons-dbcp/pull/75.
> Would anyone be interested in reviewing this?
>
> Thanks,
> Florent
>
> --
> [image: Nuxeo Logo] <https://www.nuxeo.com/>
>
> Florent Guillaume  Head of R  [image: LinkedIn]
> <https://www.linkedin.com/in/fguillaume/> [image: Twitter]
> <https://twitter.com/efge> [image: Github] <https://github.com/efge>
>
> Nuxeo Content Services Platform. Stay ahead.
>

[DBCP] ManagedConnection must clear its cached state after transaction completes

[Florent Guillaume]

Hi,

A few weeks ago I opened the ticket
https://issues.apache.org/jira/browse/DBCP-568 (ManagedConnection must
clear its cached state after transaction completes)
with an associated proposed fix at
https://github.com/apache/commons-dbcp/pull/75.
Would anyone be interested in reviewing this?

Thanks,
Florent

-- 
[image: Nuxeo Logo] <https://www.nuxeo.com/>

Florent Guillaume  Head of R  [image: LinkedIn]
<https://www.linkedin.com/in/fguillaume/> [image: Twitter]
<https://twitter.com/efge> [image: Github] <https://github.com/efge>

Nuxeo Content Services Platform. Stay ahead.

Re: [commons-dbcp] 03/09: Use for-each loops

[Phil Steitz]

First, many thanks for the cleanup work.

One thing to bear in mind for the loop changes is that in some cases the 
underlying collections may be changing as the loops progress. In theory, 
unit tests should pick up any problems introduced, but we should look 
carefully at this.


Phil

On 12/4/20 6:15 AM, ebo...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

ebourg pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/commons-dbcp.git

commit 309e204345a7b5181c883b6aa2d8497313f625ef
Author: Emmanuel Bourg 
AuthorDate: Fri Dec 4 13:32:19 2020 +0100

 Use for-each loops
---
  .../java/org/apache/commons/dbcp2/DelegatingConnection.java  |  5 +
  .../dbcp2/datasources/InstanceKeyDataSourceFactory.java  | 12 +++-
  2 files changed, 4 insertions(+), 13 deletions(-)

diff --git a/src/main/java/org/apache/commons/dbcp2/DelegatingConnection.java 
b/src/main/java/org/apache/commons/dbcp2/DelegatingConnection.java
index bdceb41..e7aeb61 100644
--- a/src/main/java/org/apache/commons/dbcp2/DelegatingConnection.java
+++ b/src/main/java/org/apache/commons/dbcp2/DelegatingConnection.java
@@ -36,7 +36,6 @@ import java.sql.Statement;
  import java.sql.Struct;
  import java.util.ArrayList;
  import java.util.Collections;
-import java.util.Iterator;
  import java.util.List;
  import java.util.Map;
  import java.util.Properties;
@@ -620,9 +619,7 @@ public class DelegatingConnection 
extends AbandonedTrace i
  final List traces = getTrace();
  if (traces != null && !traces.isEmpty()) {
  final List thrownList = new ArrayList<>();
-final Iterator traceIter = traces.iterator();
-while (traceIter.hasNext()) {
-final Object trace = traceIter.next();
+for (Object trace : traces) {
  if (trace instanceof Statement) {
  try {
  ((Statement) trace).close();
diff --git 
a/src/main/java/org/apache/commons/dbcp2/datasources/InstanceKeyDataSourceFactory.java
 
b/src/main/java/org/apache/commons/dbcp2/datasources/InstanceKeyDataSourceFactory.java
index f6ee923..8be3df3 100644
--- 
a/src/main/java/org/apache/commons/dbcp2/datasources/InstanceKeyDataSourceFactory.java
+++ 
b/src/main/java/org/apache/commons/dbcp2/datasources/InstanceKeyDataSourceFactory.java
@@ -21,7 +21,6 @@ import java.io.IOException;
  import java.io.ObjectInputStream;
  import java.util.ArrayList;
  import java.util.Hashtable;
-import java.util.Iterator;
  import java.util.List;
  import java.util.Map;
  import java.util.Map.Entry;
@@ -47,9 +46,7 @@ abstract class InstanceKeyDataSourceFactory implements 
ObjectFactory {
  
  static synchronized String registerNewInstance(final InstanceKeyDataSource ds) {

  int max = 0;
-final Iterator iterator = instanceMap.keySet().iterator();
-while (iterator.hasNext()) {
-final String s = iterator.next();
+for (String s : instanceMap.keySet()) {
  if (s != null) {
  try {
  max = Math.max(max, Integer.parseInt(s));
@@ -84,13 +81,10 @@ abstract class InstanceKeyDataSourceFactory implements 
ObjectFactory {
  public static void closeAll() throws Exception {
  // Get iterator to loop over all instances of this data source.
  final List exceptionList = new 
ArrayList<>(instanceMap.size());
-final Iterator> instanceIterator 
= instanceMap.entrySet().iterator();
-while (instanceIterator.hasNext()) {
+for (Entry next : 
instanceMap.entrySet()) {
  // Bullet-proof to avoid anything else but problems from 
InstanceKeyDataSource#close().
-final Entry next = 
instanceIterator.next();
  if (next != null) {
-@SuppressWarnings("resource")
-final InstanceKeyDataSource value = next.getValue();
+@SuppressWarnings("resource") final InstanceKeyDataSource 
value = next.getValue();
  if (value != null) {
  try {
  value.close();




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [dbcp][pool] Use abort instead of close for abandoned connections?

[Gary Gregory]

Reusing this thread to note FTR that a new version of POOL is out and that
a DBCP PR based of the new POOL is in progress...

Gary

On Wed, Sep 23, 2020, 19:28 Gary Gregory  wrote:

> On Wed, Sep 23, 2020 at 6:31 PM Phil Steitz  wrote:
>
>>
>> On 9/23/20 2:57 PM, Gary Gregory wrote:
>> > This all sounds reasonable but it would be easier to see in a PR.
>>
>> I will do that once the new version of [pool] is released. Otherwise, I
>> would have to add snapshot dependency, which I am sure would cause CI to
>> fail.
>>
>
> OK, sounds good, I'll push out a [pool] RC later this week after the
> [dbcp] RC.
>
> Gary
>
>
>>
>> Phil
>>
>> >
>> > Gary
>> >
>> > On Tue, Sep 22, 2020 at 8:30 PM Phil Steitz 
>> wrote:
>> >
>> >> On 9/14/20 10:10 AM, Gary Gregory wrote:
>> >>> On Mon, Sep 14, 2020 at 1:07 PM Phil Steitz 
>> >> wrote:
>> >>>> On 9/14/20 9:36 AM, Gary Gregory wrote:
>> >>>>> This feature is now in Pool master. I will prepare an RC soon if you
>> >>>>> all think we are good to go so we can then move on to DBCP.
>> >>>> I am still working on testing this in the DBCP use case. Probably
>> best
>> >>>> to wait a little for others to review and for me to get the DBCP
>> change
>> >>>> tested against current pool sources.  I should be able to finish that
>> >>>> this weekend.
>> >> I implemented changes in DBCP, based on recently committed changes in
>> >> pool.  I made a few decisions that I would appreciate feedback on.
>> >>
>> >> 1. The JDBC abort method requires an Executor as actual parameter.  I
>> >> added a FixedThreadPool executor with a max of 3 threads to
>> >> PoolableConnectionFactory for this purpose.  Given that this operation
>> >> might hang sometimes, I thought it best to allow more than a single
>> >> thread.  I guess it could be configurable, but 3 seemed a reasonable
>> >> choice.  I copied the custom thread factory used by pool's
>> EvictionTimer
>> >> to source daemon threads based on ccl for this.  I then added a close()
>> >> method to PCF that closes the executor and modified BasicDataSource
>> >> close to call this.
>> >>
>> >> 2. I used p.getObject().getInnermostDelegate().abort(executor) in PCF
>> >> destroyObject when abandoned mode is passed in rather than just
>> >> getObject().abort as destroy invokes close (I wonder if that is a bug?)
>> >>
>> >> 3. I changed JdbcBridge#abort to remove the checkOpen() check.  I was
>> >> getting exceptions in my concurrency tests where connections were being
>> >> closed but then considered abandoned.  This is a legit race that abort
>> >> will generally handle fine and I don't see the need to throw.
>> >>
>> >> Phil
>> >>
>> >>> Sounds good.
>> >>>
>> >>> Gary
>> >>>
>> >>>> Phil
>> >>>>
>> >>>>> Gary
>> >>>>>
>> >>>>> On Tue, Sep 8, 2020 at 9:16 AM Gary Gregory > >
>> >> wrote:
>> >>>>>> FWIW, I like the name "DestroyMode" because it matches the
>> "destroy"
>> >> in the method name.
>> >>>>>> Gary
>> >>>>>>
>> >>>>>> On Mon, Sep 7, 2020, 19:08 Gary Gregory 
>> >> wrote:
>> >>>>>>> On Mon, Sep 7, 2020 at 6:02 PM Phil Steitz > >
>> >> wrote:
>> >>>>>>>> On 9/3/20 2:44 AM, Mark Thomas wrote:
>> >>>>>>>>> On 31/08/2020 01:05, Phil Steitz wrote:
>> >>>>>>>>>
>> >>>>>>>>> 
>> >>>>>>>>>
>> >>>>>>>>>> If others agree it is a good idea for dbcp, I can do it.  I can
>> >> see the
>> >>>>>>>>>> argument that its better to stay with close() even for
>> abandoned
>> >> and I
>> >>>>>>>>>> have not been able to get the deadlock to happen, so I would
>> like
>> >> to
>> >>>>>>>>>> wait a bit and allow others to weigh in.  Similarly for pool, I
>> >> would
>> >>>>>>>>>> like to get more

Re: [ANNOUNCE] Apache Commons DBCP 2.8.0

[sebb]

On Mon, 28 Sep 2020 at 16:41, Gary Gregory  wrote:
>
> On Fri, Sep 25, 2020 at 7:32 PM sebb  wrote:
>
> > On Fri, 25 Sep 2020 at 18:26, Gary Gregory  wrote:
> > >
> > > On Fri, Sep 25, 2020 at 12:52 PM sebb  wrote:
> > >
> > > > I think I have fixed the hash links.
> > > >
> > > > The download_dbcp.xml file did not agree with the POM.
> > > > There must have been an error in the release generation process which
> > > > should be looked at.
> > > >
> > >
> > > The plugin that generates that file is either misconfigured for not
> > > flexible enough.
> >
> > I used 'mvn commons-build:download-page' and it worked fine.
> >
> > What did you use?
> >
>
> I used:
>
> mvn commons-build:all
> mvn changes:announcement-generate -Prelease-notes

Looks like there is a bug in commons-build:all.
It does not generate the same output as commons-build:download-page.

> Gary
>
>
> >
> > > The simplest solution would be to manually generate sha512 hashes for all
> > > the old files since md5 and sha1 are frowned upon anyway these days.
> >
> > The existing hashes are sha256 - no point replacing these with sha512.
> >
> > > Gary
> > >
> > >
> > > >
> > > > On Fri, 25 Sep 2020 at 17:02, sebb  wrote:
> > > > >
> > > > > There's an issue with https://commons.apache.org/dbcp/, at least
> > when
> > > > > viewed from the UK - it has not been updated to 2.8.0.
> > > > > I've reported this as INFRA-20898
> > > > >
> > > > > There's also an issue with the new page, e.g.
> > > > >
> > > > > http://commons.us.apache.org/proper/commons-dbcp/download_dbcp.cgi
> > > > >
> > > > > The hash links for 2.4.0 and earlier are all broken.
> > > > >
> > > > > On Fri, 25 Sep 2020 at 15:34, Gary Gregory 
> > wrote:
> > > > > >
> > > > > > The Apache Commons DBCP team is pleased to announce the release of
> > > > Apache
> > > > > > Apache Commons DBCP 2.8.0.
> > > > > >
> > > > > > Apache Commons DBCP software implements Database Connection
> > Pooling.
> > > > > >
> > > > > > This is a minor release, including bug fixes and enhancements.
> > > > > >
> > > > > > Changes in this version include:
> > > > > >
> > > > > > New features:
> > > > > > o DBCP-564:  Fix BasicManagedDataSource leak of connections opened
> > > > after
> > > > > > transaction is rollback-only #39. Thanks to Florent Guillaume.
> > > > > > o DBCP-566:  Add clearStatementPoolOnReturn #42. Thanks to Robert
> > > > Paschek,
> > > > > > Gary Gregory, Phil Steitz.
> > > > > > o DBCP-559:  Add start, restart methods to BasicDataSource. #50.
> > > > Thanks to
> > > > > > Phil Steitz.
> > > > > >
> > > > > > Fixed Bugs:
> > > > > > o DBCP-555:  NPE when creating a SQLExceptionList with a null list.
> > > > Thanks
> > > > > > to Gary Gregory.
> > > > > > o DBCP-558:  Fix DelegatingConnection readOnly and autoCommit
> > caching
> > > > > > mechanism #35. Thanks to louislatreille.
> > > > > > oFix regression introduced by unreleased code clean-up
> > #63.
> > > > > > Thanks to Sebastian Haas.
> > > > > >
> > > > > > Changes:
> > > > > > oUpdate to PR#36 - PrepareStatement and prepareCall
> > > > methods are
> > > > > > extracted #37. Thanks to DoiMasayuki, Alexander Norz, Gary Gregory.
> > > > > > oMask out user name and password from
> > > > > > DriverAdapterCPDS.toString(). Thanks to Gary Gregory.
> > > > > > o DBCP-650:  Update Apache Commons Pool from 2.7.0 to 2.8.1, #48.
> > > > Thanks to
> > > > > > Gary Gregory, Dependabot.
> > > > > > oUpdate tests from H2 1.4.199 to 1.4.200. Thanks to
> > Gary
> > > > > > Gregory.
> > > > > > oUpdate tests from Mockito 3.0.0 to 3.5.11 #47, #60,
> > #64.
> > > > > > Thanks to Gary Gregory, Dependabot.
> > > > > > o   

Re: [ANNOUNCE] Apache Commons DBCP 2.8.0

[Gary Gregory]

On Fri, Sep 25, 2020 at 7:32 PM sebb  wrote:

> On Fri, 25 Sep 2020 at 18:26, Gary Gregory  wrote:
> >
> > On Fri, Sep 25, 2020 at 12:52 PM sebb  wrote:
> >
> > > I think I have fixed the hash links.
> > >
> > > The download_dbcp.xml file did not agree with the POM.
> > > There must have been an error in the release generation process which
> > > should be looked at.
> > >
> >
> > The plugin that generates that file is either misconfigured for not
> > flexible enough.
>
> I used 'mvn commons-build:download-page' and it worked fine.
>
> What did you use?
>

I used:

mvn commons-build:all
mvn changes:announcement-generate -Prelease-notes

Gary


>
> > The simplest solution would be to manually generate sha512 hashes for all
> > the old files since md5 and sha1 are frowned upon anyway these days.
>
> The existing hashes are sha256 - no point replacing these with sha512.
>
> > Gary
> >
> >
> > >
> > > On Fri, 25 Sep 2020 at 17:02, sebb  wrote:
> > > >
> > > > There's an issue with https://commons.apache.org/dbcp/, at least
> when
> > > > viewed from the UK - it has not been updated to 2.8.0.
> > > > I've reported this as INFRA-20898
> > > >
> > > > There's also an issue with the new page, e.g.
> > > >
> > > > http://commons.us.apache.org/proper/commons-dbcp/download_dbcp.cgi
> > > >
> > > > The hash links for 2.4.0 and earlier are all broken.
> > > >
> > > > On Fri, 25 Sep 2020 at 15:34, Gary Gregory 
> wrote:
> > > > >
> > > > > The Apache Commons DBCP team is pleased to announce the release of
> > > Apache
> > > > > Apache Commons DBCP 2.8.0.
> > > > >
> > > > > Apache Commons DBCP software implements Database Connection
> Pooling.
> > > > >
> > > > > This is a minor release, including bug fixes and enhancements.
> > > > >
> > > > > Changes in this version include:
> > > > >
> > > > > New features:
> > > > > o DBCP-564:  Fix BasicManagedDataSource leak of connections opened
> > > after
> > > > > transaction is rollback-only #39. Thanks to Florent Guillaume.
> > > > > o DBCP-566:  Add clearStatementPoolOnReturn #42. Thanks to Robert
> > > Paschek,
> > > > > Gary Gregory, Phil Steitz.
> > > > > o DBCP-559:  Add start, restart methods to BasicDataSource. #50.
> > > Thanks to
> > > > > Phil Steitz.
> > > > >
> > > > > Fixed Bugs:
> > > > > o DBCP-555:  NPE when creating a SQLExceptionList with a null list.
> > > Thanks
> > > > > to Gary Gregory.
> > > > > o DBCP-558:  Fix DelegatingConnection readOnly and autoCommit
> caching
> > > > > mechanism #35. Thanks to louislatreille.
> > > > > oFix regression introduced by unreleased code clean-up
> #63.
> > > > > Thanks to Sebastian Haas.
> > > > >
> > > > > Changes:
> > > > > oUpdate to PR#36 - PrepareStatement and prepareCall
> > > methods are
> > > > > extracted #37. Thanks to DoiMasayuki, Alexander Norz, Gary Gregory.
> > > > > oMask out user name and password from
> > > > > DriverAdapterCPDS.toString(). Thanks to Gary Gregory.
> > > > > o DBCP-650:  Update Apache Commons Pool from 2.7.0 to 2.8.1, #48.
> > > Thanks to
> > > > > Gary Gregory, Dependabot.
> > > > > oUpdate tests from H2 1.4.199 to 1.4.200. Thanks to
> Gary
> > > > > Gregory.
> > > > > oUpdate tests from Mockito 3.0.0 to 3.5.11 #47, #60,
> #64.
> > > > > Thanks to Gary Gregory, Dependabot.
> > > > > oUpdate tests from jboss-logging 3.4.0.Final to
> > > 3.4.1.Final.
> > > > > Thanks to Gary Gregory.
> > > > > oUpdate tests from narayana-jta 5.9.5.Final to
> > > 5.10.6.Final,
> > > > > #61. Thanks to Gary Gregory.
> > > > > oUpdate tests from junit-jupiter 5.5.1 to 5.7.0 #62.
> > > Thanks to
> > > > > Gary Gregory.
> > > > > oUpdate tests from org.slf4j:slf4j-simple 1.7.26 to
> 1.7.30.
> > > > > Thanks to Gary Gregory.
> > > > > oUpdate build from
> > > > > com.github.siom7