Yes, was not sure whether the changes.xml is generated or hand crafted. Gonna add the missing bits.
LieGrue, strub > Am 29.10.2018 um 16:17 schrieb Gary Gregory <garydgreg...@gmail.com>: > > My view is to skip POOL-355 and release the current code still, on Java > 7, as 2.6.1, or 2.7.0 if a new feature has been added, which is not clear > since it seems changes.xml has not been updated for the commits over the > last week or two. > > Gary > > On Mon, Oct 29, 2018 at 6:49 AM Mark Struberg <strub...@yahoo.de.invalid> > wrote: > >> I've went through the list and pretty much the only ticket which was left >> to really benefit from it would be the getMaxNumActive() (POOL-355). >> But as noted there: after a bit of thinking through it I'm even tempted to >> close it as won't fix. Having just a bare maxNumActive doesn't give you >> much info in real production. >> What you need is really a time graph with the currently active >> connections. You usually don't care about just a short spike e.g. because >> the underlying db gets restarted. What you care about is whether the >> connections are fine NOW and at which timeframe they have been in a bad >> shape. >> >> If you (and others) could also take a look on this ticket them we could go >> on and close it. Which whould then remove the need for Java8. >> >> That means I'm perfectly fine with keeping it java7 for now. Plus we also >> know what to take care of if we really need to bump to j8. >> >> LieGrue, >> strub >> >> >>> Am 29.10.2018 um 09:35 schrieb Mark Thomas <ma...@apache.org>: >>> >>> On 28/10/18 11:09, Mark Struberg wrote: >>>> Hi folks! >>>> I've worked through the open POOL tickets and found a few tickets which >> would like to enhance a few of our interfaces. >>>> E.g. in POOL-355 we have a request to add a new method >> getMaxNumActive() to the ObjectPool interface. >>>> Now this would of course be a backward compatibility breaking change. >> If we would have java8 as minimum then we could easily just add a default >> method which returns -1. But since our min Java version is 1.7 we are >> doomed... >>>> I would love to get the deadlock fixes out with the current 1.7 >> requirement first. Because that's important to get to the people (including >> my own customers). >>>> But what after that?Would this justify a commons-pool-3.0?Do we also >> like to cleanup other stuff? Or should we just raise our min Java >> requirement to 1.8 and call it 2.7? >>>> I'm totally fine either way and would love to get any feedback. >>> >>> Tomcat 8 (with a spec required minimum Java version of Java 7) is >>> currently using the latest version of pool. This version of Tomcat is >>> unlikely to be EOL until well into the 2020s. It would be easier if pool >>> stayed on Java 7 (since we maintain a package renamed copy of the code) >>> but I appreciate that that is not practical for pool for that timescale. >>> >>> It isn't a huge amount of work to handle things like default methods. >>> The Tomcat community would certainly appreciate it if any Java 8 >>> specific changes in Pool kept in mind that Tomcat will need to back-port >>> them to Java 7. >>> >>> 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
