MyBatis 最常见错误，启动时控制台无限输出日志

你是否遇到过下面的情况，控制台无限的输出下面的日志：

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.

这个错误只有在和spring集成的情况下才会出现。

每次只要出现这个错误，我都知道是XML出错了，但是具体是那个XML还没法直接确认，因为这里的日志看不出来任何有用的信息。

想定位这个错误，我有一个常见的方法，就是从程序启动的某一个入口断点，然后逐步定位这个错误。

不过这种方式仍然很麻烦，这里要说的是一种迅速定位解决的办法，操作起来很简单。

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

protected void autowireByType(
            String beanName, AbstractBeanDefinition mbd, BeanWrapper bw, MutablePropertyValues pvs) {

这个方法大概在1200行左右。找到这个方法中catch异常的地方：

catch (BeansException ex) {
    throw new UnsatisfiedDependencyException(mbd.getResourceDescription(), beanName, propertyName, ex);
}

在throw这一行断点即可，这个地方是最早捕获异常的地方，当Mapper.xml文件出错的时候，这里的异常信息如下：

异常信息是很详细的，具体异常文字如下：

org.springframework.core.NestedIOException: 
Failed to parse mapping resource: 
'file [F:LiuGithgl	argetFranchisee-1.0WEB-INFclassescomabel533propertydaoEmployeeMapper.xml]'; 
nested exception is org.apache.ibatis.builder.BuilderException: 
Error creating document instance.  
Cause: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; 前言中不允许有内容。

打开这个出错的XML后，发现一个很无语的错误：

不知道什么情况，开头多了emplo，基本上只要是 XML 中出什么错，都是类似的异常信息，一般都是 XML 解析出的错。

还有一个问题，为什么出错后只能看到无限输出的一行日志，而看不到这里具体的异常信息呢？

通过追踪代码，发现在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导致异常被吞。

由于这里是最后一层捕获异常的地方，而且这个地方捕获到的异常范围会更广，因此在这里断点查看问题也是很不错的选择，由于这里经过多层异常处理，真正的错误信息隐藏的比较深，如下图：

看到这儿，相信再遇到这个问题的时候应该会很容易解决了。

来源：http://blog.csdn.net/isea533/article/details/51277786

null