I'm still having a problem. I'm trying de register the JDBC driver in a
crude way when the context is destroyed.
/**
* @see ServletContextListener#contextDestroyed(ServletContextEvent)
*/
public void contextDestroyed(ServletContextEvent sce) {
Enumeration drivers = DriverManager.getDrivers();
while (drivers.hasMoreElements()) {
Driver driver = (Driver) drivers.nextElement();
try {
DriverManager.deregisterDriver(driver);
} catch (SQLException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
Its not throwing an exception so It must be deregestering it? Why would it
be different if the application was deployed before tomcat was started and
after tomcat was started. Its only after deploying then restarting that I
have the problem? Does it use a different class loader for the inital load?
On Thu, Jul 16, 2009 at 11:54 PM, Mark Thomas <ma...@apache.org> wrote:
> Wesley Acheson wrote:
> > Theres only two jars and their not used.
>
> The flippant reply would be "Well delete them then and the problem will
> go away"
>
> > WEB-INF/lib/mysql-connector-java-5.1.6.jar
>
> As soon as I saw that, I suspected it would be the one causing grief and...
>
> > However the webapp isn't deployed correctly it still only contains
> > WEB-INF/lib/mysql-connector-java-5.1.6.jar
>
> The problem is that if you put a jdbc driver jar in the lib directory,
> it gets registered with DriverManager automatically.
>
> Try de-registering it with a context listener (which you'll need to do
> anyway to avoid a permgen leak on reload).
>
> As an aside, Tomcat tries (and fails) to fix this for you automatically.
> That should be fixed in the next 6.0.x release.
>
> If you still see the problem when the driver is de-registered, I can
> take a look with a profiler.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
