DO NOT REPLY [Bug 50068] Memory leak with Driver registration
https://issues.apache.org/bugzilla/show_bug.cgi?id=50068 Jeremy Boynes jboy...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #3 from Jeremy Boynes jboy...@apache.org 2010-12-21 22:51:28 EST --- Resolving per Henri's option 1 that this is a feature and the advice is to use a DataSource from the container rather than a raw JDBC Driver. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50068] Memory leak with Driver registration
https://issues.apache.org/bugzilla/show_bug.cgi?id=50068 Henri Yandell bay...@apache.org changed: What|Removed |Added OS/Version||All --- Comment #1 from Henri Yandell bay...@apache.org 2010-11-07 02:36:43 EST --- Seems like there are three paths: 1) Document that this exists and point out that people should be using the dataSource parameter anyway. 2) Document and provide a flag that disables this part of the spec - 'DISABLE_SHODDY_SPEC_FEATURES' or its ilk. We could disable x:forEach too :) There are other items in the FAQ, so it's possible there are other crufty pieces of code that should be disabled. 3) Solve the problem while maintaining the feature. I don't see any solutions for 3, but maybe someone else does. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50068] Memory leak with Driver registration
https://issues.apache.org/bugzilla/show_bug.cgi?id=50068 --- Comment #2 from Konstantin Kolinko knst.koli...@gmail.com 2010-11-07 12:00:40 EST --- 1. The only way that I see that this can be solved is to define a listener. Even if the tag was the first to register a JDBC driver, it cannot unload it immediately after use, but can do it only when the webapp stops. That would be a task for a listener, not for a tag. A tag library can define listeners in its TLD. (Or a webapp can define its own listener for the purpose of [registering and] deregistering its JDBC drivers.) 2. The JSTL spec explicitly says that such usage is not recommended. Reading jstl-1_2-mrel2-spec.pdf, chapter 10.6 sql:setDataSource: [cite] As mentioned in Section 10.1.1, using JDBC’s DriverManager class to access a database is intended for prototyping purposes only because it does not provide connection management features one can expect from a properly designed DataSource object. [/cite] -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
