git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pool] how to move to Java8?


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 <garydgregory@xxxxxxxxx> 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 <struberg@xxxxxxxx.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 <garydgregory@xxxxxxxxx>:
> > >
> > > 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
> <struberg@xxxxxxxx.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 <markt@xxxxxxxxxx>:
> > >>>
> > >>> 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-unsubscribe@xxxxxxxxxxxxxxxxxx
> > >>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> > >> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx
> >
> >
>


-- 
Matt Sicker <boards@xxxxxxxxx>