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. 
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) {
        TypeConverter converter = this.getCustomTypeConverter();
        if (converter == null) {
            converter = bw;
        }

        Set<String> autowiredBeanNames = new LinkedHashSet(4);
        String[] propertyNames = this.unsatisfiedNonSimpleProperties(mbd, bw);
        String[] var8 = propertyNames;
        int var9 = propertyNames.length;

        for(int var10 = 0; var10 < var9; ++var10) {
            String propertyName = var8[var10];

            try {
                PropertyDescriptor pd = bw.getPropertyDescriptor(propertyName);
                if (!Object.class.equals(pd.getPropertyType())) {
                    MethodParameter methodParam = BeanUtils.getWriteMethodParameter(pd);
                    boolean eager = !PriorityOrdered.class.isAssignableFrom(bw.getWrappedClass());
                    DependencyDescriptor desc = new AbstractAutowireCapableBeanFactory.AutowireByTypeDependencyDescriptor(methodParam, eager);
                    Object autowiredArgument = this.resolveDependency(desc, beanName, autowiredBeanNames, (TypeConverter)converter);
                    if (autowiredArgument != null) {
                        pvs.add(propertyName, autowiredArgument);
                    }

                    Iterator var17 = autowiredBeanNames.iterator();

                    while(var17.hasNext()) {
                        String autowiredBeanName = (String)var17.next();
                        this.registerDependentBean(autowiredBeanName, beanName);
                        if (this.logger.isDebugEnabled()) {
                            this.logger.debug("Autowiring by type from bean name '" + beanName + "' via property '" + propertyName + "' to bean named '" + autowiredBeanName + "'");
                        }
                    }

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

    }

找到這個方法中catch異常的地方：
在throw這一行斷點即可，這個地方是最早捕獲異常的地方，當Mapper.xml文件出錯的時候，這裏的異常信息如下： 

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

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; 前言中不允許有內容。

 

基本上只要是 XML 中出什麼錯，都是類似的異常信息，一般都是 XML 解析出的錯。

還有一個問題，爲什麼出錯後只能看到無限輸出的一行日誌，而看不到這裏具體的異常信息呢？
通過追蹤代碼，發現在org.springframework.beans.factory.support.AbstractBeanFactory類中的方法：

protected Class<?> getTypeForFactoryBean(final FactoryBean<?> factoryBean) {
        try {
            return System.getSecurityManager() != null ? (Class)AccessController.doPrivileged(new PrivilegedAction<Class<?>>() {
                public Class<?> run() {
                    return factoryBean.getObjectType();
                }
            }, this.getAccessControlContext()) : factoryBean.getObjectType();
        } catch (Throwable var3) {
            this.logger.warn("FactoryBean threw exception from getObjectType, despite the contract saying that it should return null if the type of its object cannot be determined yet", var3);
            return null;
        }
    }

這裏捕獲異常後，直接return null導致異常被吞。

由於這裏是最後一層捕獲異常的地方，而且這個地方捕獲到的異常範圍會更廣，因此在這裏斷點查看問題也是很不錯的選擇，由於這裏經過多層異常處理，真正的錯誤信息隱藏的比較深，如下圖： 

原文：https://blog.csdn.net/isea533/article/details/51277786