registered the JDBC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped.

最近在用maven整合SSH做个人主页时候,在eclipse里面使用tomcat7插件发布项目是没有问题的,但当打包成war之后,使用tomcat7单独发布项目,就出现了以下的错误.

严重: Context [/wangxin] startup failed due to previous errors
八月 16, 2017 7:29:12 下午 org.apache.catalina.loader.WebappClassLoaderBase clearReferencesJdbc
严重: The web application [/wangxin] registered the JDBC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
八月 16, 2017 7:29:12 下午 org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads
严重: The web application [/wangxin] appears to have started a thread named [Timer-0] but has failed to stop it. This is very likely to create a memory leak.
八月 16, 2017 7:29:12 下午 org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads
严重: The web application [/wangxin] appears to have started a thread named [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0] but has failed to stop it. This is very likely to create a memory leak.
八月 16, 2017 7:29:12 下午 org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads
严重: The web application [/wangxin] appears to have started a thread named [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1] but has failed to stop it. This is very likely to create a memory leak.
八月 16, 2017 7:29:12 下午 org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads
严重: The web application [/wangxin] appears to have started a thread named [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2] but has failed to stop it. This is very likely to create a memory leak.
八月 16, 2017 7:29:12 下午 org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads
严重: The web application [/wangxin] appears to have started a thread named [MySQL Statement Cancellation Timer] but has failed to stop it. This is very likely to create a memory leak.

这个错误的意思是:在tomcat7启动时候,tomcat自带的一个内存检查的监听器发现,你的项目使用了一个数据库的连接池,并没有关闭的情况下,又去注册了一个连接池,为了保证内存不泄露,所以不允许你项目进行部署.

理论上,使用了SSH框架去整合了数据库,使用了jpa和c3P0连接池,是根本不需要去关心是要去关闭连接和GC的,但是还是报错,对此,就很有疑问了.

网上给出的理论是,因为tomcat7采用了一个监听技术,所以就会这样,完全可以关闭.但事实上,我关闭了之后,虽然启动不报错了,但是还是部署不了,日志里面还是这个错误.

同样的,网上还说了一个方法,就是把数据库的jar包放到tomcat的lib下面,我试了还是没用.

最后层层排查,发现,错误出现在了我的applicationContext.xml上,为了方便开发,我把applicationContext.xml里面的jdbc方面全部提取出来,放到了一个性的applicationContext-jdbc.xml文件里面,并且在总的xml里面使用了<import>标签去插入.

然后,我发现我的web.xml文件配置有点不同,即spring的监听器的classpath配置错误

<context-param>
     <param-name>contextConfigLocation</param-name>
     <param-value>classpath:applicationContext*.xml</param-value>
</context-param>

我在classpath那边配置多加了一个*这就导致了

正确的代码:

<context-param>
      <param-name>contextConfigLocation</param-name>
      <param-value>classpath:applicationContext.xml</param-value>
</context-param>

由于多配了一个*,这就导致了当启动加载的时候,先加载了applicationContext-jdbc的内容,然后再加载applicationContext的内容,当加载appliactionContext的时候,再次去加载里面<import>标签导入的applicationContext-jdbc内容,这就造成了一次项目加载了两次数据库的连接池,因此造成了重复加载,项目无法启动的问题.

对于web.xml的配置,在这里我还得说一个非常骚气的问题.

不知先前什么情况,在WEF-INF下自动生成了一个classes文件夹,然后文件夹里面竟然多了一个applicationContext文件(理论上编译时候,生成到target里面的WEF-INF文件夹下),这就造成了,当修改resource里面的xml文件时候,没有修改到classes里面的文件,于是悲剧的一幕发生了:

使用SSH框架整合,使用SpringJPA整合的时候,写了一个action,action里面是使用的注解,注入的service,service里面用注解注入的dao,dao只写了一个接口,接口继承了JpaRepository.

使用junit直接调用service里面方法,能获取到数据库里面的数据,而使用tomcat运行的话,调用action获取不到数据.根本不报错,使用debug发现,运行过程中,并没有注入service以及dao.即都是null.

结果原因就是:在maven项目中的classes文件夹下面,自动将resource全部复制过来,而在mavenresource里面的配置文件是修改过的,这就导致了,junit和tomcat运行时候采用的applicationContext.xml文件不同,导致了这个错误.而同时,在web.xml中,配置spring的监听器使用的是

<param-value>classpath*:applicationContext.xml</param-value>

即加载所有classpath下面的xml文件,这就造成了一种情况,就是在junit时候能加载spring自动注入,而使用tomcat却加载不了,同时还不会报错....

就这两个关于web.xml的错误,与君共勉!