- 浏览: 1816237 次
- 性别:
- 来自: 深圳
文章分类
- 全部博客 (665)
- 闲话 (17)
- ruby (1)
- javascript (40)
- linux (7)
- android (22)
- 开发过程 (11)
- 哥也读读源代码 (13)
- JVM (1)
- ant (2)
- Hibernate (3)
- jboss (3)
- web service (17)
- https (4)
- java基础 (17)
- spring (7)
- servlet (3)
- 杂记 (39)
- struts2 (10)
- logback (4)
- 多线程 (2)
- 系统诊断 (9)
- UI (4)
- json (2)
- Java EE (7)
- eclipse相关 (4)
- JMS (1)
- maven (19)
- 版本管理 (7)
- sso (1)
- ci (1)
- 设计 (18)
- 戒烟 (4)
- http (9)
- 计划 (4)
- HTML5 (3)
- chrome extensions (5)
- tomcat源码阅读 (4)
- httpd (5)
- MongoDB (3)
- node (2)
最新评论
-
levin_china:
勾选了,还是找不到
用spring annotation声明的bean,当打包在jar中时,无法被扫描到 -
GGGGeek:
我用的maven-3.5.0,还没有遇到这种情况,使用jar ...
用spring annotation声明的bean,当打包在jar中时,无法被扫描到 -
GGGGeek:
受益匪浅,从组织项目结构,到技术细节,讲的很到位,只是博主不再 ...
一个多maven项目聚合的实例 -
Aaron-Joe-William:
<?xml version="1.0" ...
hibernate逆向工程 -
li272355201:
http://archive.apache.org/dist/ ...
tomcat源码阅读(一)——环境搭建
以前也读过一些开源项目的源码,主要是spring和ant,不过那会都没记录下来,也没仔细消化吸收,现在时间久了忘了好多,而且模模糊糊地感觉学到了一些东西,但具体是什么也说不出个所以然来。深刻反省,这样读源码效果太差。
前几天决定重新开始读源码,并把读源码的过程和收获记录下来。想了想决定先用1-2个月时间把logback的源码看一下。目的是……,好吧,没什么目的,就是想读一下。
大家知道,slf4j为各种日志框架提供了一个统一的界面,使用户可以用统一的接口记录日志,但是动态地决定真正的实现框架。logback,log4j,common-logging等框架都实现了这些接口。所以分析logback,首先要从它怎么对接slf4j说起。
slf4j框架本身是非常简单的,一共只有3个package,不到30个class。而且其中很多类在读源码的时候是不必深究的。
PS:插一句题外话,很多朋友看到一个项目里动辄几十个package,数不清的类,当时就蒙了,然后读了几天就放弃了。这里我说2个建议:
1、源代码的类虽然很多,但是一般是有一个清晰的结构的(当然有些项目确实结构混乱,东一撮西一撮的,那没关系,不读就是了)。所以在深入到具体的细节之前,应该先把整个代码的结构梳理清楚,再一块一块地往下读。梳理清楚了脉络和结构,可以直接跳过不想深究的细节,只要知道它是干什么的就行了,当用到的时候再来看
2、源代码的类虽然很多,但是一般会有一个入口。比如hibernate的SessionFactory,spring的ApplicationContext,logback的LoggerFactory。从入口进去,一点点地读,必要的时候使用debug功能跟着走一走,相信会清晰很多
说完题外话,回到slf4j。slf4j最关键的是2个接口,和一个入口类。搞清楚了这3个,对slf4j就会比较清楚了。
最关键的2个接口,分别是Logger和ILoggerFactory。最关键的入口类,是LoggerFactory
所有的具体实现框架,一定会实现Logger接口和ILoggerFactory接口。前者实际记录日志,后者用来提供Logger,重要性不言自明。而LoggerFactory类,则是前面说过的入口类。
不管实现框架是什么,要获取Logger对象,都是通过这个类的getLogger()方法,所以这个类也非常重要。具体实现框架和slf4j的对接,就是通过这个类
如图,每个日志框架都需要实现ILoggerFactory接口,来说明自己是怎么提供Logger的。像log4j、logback能够提供父子层级关系的Logger,就是在ILoggerFactory的实现类里实现的。同时,它们也需要实现Logger接口,以完成记录日志。为啥log4j和logback可以一个Logger对应多个Appender?这就要去分析它们的Logger实现类。
slf4j自带的NOPLoggerFactory,实现了ILoggerFactory,其getLogger()方法很简单,就是返回一个NOPLogger
NOPLogger实现了Logger接口,它就更简单,如同它的名字一样:什么都不做
下面就是关键的LoggerFactory类了,这个入口类是怎么提供Logger的呢?
首先它调用一个private的getILoggerFactory()方法,获得一个ILoggerFactory的实现类,然后委托这个实现类提供一个Logger实现类。就是这样把获取实际Logger的工作,委托给具体的日志框架上,比如log4j、logback、common-logging等
为了获得ILoggerFactory的实现类,它首先判断初始化是否成功,如果没成功,它会委托NOPLoggerFactory来提供Logger,最终结果就是一个没实现的NOPLogger。如果初始化成功了,就是和日志框架对接成功,就委托日志框架的ILoggerFactory来提供Logger的实现。
在初始化里,它要做3个工作。首先是检查classpath里是否存在多个日志框架,如果有就会抛出警告信息,提示用户只保留一个。然后是关键的bind()方法,绑定实现框架。最后再检查一下版本完整性。
这段代码提到了一个最关键的StaticLoggerBinder类,检查是否有这个类存在,以及这个类有没有getSingleton()方法,如果有,就视为绑定成功。其实这个类还必须有getLoggerFactory()方法,否则虽然绑定成功,但是到了运行期,一样会抛出NoSuchMethodException。我认为这里是slf4j设计不好的地方,应该在bind()方法里,就检查一下StaticLoggerBinder有没有实现getLoggerFactory()方法。
这个StaticLoggerBinder类,就是具体实现框架和slf4j框架对接的接口。
这就介绍完了logback是怎么和slf4j对接的。不止是logback,任何日志框架,一定都是通过自己的StaticLoggerBinder类,来和slf4j对接。这个类的实现,在不同的框架中不同,比如后面会说到,在logback中,这个类被设计为或者简单的返回一个默认的LoggerContext(LoggerContext是ILoggerFactory在logback中的实现),或者通过ContextSelector(logback特有的)来选择一个LoggerContext并返回。
大家可能会有一个疑问:在LoggerFactory类的bind()方法里,依赖了StaticLoggerBinder类,但是slf4j框架里又没有这个类,那么框架一开始是怎么编译通过并发布成jar包的呢?
我认为应该是这样的:
作者一开始的时候,是以类似图里的包结构组织代码的。为了编译通过,作者写了一个StaticLoggerBinder类
然后,作者把org.slf4j、org.slf4j.helpers、org.slf4j.spi这3个package发布为slf4j-api.jar。把org.slf4j.impl发布为slf4j-nop.jar
用户实际使用的时候,必须要引入slf4j-api.jar和具体实现框架,比如log4j.jar,以及对接用的slf4j-log4j.jar,不需要引入slf4j-nop.jar
最后,大家可能还有一个疑问:为什么log4j和logback这么相似,又为什么log4j和logback可以和slf4j结合地这么好呢?这是因为,这3个框架的作者,根本是同一个人。这位大哥应该可以算作日志界的战斗机了
前几天决定重新开始读源码,并把读源码的过程和收获记录下来。想了想决定先用1-2个月时间把logback的源码看一下。目的是……,好吧,没什么目的,就是想读一下。
大家知道,slf4j为各种日志框架提供了一个统一的界面,使用户可以用统一的接口记录日志,但是动态地决定真正的实现框架。logback,log4j,common-logging等框架都实现了这些接口。所以分析logback,首先要从它怎么对接slf4j说起。
slf4j框架本身是非常简单的,一共只有3个package,不到30个class。而且其中很多类在读源码的时候是不必深究的。
PS:插一句题外话,很多朋友看到一个项目里动辄几十个package,数不清的类,当时就蒙了,然后读了几天就放弃了。这里我说2个建议:
1、源代码的类虽然很多,但是一般是有一个清晰的结构的(当然有些项目确实结构混乱,东一撮西一撮的,那没关系,不读就是了)。所以在深入到具体的细节之前,应该先把整个代码的结构梳理清楚,再一块一块地往下读。梳理清楚了脉络和结构,可以直接跳过不想深究的细节,只要知道它是干什么的就行了,当用到的时候再来看
2、源代码的类虽然很多,但是一般会有一个入口。比如hibernate的SessionFactory,spring的ApplicationContext,logback的LoggerFactory。从入口进去,一点点地读,必要的时候使用debug功能跟着走一走,相信会清晰很多
说完题外话,回到slf4j。slf4j最关键的是2个接口,和一个入口类。搞清楚了这3个,对slf4j就会比较清楚了。
最关键的2个接口,分别是Logger和ILoggerFactory。最关键的入口类,是LoggerFactory
所有的具体实现框架,一定会实现Logger接口和ILoggerFactory接口。前者实际记录日志,后者用来提供Logger,重要性不言自明。而LoggerFactory类,则是前面说过的入口类。
Logger logger = LoggerFactory.getLogger(Main.class);
不管实现框架是什么,要获取Logger对象,都是通过这个类的getLogger()方法,所以这个类也非常重要。具体实现框架和slf4j的对接,就是通过这个类
如图,每个日志框架都需要实现ILoggerFactory接口,来说明自己是怎么提供Logger的。像log4j、logback能够提供父子层级关系的Logger,就是在ILoggerFactory的实现类里实现的。同时,它们也需要实现Logger接口,以完成记录日志。为啥log4j和logback可以一个Logger对应多个Appender?这就要去分析它们的Logger实现类。
slf4j自带的NOPLoggerFactory,实现了ILoggerFactory,其getLogger()方法很简单,就是返回一个NOPLogger
public class NOPLoggerFactory implements ILoggerFactory { public NOPLoggerFactory() { // nothing to do } public Logger getLogger(String name) { return NOPLogger.NOP_LOGGER; } }
NOPLogger实现了Logger接口,它就更简单,如同它的名字一样:什么都不做
/** A NOP implementation. */ final public void info(String msg) { // NOP } /** A NOP implementation. */ final public void info(String format, Object arg1) { // NOP } /** A NOP implementation. */ final public void info(String format, Object arg1, Object arg2) { // NOP }
下面就是关键的LoggerFactory类了,这个入口类是怎么提供Logger的呢?
public static Logger getLogger(String name) { ILoggerFactory iLoggerFactory = getILoggerFactory(); return iLoggerFactory.getLogger(name); }
首先它调用一个private的getILoggerFactory()方法,获得一个ILoggerFactory的实现类,然后委托这个实现类提供一个Logger实现类。就是这样把获取实际Logger的工作,委托给具体的日志框架上,比如log4j、logback、common-logging等
public static ILoggerFactory getILoggerFactory() { if (INITIALIZATION_STATE == UNINITIALIZED) { INITIALIZATION_STATE = ONGOING_INITILIZATION; performInitialization(); } switch (INITIALIZATION_STATE) { case SUCCESSFUL_INITILIZATION: return StaticLoggerBinder.getSingleton().getLoggerFactory(); case NOP_FALLBACK_INITILIZATION: return NOP_FALLBACK_FACTORY; case FAILED_INITILIZATION: throw new IllegalStateException(UNSUCCESSFUL_INIT_MSG); case ONGOING_INITILIZATION: // support re-entrant behavior. // See also http://bugzilla.slf4j.org/show_bug.cgi?id=106 return TEMP_FACTORY; } throw new IllegalStateException("Unreachable code"); }
为了获得ILoggerFactory的实现类,它首先判断初始化是否成功,如果没成功,它会委托NOPLoggerFactory来提供Logger,最终结果就是一个没实现的NOPLogger。如果初始化成功了,就是和日志框架对接成功,就委托日志框架的ILoggerFactory来提供Logger的实现。
private final static void performInitialization() { singleImplementationSanityCheck(); bind(); if (INITIALIZATION_STATE == SUCCESSFUL_INITILIZATION) { versionSanityCheck(); } }
在初始化里,它要做3个工作。首先是检查classpath里是否存在多个日志框架,如果有就会抛出警告信息,提示用户只保留一个。然后是关键的bind()方法,绑定实现框架。最后再检查一下版本完整性。
private final static void bind() { try { // the next line does the binding StaticLoggerBinder.getSingleton(); INITIALIZATION_STATE = SUCCESSFUL_INITILIZATION; emitSubstituteLoggerWarning(); } catch (NoClassDefFoundError ncde) { String msg = ncde.getMessage(); if (msg != null && msg.indexOf("org/slf4j/impl/StaticLoggerBinder") != -1) { INITIALIZATION_STATE = NOP_FALLBACK_INITILIZATION; Util .report("Failed to load class \"org.slf4j.impl.StaticLoggerBinder\"."); Util.report("Defaulting to no-operation (NOP) logger implementation"); Util.report("See " + NO_STATICLOGGERBINDER_URL + " for further details."); } else { failedBinding(ncde); throw ncde; } } catch(java.lang.NoSuchMethodError nsme) { String msg = nsme.getMessage(); if (msg != null && msg.indexOf("org.slf4j.impl.StaticLoggerBinder.getSingleton()") != -1) { INITIALIZATION_STATE = FAILED_INITILIZATION; Util.report("slf4j-api 1.6.x (or later) is incompatible with this binding."); Util.report("Your binding is version 1.5.5 or earlier."); Util.report("Upgrade your binding to version 1.6.x. or 2.0.x"); } throw nsme; } catch (Exception e) { failedBinding(e); throw new IllegalStateException("Unexpected initialization failure", e); } }
这段代码提到了一个最关键的StaticLoggerBinder类,检查是否有这个类存在,以及这个类有没有getSingleton()方法,如果有,就视为绑定成功。其实这个类还必须有getLoggerFactory()方法,否则虽然绑定成功,但是到了运行期,一样会抛出NoSuchMethodException。我认为这里是slf4j设计不好的地方,应该在bind()方法里,就检查一下StaticLoggerBinder有没有实现getLoggerFactory()方法。
这个StaticLoggerBinder类,就是具体实现框架和slf4j框架对接的接口。
这就介绍完了logback是怎么和slf4j对接的。不止是logback,任何日志框架,一定都是通过自己的StaticLoggerBinder类,来和slf4j对接。这个类的实现,在不同的框架中不同,比如后面会说到,在logback中,这个类被设计为或者简单的返回一个默认的LoggerContext(LoggerContext是ILoggerFactory在logback中的实现),或者通过ContextSelector(logback特有的)来选择一个LoggerContext并返回。
大家可能会有一个疑问:在LoggerFactory类的bind()方法里,依赖了StaticLoggerBinder类,但是slf4j框架里又没有这个类,那么框架一开始是怎么编译通过并发布成jar包的呢?
我认为应该是这样的:
作者一开始的时候,是以类似图里的包结构组织代码的。为了编译通过,作者写了一个StaticLoggerBinder类
private final ILoggerFactory loggerFactory; private StaticLoggerBinder() { loggerFactory = new NOPLoggerFactory(); } public ILoggerFactory getLoggerFactory() { return loggerFactory; }
然后,作者把org.slf4j、org.slf4j.helpers、org.slf4j.spi这3个package发布为slf4j-api.jar。把org.slf4j.impl发布为slf4j-nop.jar
用户实际使用的时候,必须要引入slf4j-api.jar和具体实现框架,比如log4j.jar,以及对接用的slf4j-log4j.jar,不需要引入slf4j-nop.jar
最后,大家可能还有一个疑问:为什么log4j和logback这么相似,又为什么log4j和logback可以和slf4j结合地这么好呢?这是因为,这3个框架的作者,根本是同一个人。这位大哥应该可以算作日志界的战斗机了
发表评论
-
小读spring ioc源码(五)——BeanDefinitionDocumentReader
2012-07-28 13:11 2764上一篇博客说到,BeanDefinition的解析,已经走到了 ... -
小读spring ioc源码(四)——BeanDefinitionReader
2012-07-24 19:02 2392上一篇博客说到,ApplicationContext将解析Be ... -
小读spring ioc源码(三)——XmlWebApplicationContext初始化的整体过程
2012-07-12 16:54 2874上一篇说到,ContextLoader ... -
小读spring ioc源码(二)——ContextLoaderListener
2012-06-25 18:41 2824实际开发中,比较多的项目是web项目,这时候加载spring, ... -
小读spring ioc源码(一)——整体介绍
2012-06-18 22:59 2557最近在读spring ioc的源码,用EA画了几张比较清楚的类 ... -
读logback源码系列文章(八)——记录日志的实际工作类Encoder
2011-10-17 20:34 2931本系列的博客从logback怎么对接slf4j开始,逐步介绍了 ... -
读logback源码系列文章(七)——配置的实际工作类Action
2011-10-11 22:59 3478上篇博客介绍了ContextInitializer类如何把框架 ... -
读logback源码系列文章(六)——ContextInitializer
2011-10-09 21:46 6721放了一个长假回来啦,继续写本系列博客 这篇博客我们接着上一篇 ... -
读logback源码系列文章(五)——Appender
2011-09-16 21:03 13762明天要带老婆出国旅游 ... -
读logback源码系列文章(四)——记录日志
2011-09-12 02:22 4358今天晚上本来想来写一下Logger怎么记录日志,以及Appen ... -
读logback源码系列文章(三)——创建Logger
2011-09-07 21:35 6130上一篇博客介绍了logback的StaticLoggerBin ... -
读logback源码系列文章(二)——提供ILoggerFactory
2011-09-07 20:07 6565上篇博客介绍了logback是 ...
相关推荐
logback+slf4j 异步日志输出到不同级别的文件-配置文件,下载即可使用。结合lombok【@slf4j】即可方便愉快的输出日志了 666
https://github.com/tomcat-slf4j-logback/tomcat-slf4j-logback上的jar与源码,网络不好,下载不易,特此分享。包括: logback-1.2.3.zip Tomcat7.0.82\tomcat-juli-7.0.82-slf4j-1.7.25-logback-1.2.3.zip Tomcat...
log4j-slf4j+logback1.3.0 共六个jar包
slf4j,logback.xml
只要里面的logback-classic-1.1.7,logback-core-1.1.7,slf4j-api-1.7.21的JAR就可以打印出日志信息,而带有source表示对应的JAR包的源代码。可以要也可以不要
logback + slf4j web项目源码,同时包含一些常用的json和xml互相转化 ,以及json与bean互相转化实例
janino-2.3.17.jar jcl-over-slf4j-1.6.1.jar log4j-1.2.8.jar logback-access-0.9.24.jar logback-classic-0.9.24.jar logback-core-0.9.24.jar ... slf4j-1.6.1+logback-0.9.24.rar slf4j-api-1.6.1.jar
logback+slf4j自定义appender输出的使用方法,让你明白什么是自定义输出意思使用方式。
springMvc mybaties slf4j所需包
logback 1.2.6 和 slf4j 1.7.32
slf4j日志demo项目 logback.xml配置详解,slf4j日志demo项目 logback.xml配置详解,slf4j日志demo项目 logback.xml配置详解,slf4j日志demo项目 logback.xml配置详解
Tomcat SLF4J Logback是tomcat的替代产品,它允许所有内部日志记录全部使用我们喜欢的slf4j / logback库。 注意 从logback 1.1.7开始,不再需要在server.xml中包含${catalina.home}来进行logback访问。 我们还重新...
Slf4j+logback实现logback测试,Slf4j+logback实现logback测试
slf4j+logback需要的jar和配置文件,下载之后可以直接使用
slf4j-1.7.25jar包+logback-1.2.3jar包 slf4j-1.7.25jar包+logback-1.2.3jar包
NULL 博文链接:https://xiayingjie.iteye.com/blog/828498
SLF4J结合logback已经逐步替代了Log4j,带来了更好的性能和灵活性。
NULL 博文链接:https://tristan-s.iteye.com/blog/1966020
NULL 博文链接:https://cywhoyi.iteye.com/blog/1941165
NULL 博文链接:https://200cc.iteye.com/blog/2109690