Re: [pool] Resilience against factory outages (POOL-407)
No need to apologize We all have complex system to deal with all over the place. Gary On Fri, May 31, 2024, 5:55 PM Phil Steitz wrote: > Thx and sorry. > > Phil > > On Fri, May 31, 2024 at 1:45 PM Gary D. Gregory > wrote: > > > Hello Phil, > > > > Before you push, run 'mvn' (buy itself), this runs the default goal, > which > > contains all build checks. > > > > If see the code coverage report, regardless of coverage failures, run: > > > > mvn clean site -Dcommons.jacoco.haltOnFailure=false > > > > I'll update the readme... > > > > TY, > > Gary > > > > On 2024/05/31 20:12:09 Phil Steitz wrote: > > > The build worked locally for me fine. I could not get the site to > build. > > > Is there some sequence that I need to use to get the site to build? I > > did > > > run Checksytle and Findbugs separately. What is the test coverage > plugin > > > and how do I run that? > > > > > > Phil > > > > > > On Fri, May 31, 2024 at 11:53 AM Gary Gregory > > > wrote: > > > > > > > Hi Phil, > > > > > > > > Thank you for the note. I'll try to take a look soon. > > > > > > > > The new code causes the build to fail as it looks like not all of it > is > > > > covered by unit tests. > > > > > > > > Gary > > > > > > > > > > > > On Fri, May 31, 2024, 2:29 PM Phil Steitz > > wrote: > > > > > > > > > I just committed a first attempt at providing the above, intended > > as a > > > > fix > > > > > for POOL-407 and a lot of similar issues reported over the years. > > The > > > > > scenario in POOL-407 is common when resource providers (like > > databases) > > > > go > > > > > down: > > > > > > > > > > 1. makeObject requests start to fail and threads line up waiting on > > the > > > > > deque. > > > > > 2. The provider comes back up so makes will succeed again, but the > > > > clients, > > > > > the pool and the factory are all ignorant of this fact, so no > > clients get > > > > > served. > > > > > > > > > > What I just committed puts the resilience responsibility on the > > factory, > > > > > having it monitor itself. That responsibility could arguably be > put > > > > > instead on the pool. > > > > > > > > > > To use the feature as is, you need to create a > > > > ResilientPooledObjectFactory > > > > > wrapping a PooledObjectFactory, configure it, attach it to its pool > > and > > > > > start its monitor. The formerly disabled GOP test, > > > > > testLivenessOnTransientFactoryFailure, shows how to do it. The > > setup is > > > > a > > > > > little awkward. I would appreciate feedback on the following > > options for > > > > > how to improve it (or any other comments on the code): > > > > > > > > > > 0) Roll it back and come up with something better > > > > > 1) Leave as is > > > > > 2) add a GOP config that results in its factory being wrapped > > > > automatically > > > > > in a RPOF. > > > > > 3) move the functionality into the pool > > > > > > > > > > The other thing that needs to be designed is how to make the > > proactive > > > > make > > > > > attempt strategy configurable. It is hard-coded now in the RPOF > > > > runChecks > > > > > and the Adder inner class. The initial implementation is > primitive: > > > > > Monitor the makeObject log. Any failure triggers start of an Adder > > that > > > > > tries addObject with configurable delay and (hard-coded) max > > failures. > > > > > Once the circular log becomes filled with successes, turn the adder > > off. > > > > > > > > > > Also, RPOF spawns a monitoring thread and, when it detects a > > transient > > > > > failure, an adder thread. Careful review - and improvement - of > the > > > > > management of these threads would be appreciated. I tried to make > > sure, > > > > > and added tests to confirm, that closing the pool kills these > > threads. > > > > > > > > > > Phil > > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
Re: [pool] Resilience against factory outages (POOL-407)
Thx and sorry. Phil On Fri, May 31, 2024 at 1:45 PM Gary D. Gregory wrote: > Hello Phil, > > Before you push, run 'mvn' (buy itself), this runs the default goal, which > contains all build checks. > > If see the code coverage report, regardless of coverage failures, run: > > mvn clean site -Dcommons.jacoco.haltOnFailure=false > > I'll update the readme... > > TY, > Gary > > On 2024/05/31 20:12:09 Phil Steitz wrote: > > The build worked locally for me fine. I could not get the site to build. > > Is there some sequence that I need to use to get the site to build? I > did > > run Checksytle and Findbugs separately. What is the test coverage plugin > > and how do I run that? > > > > Phil > > > > On Fri, May 31, 2024 at 11:53 AM Gary Gregory > > wrote: > > > > > Hi Phil, > > > > > > Thank you for the note. I'll try to take a look soon. > > > > > > The new code causes the build to fail as it looks like not all of it is > > > covered by unit tests. > > > > > > Gary > > > > > > > > > On Fri, May 31, 2024, 2:29 PM Phil Steitz > wrote: > > > > > > > I just committed a first attempt at providing the above, intended > as a > > > fix > > > > for POOL-407 and a lot of similar issues reported over the years. > The > > > > scenario in POOL-407 is common when resource providers (like > databases) > > > go > > > > down: > > > > > > > > 1. makeObject requests start to fail and threads line up waiting on > the > > > > deque. > > > > 2. The provider comes back up so makes will succeed again, but the > > > clients, > > > > the pool and the factory are all ignorant of this fact, so no > clients get > > > > served. > > > > > > > > What I just committed puts the resilience responsibility on the > factory, > > > > having it monitor itself. That responsibility could arguably be put > > > > instead on the pool. > > > > > > > > To use the feature as is, you need to create a > > > ResilientPooledObjectFactory > > > > wrapping a PooledObjectFactory, configure it, attach it to its pool > and > > > > start its monitor. The formerly disabled GOP test, > > > > testLivenessOnTransientFactoryFailure, shows how to do it. The > setup is > > > a > > > > little awkward. I would appreciate feedback on the following > options for > > > > how to improve it (or any other comments on the code): > > > > > > > > 0) Roll it back and come up with something better > > > > 1) Leave as is > > > > 2) add a GOP config that results in its factory being wrapped > > > automatically > > > > in a RPOF. > > > > 3) move the functionality into the pool > > > > > > > > The other thing that needs to be designed is how to make the > proactive > > > make > > > > attempt strategy configurable. It is hard-coded now in the RPOF > > > runChecks > > > > and the Adder inner class. The initial implementation is primitive: > > > > Monitor the makeObject log. Any failure triggers start of an Adder > that > > > > tries addObject with configurable delay and (hard-coded) max > failures. > > > > Once the circular log becomes filled with successes, turn the adder > off. > > > > > > > > Also, RPOF spawns a monitoring thread and, when it detects a > transient > > > > failure, an adder thread. Careful review - and improvement - of the > > > > management of these threads would be appreciated. I tried to make > sure, > > > > and added tests to confirm, that closing the pool kills these > threads. > > > > > > > > Phil > > > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [pool] Resilience against factory outages (POOL-407)
I updated the README's "Contributing" sections with: + Before you pushing a PR, run `mvn` (by itself), this runs the default goal, which contains all build checks. + To see the code coverage report, regardless of coverage failures, run `mvn clean site -Dcommons.jacoco.haltOnFailure=false` This change will eventually make it other README files. TY, Gary On 2024/05/31 20:44:51 "Gary D. Gregory" wrote: > Hello Phil, > > Before you push, run 'mvn' (buy itself), this runs the default goal, which > contains all build checks. > > If see the code coverage report, regardless of coverage failures, run: > > mvn clean site -Dcommons.jacoco.haltOnFailure=false > > I'll update the readme... > > TY, > Gary > > On 2024/05/31 20:12:09 Phil Steitz wrote: > > The build worked locally for me fine. I could not get the site to build. > > Is there some sequence that I need to use to get the site to build? I did > > run Checksytle and Findbugs separately. What is the test coverage plugin > > and how do I run that? > > > > Phil > > > > On Fri, May 31, 2024 at 11:53 AM Gary Gregory > > wrote: > > > > > Hi Phil, > > > > > > Thank you for the note. I'll try to take a look soon. > > > > > > The new code causes the build to fail as it looks like not all of it is > > > covered by unit tests. > > > > > > Gary > > > > > > > > > On Fri, May 31, 2024, 2:29 PM Phil Steitz wrote: > > > > > > > I just committed a first attempt at providing the above, intended as a > > > fix > > > > for POOL-407 and a lot of similar issues reported over the years. The > > > > scenario in POOL-407 is common when resource providers (like databases) > > > go > > > > down: > > > > > > > > 1. makeObject requests start to fail and threads line up waiting on the > > > > deque. > > > > 2. The provider comes back up so makes will succeed again, but the > > > clients, > > > > the pool and the factory are all ignorant of this fact, so no clients > > > > get > > > > served. > > > > > > > > What I just committed puts the resilience responsibility on the factory, > > > > having it monitor itself. That responsibility could arguably be put > > > > instead on the pool. > > > > > > > > To use the feature as is, you need to create a > > > ResilientPooledObjectFactory > > > > wrapping a PooledObjectFactory, configure it, attach it to its pool and > > > > start its monitor. The formerly disabled GOP test, > > > > testLivenessOnTransientFactoryFailure, shows how to do it. The setup is > > > a > > > > little awkward. I would appreciate feedback on the following options > > > > for > > > > how to improve it (or any other comments on the code): > > > > > > > > 0) Roll it back and come up with something better > > > > 1) Leave as is > > > > 2) add a GOP config that results in its factory being wrapped > > > automatically > > > > in a RPOF. > > > > 3) move the functionality into the pool > > > > > > > > The other thing that needs to be designed is how to make the proactive > > > make > > > > attempt strategy configurable. It is hard-coded now in the RPOF > > > runChecks > > > > and the Adder inner class. The initial implementation is primitive: > > > > Monitor the makeObject log. Any failure triggers start of an Adder that > > > > tries addObject with configurable delay and (hard-coded) max failures. > > > > Once the circular log becomes filled with successes, turn the adder off. > > > > > > > > Also, RPOF spawns a monitoring thread and, when it detects a transient > > > > failure, an adder thread. Careful review - and improvement - of the > > > > management of these threads would be appreciated. I tried to make sure, > > > > and added tests to confirm, that closing the pool kills these threads. > > > > > > > > Phil > > > > > > > > > > > - > 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: [pool] Resilience against factory outages (POOL-407)
Hello Phil, Before you push, run 'mvn' (buy itself), this runs the default goal, which contains all build checks. If see the code coverage report, regardless of coverage failures, run: mvn clean site -Dcommons.jacoco.haltOnFailure=false I'll update the readme... TY, Gary On 2024/05/31 20:12:09 Phil Steitz wrote: > The build worked locally for me fine. I could not get the site to build. > Is there some sequence that I need to use to get the site to build? I did > run Checksytle and Findbugs separately. What is the test coverage plugin > and how do I run that? > > Phil > > On Fri, May 31, 2024 at 11:53 AM Gary Gregory > wrote: > > > Hi Phil, > > > > Thank you for the note. I'll try to take a look soon. > > > > The new code causes the build to fail as it looks like not all of it is > > covered by unit tests. > > > > Gary > > > > > > On Fri, May 31, 2024, 2:29 PM Phil Steitz wrote: > > > > > I just committed a first attempt at providing the above, intended as a > > fix > > > for POOL-407 and a lot of similar issues reported over the years. The > > > scenario in POOL-407 is common when resource providers (like databases) > > go > > > down: > > > > > > 1. makeObject requests start to fail and threads line up waiting on the > > > deque. > > > 2. The provider comes back up so makes will succeed again, but the > > clients, > > > the pool and the factory are all ignorant of this fact, so no clients get > > > served. > > > > > > What I just committed puts the resilience responsibility on the factory, > > > having it monitor itself. That responsibility could arguably be put > > > instead on the pool. > > > > > > To use the feature as is, you need to create a > > ResilientPooledObjectFactory > > > wrapping a PooledObjectFactory, configure it, attach it to its pool and > > > start its monitor. The formerly disabled GOP test, > > > testLivenessOnTransientFactoryFailure, shows how to do it. The setup is > > a > > > little awkward. I would appreciate feedback on the following options for > > > how to improve it (or any other comments on the code): > > > > > > 0) Roll it back and come up with something better > > > 1) Leave as is > > > 2) add a GOP config that results in its factory being wrapped > > automatically > > > in a RPOF. > > > 3) move the functionality into the pool > > > > > > The other thing that needs to be designed is how to make the proactive > > make > > > attempt strategy configurable. It is hard-coded now in the RPOF > > runChecks > > > and the Adder inner class. The initial implementation is primitive: > > > Monitor the makeObject log. Any failure triggers start of an Adder that > > > tries addObject with configurable delay and (hard-coded) max failures. > > > Once the circular log becomes filled with successes, turn the adder off. > > > > > > Also, RPOF spawns a monitoring thread and, when it detects a transient > > > failure, an adder thread. Careful review - and improvement - of the > > > management of these threads would be appreciated. I tried to make sure, > > > and added tests to confirm, that closing the pool kills these threads. > > > > > > Phil > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] Resilience against factory outages (POOL-407)
The build worked locally for me fine. I could not get the site to build. Is there some sequence that I need to use to get the site to build? I did run Checksytle and Findbugs separately. What is the test coverage plugin and how do I run that? Phil On Fri, May 31, 2024 at 11:53 AM Gary Gregory wrote: > Hi Phil, > > Thank you for the note. I'll try to take a look soon. > > The new code causes the build to fail as it looks like not all of it is > covered by unit tests. > > Gary > > > On Fri, May 31, 2024, 2:29 PM Phil Steitz wrote: > > > I just committed a first attempt at providing the above, intended as a > fix > > for POOL-407 and a lot of similar issues reported over the years. The > > scenario in POOL-407 is common when resource providers (like databases) > go > > down: > > > > 1. makeObject requests start to fail and threads line up waiting on the > > deque. > > 2. The provider comes back up so makes will succeed again, but the > clients, > > the pool and the factory are all ignorant of this fact, so no clients get > > served. > > > > What I just committed puts the resilience responsibility on the factory, > > having it monitor itself. That responsibility could arguably be put > > instead on the pool. > > > > To use the feature as is, you need to create a > ResilientPooledObjectFactory > > wrapping a PooledObjectFactory, configure it, attach it to its pool and > > start its monitor. The formerly disabled GOP test, > > testLivenessOnTransientFactoryFailure, shows how to do it. The setup is > a > > little awkward. I would appreciate feedback on the following options for > > how to improve it (or any other comments on the code): > > > > 0) Roll it back and come up with something better > > 1) Leave as is > > 2) add a GOP config that results in its factory being wrapped > automatically > > in a RPOF. > > 3) move the functionality into the pool > > > > The other thing that needs to be designed is how to make the proactive > make > > attempt strategy configurable. It is hard-coded now in the RPOF > runChecks > > and the Adder inner class. The initial implementation is primitive: > > Monitor the makeObject log. Any failure triggers start of an Adder that > > tries addObject with configurable delay and (hard-coded) max failures. > > Once the circular log becomes filled with successes, turn the adder off. > > > > Also, RPOF spawns a monitoring thread and, when it detects a transient > > failure, an adder thread. Careful review - and improvement - of the > > management of these threads would be appreciated. I tried to make sure, > > and added tests to confirm, that closing the pool kills these threads. > > > > Phil > > >
Re: [pool] Resilience against factory outages (POOL-407)
Hi Phil, Thank you for the note. I'll try to take a look soon. The new code causes the build to fail as it looks like not all of it is covered by unit tests. Gary On Fri, May 31, 2024, 2:29 PM Phil Steitz wrote: > I just committed a first attempt at providing the above, intended as a fix > for POOL-407 and a lot of similar issues reported over the years. The > scenario in POOL-407 is common when resource providers (like databases) go > down: > > 1. makeObject requests start to fail and threads line up waiting on the > deque. > 2. The provider comes back up so makes will succeed again, but the clients, > the pool and the factory are all ignorant of this fact, so no clients get > served. > > What I just committed puts the resilience responsibility on the factory, > having it monitor itself. That responsibility could arguably be put > instead on the pool. > > To use the feature as is, you need to create a ResilientPooledObjectFactory > wrapping a PooledObjectFactory, configure it, attach it to its pool and > start its monitor. The formerly disabled GOP test, > testLivenessOnTransientFactoryFailure, shows how to do it. The setup is a > little awkward. I would appreciate feedback on the following options for > how to improve it (or any other comments on the code): > > 0) Roll it back and come up with something better > 1) Leave as is > 2) add a GOP config that results in its factory being wrapped automatically > in a RPOF. > 3) move the functionality into the pool > > The other thing that needs to be designed is how to make the proactive make > attempt strategy configurable. It is hard-coded now in the RPOF runChecks > and the Adder inner class. The initial implementation is primitive: > Monitor the makeObject log. Any failure triggers start of an Adder that > tries addObject with configurable delay and (hard-coded) max failures. > Once the circular log becomes filled with successes, turn the adder off. > > Also, RPOF spawns a monitoring thread and, when it detects a transient > failure, an adder thread. Careful review - and improvement - of the > management of these threads would be appreciated. I tried to make sure, > and added tests to confirm, that closing the pool kills these threads. > > Phil >
[pool] Resilience against factory outages (POOL-407)
I just committed a first attempt at providing the above, intended as a fix for POOL-407 and a lot of similar issues reported over the years. The scenario in POOL-407 is common when resource providers (like databases) go down: 1. makeObject requests start to fail and threads line up waiting on the deque. 2. The provider comes back up so makes will succeed again, but the clients, the pool and the factory are all ignorant of this fact, so no clients get served. What I just committed puts the resilience responsibility on the factory, having it monitor itself. That responsibility could arguably be put instead on the pool. To use the feature as is, you need to create a ResilientPooledObjectFactory wrapping a PooledObjectFactory, configure it, attach it to its pool and start its monitor. The formerly disabled GOP test, testLivenessOnTransientFactoryFailure, shows how to do it. The setup is a little awkward. I would appreciate feedback on the following options for how to improve it (or any other comments on the code): 0) Roll it back and come up with something better 1) Leave as is 2) add a GOP config that results in its factory being wrapped automatically in a RPOF. 3) move the functionality into the pool The other thing that needs to be designed is how to make the proactive make attempt strategy configurable. It is hard-coded now in the RPOF runChecks and the Adder inner class. The initial implementation is primitive: Monitor the makeObject log. Any failure triggers start of an Adder that tries addObject with configurable delay and (hard-coded) max failures. Once the circular log becomes filled with successes, turn the adder off. Also, RPOF spawns a monitoring thread and, when it detects a transient failure, an adder thread. Careful review - and improvement - of the management of these threads would be appreciated. I tried to make sure, and added tests to confirm, that closing the pool kills these threads. Phil
[ANNOUNCE] Apache Commons Net 3.11.0
The Apache Commons Net team is pleased to announce the release of Apache Commons Net 3.11.0. Apache Commons Net library contains a collection of network utilities and protocol implementations. Supported protocols include Echo, Finger, FTP, NNTP, NTP, POP3(S), SMTP(S), Telnet, and Whois. Maintenance and bug fix release (Java 8 or above). For complete information on Apache Commons Net, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons Net website: https://commons.apache.org/proper/commons-net/ Download page: https://commons.apache.org/proper/commons-net/download_net.cgi Historical list of changes: https://commons.apache.org/proper/commons-net/changes-report.html Enjoy! Gary Gregory -Apache Commons Net team - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[RESULT][VOTE] Release Apache Commons Net 3.11.0 based on RC1
This vote thread passes with the following binding +1 votes: - Henri Biestro (henrib) - Gary Gregory (ggregory) - Rob Tompkins (chtompki) Gary On Thu, May 30, 2024 at 8:28 AM Rob Tompkins wrote: > > +1 > > > On May 28, 2024, at 8:09 PM, Gary Gregory wrote: > > > > We have fixed a few bugs and added enhancements since Apache Commons > > Net 3.10.0 was released, so I would like to release Apache Commons Net > > 3.11.0. > > > > Apache Commons Net 3.11.0 RC1 is available for review here: > >https://dist.apache.org/repos/dist/dev/commons/net/3.11.0-RC1 (svn > > revision 69435) > > > > The Git tag commons-net-3.11.0-RC1 commit for this RC is > > 5f22becd00743b809b81bfff21ec25ed39f2a7e6 which you can browse here: > > > > https://gitbox.apache.org/repos/asf?p=commons-net.git;a=commit;h=5f22becd00743b809b81bfff21ec25ed39f2a7e6 > > You may checkout this tag using: > >git clone https://gitbox.apache.org/repos/asf/commons-net.git > > --branch commons-net-3.11.0-RC1 commons-net-3.11.0-RC1 > > > > Maven artifacts are here: > > > > https://repository.apache.org/content/repositories/orgapachecommons-1736/commons-net/commons-net/3.11.0/ > > > > These are the artifacts and their hashes: > > > > #Release SHA-512s > > #Wed May 29 00:00:06 UTC 2024 > > commons-net-3.11.0-bin.tar.gz=ba477cf8faf25fa84c993b44ee083be912435edb669e7a84e1c49502a77aa1743c7c7391eaa61fdecd6453027553d79f88d197a444dfa8555dbc745be7227964 > > commons-net-3.11.0-bin.zip=c7e52cde61664764e94dbe0b900369765a6c40f704ef55f2928fa011b3ed51419658d15b918d955ae1e6d183110cf7bc2199afc1106f9d104c6a6fc0c76d5ff4 > > commons-net-3.11.0-bom.json=d32a8ccd605556d03a6a4437617a654288aac41d3de3d74223dca056b1abcdabbc667562c4c6296b6c9e0166c0891511fcedc124feac7798b107cb2bbcdfd32c > > commons-net-3.11.0-bom.xml=b4b69706b359f81d1b4649556384efdc165536542c9cca13e507257f17c89075a710f4a369276aec083a32b4b1c127adf74c8831686976ba90d3c1db34bb > > commons-net-3.11.0-javadoc.jar=63665b405e763c96d18a5b34f7e770c1d046a03ac140c61040ac4ca452948f4b596dc080426a6003ae67dbfdebed8617f444e87759d042b93536b8474f008dc8 > > commons-net-3.11.0-sources.jar=3a7f8ffab99d643c4c14300c10c433e03ab8a78d1ebdc8271319122dd5c23a289b14a33bfff5f648a4e98422b96c159a72cf3dd1e4f118813a28270b5eb398a9 > > commons-net-3.11.0-src.tar.gz=6638bcd668110b189e4c3e74b0964165dc577d7c5209fbbcef21ddbb6d83a96ebb904863a2516fd971b45cec859600fa0806f22cfaa1fa4eb7bf780743939ccc > > commons-net-3.11.0-src.zip=6e844164cdcd2975bf23bec41e9c13ef11263fa75dbca647c7f29d17e4fe2000dd4e06ce1e502c9e97804681ac9885eeb37a644004b04eec2bc38c94a489fca7 > > commons-net-3.11.0-test-sources.jar=3ae6b5a94112430f7c2bc2074936abe04939a7e2332a06f7727d459b608f832dfb74d868f6444b0d8a9a990f20eeb70926570770f380134cfea9e14ac8597f41 > > commons-net-3.11.0-tests.jar=f8d0d4d7fb1db5fc19446246cba3b60370bfea9a986c20197366eed270993063c5f795355f69f91c7157dcb92bd4e0ae7983d7fb30623ebffcec29f1abbd6ce2 > > commons-net-examples-3.11.0.jar=df8a2d4ed8c04a22d6ea971de6e7e487eb2c7a06b4995649ce425d3ec911765626e3ad9e9588c72979bfc8748bd106c64909e3e04aecdb4048e9925328980eb5 > > commons-net-ftp-3.11.0.jar=fe90773486c2159f24a08076289fa59f39b4b3e6e5a7b5c317cccf993b0509b2a3884df1bc66dba4c9882ec0db0d1c9d0e1fd6c18d15200b2a04b7ad2d70658c > > commons-net_commons-net-3.11.0.spdx.json=6830dc7df688138eae0e5c73e74500131c92a43d91a4dd01edf7b22aa868f8ee092a9ebe392d1213386467ff8d710cf0b9ecc506cfd317499fa07a0116b33f9c > > > > I have tested this with 'mvn' and 'mvn -V -Prelease -Ptest-deploy -P > > jacoco -P japicmp clean package site deploy' using: > > > > openjdk version "17.0.11" 2024-04-16 > > OpenJDK Runtime Environment Homebrew (build 17.0.11+0) > > OpenJDK 64-Bit Server VM Homebrew (build 17.0.11+0, mixed mode, sharing) > > > > Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0) > > Maven home: /usr/local/Cellar/maven/3.9.7/libexec > > Java version: 17.0.11, vendor: Homebrew, runtime: > > /usr/local/Cellar/openjdk@17/17.0.11/libexec/openjdk.jdk/Contents/Home > > Default locale: en_US, platform encoding: UTF-8 > > OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac" > > > > Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:09:52 > > PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64 > > > > Details of changes since 3.10.0 are in the release notes: > > > > https://dist.apache.org/repos/dist/dev/commons/net/3.11.0-RC1/RELEASE-NOTES.txt > > > > https://dist.apache.org/repos/dist/dev/commons/net/3.11.0-RC1/site/changes-report.html > > > > Site: > > > > https://dist.apache.org/repos/dist/dev/commons/net/3.11.0-RC1/site/index.html > >(note some *relative* links are broken and the 3.11.0 directories > > are not yet created - these will be OK once the site is deployed.) > > > > JApiCmp Report (compared to 3.10.0): > > > > https://dist.apache.org/repos/dist/dev/commons/net/3.11.0-RC1/site/japicmp.html > > > > RAT Report: > > > > https://dist.apache.org/repos/dist/dev/commons/net/3.11.0-RC1/site/rat-report.html > > > > KEYS: > >
Re: Re: [LANG] Support single quotes in DurationFormatUtils methods' formats
Honestly I think not supporting empty literals is just as big a limitation as not supporting single quotes, so IMO we'd just be trading one limitation for another. i.e. if someone were to need empty literals, the things they would have to do to use them are the same things they'd have to do to support single quotes, and I can imagine use cases for both. On Thu, May 30, 2024 at 2:48 PM Gary D. Gregory wrote: > I'm OK with Sebb's solution [1] > > Any further thoughts here? > > Gary > [1] https://github.com/apache/commons-lang/pull/1227 > > On 2024/05/29 13:37:40 Mike Drob wrote: > > On Wed, May 29, 2024 at 8:17 AM Gary Gregory > wrote: > > > > > (Sorry for the top post, phone) > > > > > > A case I can imagine an empty '' occurring is when the format string > itself > > > is built programmatically for example a '%s' or using string > concatenate of > > > a variable that holds a string where that string can be empty or an > "s" to > > > mark a plural or a quote for example. > > > > > > "He said '" + bla + "' to me and I waited mm minutes!" > > > > > > Far fetched? Sure > > > > > > Gary > > > > > > On Wed, May 29, 2024, 8:43 AM sebb wrote: > > > > > > > On Sun, 26 May 2024 at 23:37, sebb wrote: > > > > > > > > > > On Sun, 26 May 2024 at 08:25, Laertes Moustakas < > lmous...@gmail.com> > > > > wrote: > > > > > > > > > > > > Hello Gary, > > > > > > > > > > > > Thank you for your response. Some of the new assertions indeed > fail > > > > when interpreting the duplicate single quote as an escaped quote > instead > > > of > > > > a closing and opening quote. In particular, "y' ''years' M 'months'" > is > > > > interpreted as "4 'years 0 months" while the expected text lacks the > > > quote > > > > before "years". Same for "hello''world": it's interpreted as > > > "hello'world" > > > > instead of "helloworld". > > > > > > > > > > Please see https://github.com/apache/commons-lang/pull/1227 for an > > > > > alternate solution. > > > > > This does not cause issues with any existing tests. > > > > > > > > > > However, it does change the behaviour of a duplicate single quote > > > > > which is found outside an existing opening and closing quote. > > > > > Instead of the empty string, it generates a lone single quote. > > > > > > > > > > Whilst this is a change in behaviour, it seems to me that there > should > > > > > be no need for anyone to use a format that uses a pair of adjacent > > > > > single quotes to generate an empty string in the output, so it > seems > > > > > unlikely that this will cause any breakages. > > > > > > > > I've since realised that this argument could also apply to the > > > > existing test cases: is there really a use-case for adjacent constant > > > > strings? > > > > Why would anyone want to split a constant string in this way? > > > > > > This is similar to allowable string concatenation in Python, which static > > analysis flags as a warning and probable bug. > > > https://pylint.pycqa.org/en/latest/user_guide/messages/warning/implicit-str-concat.html > > > > > > > > AFAICT it just makes it harder to read the string. > > > > > > > > i.e. do the test cases represent a real-world use case? > > > > > > > > > > I understand this brings forth a breaking change in formats that > use > > > > two single quotes to close and open new literals (or even add an > empty > > > > string), but this is consistent with what java.text.SimpleDateFormat > > > > expects. And I believe that most developers would favor consistency > > > between > > > > format strings in equivalent classes. Thus, I think the cases > described > > > > above where the two single quotes terminate and begin a literal > should no > > > > longer be supported. > > > > > > > > I agree. > > > > > > > > My alternate solution avoids breaking the test cases, but the > downside > > > > is that the syntax is not in agreement with > > > > java.text.SimpleDateFormat, and is more verbose where a single-quote > > > > is to be inserted in an existing constant string (it requires 4 > single > > > > quotes, rather than 2). > > > > > > > > > > > > > > > > Should this change go forward, I expect it to be part of a major > > > > release (e.g. version 4.0.0, 5.0.0, etc.) instead of 3.x.x, as it > does > > > > contain a breaking change. > > > > > > > > > > > > If you have more questions, please don't hesitate to contact me. > > > > > > > > > > > > Best regards, > > > > > > Laertes > > > > > > > > > > > > On 2024/05/25 13:47:23 Gary Gregory wrote: > > > > > > > Hello Laertes, > > > > > > > > > > > > > > Thank you for your interest in improving Apache Commons Lang > :-) > > > > > > > > > > > > > > Do you foresee any compatibility issues for existing call > sites and > > > > > > > format strings? > > > > > > > > > > > > > > For example, can you make your use cases work and still > support: > > > > > > > > > > > > > > > > > > > > > >
