On 1/11/13 4:55 AM, Jörg Schaible wrote: > Hi Mark, > > Mark Thomas wrote: > >> On 11/01/2013 11:31, sebb wrote: >>> On 11 January 2013 02:38, Phil Steitz <p...@steitz.com> wrote: >>>> On 1/10/13 8:57 AM, ma...@apache.org wrote: >>>>> Author: markt >>>>> Date: Thu Jan 10 16:57:07 2013 >>>>> New Revision: 1431496 >>>>> >>>>> URL: http://svn.apache.org/viewvc?rev=1431496&view=rev >>>>> Log: >>>>> Update DBCP2 to require JDBC 4.1 (Java 7) since Java 6 is close to end >>>>> of life and a DBCP2 release is still a little way off. >>>> Probably should have talked about this on the list. Oh, I guess we >>>> are. In that case, here is my +1. >>> I don't understand the rationale for requiring JDBC 4.1 - does it >>> offer significant benefits over the previous version? >> Nothing significant that I have found so far. >> >>> Or is it that applications written to use the previous version of JDBC >>> won't even run on Java 7? >> They should run but DBCP won't compile on Java 7 unless the JDBC 4.1 >> methods are implemented (hence the gump nags we have been getting for a >> while). There is also the risk that an app written compiled against Java >> 7 tries to use one of the JDBC 4.1 methods. That would trigger a >> run-time exception. >> >>> I know that the JDBC API has been changed in ways that don't respect >>> upward compatibilty in the past - has that happened again? >> Yes. As it has with every new JDBC release that I can recall. >> >>> Although Java 6 is close to EOL, I suspect a lot of commercial sites >>> will remain on it long after EOL. >> There is the option (if someone wants to scratch this particular itch - >> I don't) to add similar filtering as there is in DBCP1 to support dual >> builds for JBDC4 and JDBC4.1. > Why not? DBCP did set the precedence with active 1.3.x and 1.4.x series. No > reason why we should not have now 1.5.x (JDBC 4.1) and 1.4.x (JDBC 4.0). > However, I'd skip the maintenance of 1.3.x then.
Patches welcome! I think this would be a good feature to have; but someone has to actually do the work. I would look carefully at the question though of whether or not we have to actually split the series. IIRC, we were forced into in the 1.3/1.4 split by really incompatible JDBC changes. Just added methods we were able to accommodate before with filters. In any case, if we ended up splitting here it would be 2.0.x / 2.1.x. Phil > >> My primary driver is that I want to get a decent concurrent connection >> pool based on DBCP into Tomcat 8. Tomcat 8 implements Servlet 3.1 which >> requires Java 7 so I need DBCP2 to build against Java 7 and I'd rather >> not continue the current hack in the Tomcat build of patching the source >> to add the methods. > Cheers, > Jörg > > > --------------------------------------------------------------------- > 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
