I'm fine with sticking with Java 7 for Tomcat as long as the Jenkins build continues to work properly. Keep an eye on the JDKs available! ;)
On Mon, 29 Oct 2018 at 10:28, Gary Gregory <garydgreg...@gmail.com> wrote: > 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 > > > > > -- Matt Sicker <boa...@gmail.com>
