快捷導(dǎo)航

MyBatis啟動(dòng)時(shí)控制臺(tái)無限輸出日志的原因及解決辦法

更新時(shí)間：2016年07月01日 17:07:04 作者：isea533

這篇文章主要介紹了MyBatis啟動(dòng)時(shí)控制臺(tái)無限輸出日志的原因及解決辦法的相關(guān)資料,需要的朋友可以參考下

你是否遇到過下面的情況，控制臺(tái)無限的輸出下面的日志：

Logging initialized using ‘class org.apache.ibatis.logging.log4j.Log4jImpl' adapter.
Logging initialized using ‘class org.apache.ibatis.logging.log4j.Log4jImpl' adapter.
Logging initialized using ‘class org.apache.ibatis.logging.log4j.Log4jImpl' adapter.
Logging initialized using ‘class org.apache.ibatis.logging.log4j.Log4jImpl' adapter.
Logging initialized using ‘class org.apache.ibatis.logging.log4j.Log4jImpl' adapter.

這個(gè)錯(cuò)誤只有在和Spring集成的情況下才會(huì)出現(xiàn)。

每次只要出現(xiàn)這個(gè)錯(cuò)誤，我都知道是XML出錯(cuò)了，但是具體是那個(gè)XML還沒法直接確認(rèn)，因?yàn)檫@里的日志看不出來任何有用的信息。

想定位這個(gè)錯(cuò)誤，我有一個(gè)常見的方法，就是從程序啟動(dòng)的某一個(gè)入口斷點(diǎn)，然后逐步定位這個(gè)錯(cuò)誤。

不過這種方式仍然很麻煩，這里要說的是一種迅速定位解決的辦法，操作起來很簡單。

找到org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory 類，在下面方法：

protected void autowireByType(
String beanName, AbstractBeanDefinition mbd, BeanWrapper bw, MutablePropertyValues pvs) {
這個(gè)方法大概在1200行左右。找到這個(gè)方法中catch異常的地方：
catch (BeansException ex) {
throw new UnsatisfiedDependencyException(mbd.getResourceDescription(), beanName, propertyName, ex);
}

在throw這一行斷點(diǎn)即可，這個(gè)地方是最早捕獲異常的地方，當(dāng)Mapper.xml文件出錯(cuò)的時(shí)候，這里的異常信息如下：

這里寫圖片描述

異常信息是很詳細(xì)的，具體異常文字如下：

org.springframework.core.NestedIOException:
Failed to parse mapping resource:
'file [F:\Liu\Git\bhgl\target\Franchisee-1.0\WEB-INF\classes\com\abel533\property\dao\EmployeeMapper.xml]';
nested exception is org.apache.ibatis.builder.BuilderException:
Error creating document instance.
Cause: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; 前言中不允許有內(nèi)容。

打開這個(gè)出錯(cuò)的XML后，發(fā)現(xiàn)一個(gè)很無語的錯(cuò)誤：

這里寫圖片描述

不知道什么情況，開頭多了emplo，基本上只要是 XML 中出什么錯(cuò)，都是類似的異常信息，一般都是 XML 解析出的錯(cuò)。

還有一個(gè)問題，為什么出錯(cuò)后只能看到無限輸出的一行日志，而看不到這里具體的異常信息呢？

通過追蹤代碼，發(fā)現(xiàn)在org.springframework.beans.factory.support.AbstractBeanFactory類中的方法：

protected Class<?> getTypeForFactoryBean(String beanName, RootBeanDefinition mbd) {
if (!mbd.isSingleton()) {
return null;
}
try {
FactoryBean<?> factoryBean = doGetBean(FACTORY_BEAN_PREFIX + beanName, FactoryBean.class, null, true);
return getTypeForFactoryBean(factoryBean);
}
catch (BeanCreationException ex) {
// Can only happen when getting a FactoryBean.
if (logger.isDebugEnabled()) {
logger.debug("Ignoring bean creation exception on FactoryBean type check: " + ex);
}
onSuppressedException(ex);
return null;
}
}

這里捕獲異常后，直接return null導(dǎo)致異常被吞。

由于這里是最后一層捕獲異常的地方，而且這個(gè)地方捕獲到的異常范圍會(huì)更廣，因此在這里斷點(diǎn)查看問題也是很不錯(cuò)的選擇，由于這里經(jīng)過多層異常處理，真正的錯(cuò)誤信息隱藏的比較深，如下圖：

這里寫圖片描述