Re: JDBC drivers in WEB-INF/lib
Am 2018-09-11 um 23:53 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 9/11/18 3:33 PM, Michael Osipov wrote: in bug 62670 [1] -- contrary to my statement -- Mark pointed out that is it pefectly legal to have a JDBC driver in WEB-INF/lib. While I was living for years with the assumption that this is discouraged because the DriverManager is VM wide and not classloader-wide, plus numerous SO questions have been asked about this. Most answers are based upon speculation and age-old wisdom about decades-old versions of Tomcat. Most of those questions haven't been answered by anyone who actually knows the answers. While reading [2] it is still not clear why this is a perfectly legal case. Putting a JDBC library into WEB-INF/lib is a supported use-case in Tomcat, full stop. That's why it's a legal case: simply because we say it is. How can we improve the docs to make it crystal clear for users under which circumstances a driver is valid in WEB-INF/lib? I can't imagine a case where it should *not* be valid. The documentation[2] simply says that the application won't be able to rely on auto-registration of JDBC drivers (which has, in my experience, always been flaky anyway) and you'll have to go back to the practice of calling Class.forName(driverName) and possibly calling newInstance() on the Class object, just like it was still 1995. I haven't checked, but presumably both of the JDBC pools shipped with Tomcat perform this operation for you, so you don't have to have a ServletContextListener that does it, but you will want to take care to de-register your JDBC driver when your application shuts-down, or you will have a ClassLoader-pinning leak (DriverManager[app CL] -> JDBC Driver Class [webapp CL] -> webapp CL -> all classes loaded for the webapp). There are some drivers (notably MySQL's Connector/J) that are notoriously difficult to kill because they are written by people who don't understand why drivers would ever have to be removed from memory, but that's a different problem. At $work, we still use CATALINA_BASE/lib for out JDBC drivers, but that's simply due to historical deployment strategy. - -chris References left in-tact: [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=62670#c2 [2] http://tomcat.apache.org/tomcat-9.0-doc/jndi-datasource-examples-howto .html Thank you very much for your elaboration. I will keep this as a reference. It still makes sense to put the driver into CATALINA_HOME/lib if you multiple apps running with the same database type. Regards, Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: JDBC drivers in WEB-INF/lib
On 9/11/2018 2:53 PM, Christopher Schultz wrote: On 9/11/18 3:33 PM, Michael Osipov wrote: ... plus numerous SO questions have been asked about this. ... Most of those questions haven't been answered by anyone who actually knows the answers. Sad but true. Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: JDBC drivers in WEB-INF/lib
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 9/11/18 3:33 PM, Michael Osipov wrote: > in bug 62670 [1] -- contrary to my statement -- Mark pointed out > that is it pefectly legal to have a JDBC driver in WEB-INF/lib. > While I was living for years with the assumption that this is > discouraged because the DriverManager is VM wide and not > classloader-wide, plus numerous SO questions have been asked about > this. Most answers are based upon speculation and age-old wisdom about decades-old versions of Tomcat. Most of those questions haven't been answered by anyone who actually knows the answers. > While reading [2] it is still not clear why this is a perfectly > legal case. Putting a JDBC library into WEB-INF/lib is a supported use-case in Tomcat, full stop. That's why it's a legal case: simply because we say it is. > How can we improve the docs to make it crystal clear for users > under which circumstances a driver is valid in WEB-INF/lib? I can't imagine a case where it should *not* be valid. The documentation[2] simply says that the application won't be able to rely on auto-registration of JDBC drivers (which has, in my experience, always been flaky anyway) and you'll have to go back to the practice of calling Class.forName(driverName) and possibly calling newInstance() on the Class object, just like it was still 1995. I haven't checked, but presumably both of the JDBC pools shipped with Tomcat perform this operation for you, so you don't have to have a ServletContextListener that does it, but you will want to take care to de-register your JDBC driver when your application shuts-down, or you will have a ClassLoader-pinning leak (DriverManager[app CL] -> JDBC Driver Class [webapp CL] -> webapp CL -> all classes loaded for the webapp). There are some drivers (notably MySQL's Connector/J) that are notoriously difficult to kill because they are written by people who don't understand why drivers would ever have to be removed from memory, but that's a different problem. At $work, we still use CATALINA_BASE/lib for out JDBC drivers, but that's simply due to historical deployment strategy. - -chris References left in-tact: > [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=62670#c2 [2] > http://tomcat.apache.org/tomcat-9.0-doc/jndi-datasource-examples-howto .html -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluYOXQACgkQHPApP6U8 pFhBCBAAi+BqVwcKOqo7OQVK2RW5nODITckdVCMiX/qLrlUQ0smZc+cp74SVoup6 kCFrnICvuvPawI0Qt0tCnzkuMoagM5DpwTFWlud5Q5XNN5nZq38hvlzTrVb8hl/j rniK+T9tgnCn406RFf09QpZA70b5QGa0O151Gv/ckZm3FmYIXo2MnzJ4vtsnC/CJ /sSXt4sfL5IodI0iiqdEcuByrpHlvben47KM2n/+QTaxWiU61XQ7+D+khKo+kpDY yxXlTzkWCDp2TFRLYYUrYHUZyCgXydQYIGH1jY+qtDclarP5+LTrFwkEYU+G4tIX Pvr6gGG3a3NM2S9mbbLGYl5A8y2yiYPJQ8bYBbOvKk1a5AG4yfYDzx7oKjmbAP/O DZgNhgFC/vZZvD75L/3dROErIQrQkJbBqDNLUpXlzVFlBLzaBNaqDRZ23ZDQ9lh1 hRO0OxHuOhNYQ0f2V1C9HueAwWE3ZfBj37L2eGvLAJQ9TP233lx9BD69jTVZChOd TPYE/NUiViThj4XaYXBtHzmOk6vwOOWrEebUhaq7s8duaQAWBWDINAg792T6wX6l YJRL6HW7uRfWJqpdJJjVZI9xjZ7kC1cHfGeIB02LC8r9d+ra68ZJFSk0DiaReKrH RjZQ5rQJkOIr+n8Wyqu5P6Ge6fpLvDzHnsGOqxHQo7SdAdbXNJ0= =8tx0 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
JDBC drivers in WEB-INF/lib
Hi folks, in bug 62670 [1] -- contrary to my statement -- Mark pointed out that is it pefectly legal to have a JDBC driver in WEB-INF/lib. While I was living for years with the assumption that this is discouraged because the DriverManager is VM wide and not classloader-wide, plus numerous SO questions have been asked about this. While reading [2] it is still not clear why this is a perfectly legal case. How can we improve the docs to make it crystal clear for users under which circumstances a driver is valid in WEB-INF/lib? [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=62670#c2 [2] http://tomcat.apache.org/tomcat-9.0-doc/jndi-datasource-examples-howto.html Regards, Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
