changes.xml is hand crafted and used to generate parts of the site. Gary
On Mon, Oct 29, 2018 at 9:26 AM Mark Struberg <strub...@yahoo.de.invalid> wrote: > 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 > >
