iBATIS的Log機制是什么

本篇內容介紹了“iBATIS的Log機制是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

iBATIS的Log機制的問題我們要首先從iBATIS的Log使用的兩個類開始，他們是：
com.ibatis.common.logging.LogFactory

com.ibatis.common.logging.Log

查看這兩個類的源代碼，可以發現它不過是對org.apache.commons.logging、org.apache.log4j、java.util.logging，三種目前可用的Log框架的同時封裝。

開始時很費解，不知iBATIS開發者為何要采用這種方式，直接使用某個確定的Log不就可以了嗎？思考后發現原因如下：

“iBATIS宣稱自己具有最少的第三方依賴性，其Log采用以上機制的原因也正在于此：如果iBATIS采用某個特定的Log框架，那么它就必須添加對該框架的依賴關系；而考慮到使用iBATIS的開發者肯定會使用以上三個Log框架中的某個，因此iBATIS決定與其使用者共用該框架；這樣iBATIS就可以避免不必要的第三方依賴；另外，如果開發者的確沒有使用某Log框架，查看iBATIS的Log代碼可以發現它對此也有相應措施，即不log出任何東西。”

思考明白以上原因后，再查看com.ibatis.common.logging.LogFactory的代碼，就不難理解了，但還是說明幾個小點：

private static void tryImplementation(String testClassName, String implClassName) ...{       if (logConstructor == null) ...{         try ...{           Resources.classForName(testClassName);           Class implClass = Resources.classForName(implClassName);           logConstructor = implClass.getConstructor(new Class[]...{Class.class});         } catch (Throwable t) ...{         }       }    }

testClassName為某Log框架中的工廠類的類名，implClassName為該框架相應Log接口實現類的類名（該類屬于iBATIS）。代碼先加載工廠類，然后加載實現類，得到其class，并由class得到constructor，供getLog方法調用時使用。

“iBATIS的Log機制是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！