① 日志实体类信息包括哪些内容
tomcat 日志信息
前言
tomcat的日志信息。
tomcat如何查看日志信息。
tomcat的日志信息包括哪些部分。
tomcat的日志信息包括哪些部分
1、启动/关闭tomcat时的日志信息，这里指的是tomcat本身的日志信息，往往是tomcat本身的问题。
比如，启动tomcat时，端口被占用。
2、访问网站时出现的日志信息，这里往往是代码程序出现bug。
tomcat如何查看日志信息
tomcat的日志信息文件，是放在安装目录/logs/目录下的。最常用的包括两部分，就是前面说的2种类型。
1、启动/关闭tomcat时的日志信息，在 catalina.2015-12-02.log文件里。
每天都会生成一个新的单独的文件。
2、访问网站时的日志信息，在localhost.2015-12-02.log文件里。
只要那天有访问，就会生成一个新的单独的日志文件。
收起全文
一个日志系统需要具备哪些功能
② Dubbo（一）——Dubbo 集成于 Spring 的原理
最近一直在看bbo的源码部分。在阅读的时候，需要有一个入手点，才能一点一点的进行下去。自己在研究的时候，发现思绪比较乱，于是就以 芋道源码 为基础，一点一点的啃食。芋道源码是直接从bbo的配置和一些核心的API开始讲起，是从bbo已经启动的过程作为开始节点，而这些核心 API 与 Spring 的之间的关系被省略了，这些东西对我来说属于前置的知识点，所以花了比较长的时间又从 Dubbo 的核心 API 倒着往前看。
在阅读 Dubbo 时，发现前置知识越来越多，如：Spring 的 refresh 中的一些核心点，Spring 中 bean 的生命周期，BeanFactory 与 FactoryBean 的区别等。所以这些前置知识花了特别多的时间去补。所幸，虽然补前置知识虽然时间长，但是性价比还是可以的。Dubbo 是依赖于Spring 的上下文环境的框架，其他依赖于 Spring 的框架也是相同的道理。Spring 的一些对外的扩展点，读过之后也会心中有数。
1、本篇主要是描述了 Dubbo 在 Spring 创建上下文的时候，是如何从创建，到能完整提供一个RPC调用能力的一些相关点。
2、由于源码比较多，直接贴断点也太过臃肿，所以仅仅贴一些关键点来概括整个流程。
3、本文是依赖于前面的 bbo 项目进行断点分析，项目结构可以参照这里。项目中 bbo 的配置方式是 xml 文件，所以本篇主要说 xml 配置方式。其他方式道理相同，并不是问题的关键点。
4、项目启动的是 bbo-user 服务，所以 UserService 为 bbo:service，OrderService 为 bbo:reference。
下图为Spring 启动时是如何加载 Dubbo 的，其中省略了大量过程，只保留了一些关键节点，省略的部分可以略微脑补一下。
整个流程的入口是 Spring 的 refresh 方法。每个方法都有比较深的调用栈。与 Dubbo 有关的入口是 refresh 中的 方法
这个方法是执行 beanFactory 的一些后处理操作，其核心流程为在Spring容器中找出实现了BeanFactoryPostProcessor接口的processor并执行。Spring容器会委托给的方法执行。
是比较核心的类，在这里我们关注一下这个类。它的作用是对项目中配置的类进行处理。具体处理可以分为几步：
在加载类信息时，spring 会去用各种方式扫到注册的 bean 信息。我们在 spring 中注册的 bean，逃不出这个方法的扫描方式。 核心方法是:
扫描之后，会将扫描到的 bean 注册到 beanDefinitionMap 中
首先是此处 org.springframework.beans.factory.xml.#parseBeanDefinitions，可以看出方法会以配置文件根节点起，遍历所有子节点。
其次是这里 org.springframework.beans.factory.xml.BeanDefinitionParserDelegate#parseCustomElement(org.w3c.dom.Element, org.springframework.beans.factory.config.BeanDefinition)， 此方法会通过解析出来的节点，获取对应的 Spring 的 namespaceUri ，进而获取对应的配置文件处理器。
此处 ele 参数实际值为 <bbo:service ... />，namespaceUri 为 http://code.alibabatech.com/schema/bbo
我们看一下 resolve 方法中的细节。因为这个方法内部才是 Dubbo 依赖于 Spring 的关键点。
此处的 NamespaceHandler 为 DubboNamespaceHandler，再创建结束之后，进行 init 初始化。
可以看到，DubboNamespaceHandler 在初始化的时候，会创建所有 bbo 标签对应的Config 类的 DubboBeanDefinitionParser。并将 DubboBeanDefinitionParser 和 对应的 bbo 标签类注册到 NamespaceHandlerSupport 的 parsers 中。
最后，会在 com.alibaba.bbo.config.spring.schema.DubboBeanDefinitionParser#parse(org.w3c.dom.Element, org.springframework.beans.factory.xml.ParserContext, java.lang.Class<?>, boolean) 方法中进行处理
Dubbo 服务比较特殊，beanDefinition 跟普通的 bean 不太一样。在向 beanDefinitionMap 注册时，普通的 beanDefinition 的 beanName 与 beanClass 是对应的；而 bbo 服务的 beanDefinition 的 beanName 是bbo 服务的名称，beanClass 为 bbo 对应的 Bean。
普通的 beanDefinition：
bbo 引用的服务的 beanDefinition：
这一步的核心流程是从 beanFactory 中获取所有的 ApplicationListener，然后注册到监听器集合中。它的关键点其实是 ServiceBean。因为 ServiceBean 是 ApplicationListener 的实现。
所以 beanFactory 中 ServiceBean 也会被注册到监听器集合中。项目中的 ServiceBean 的 beanClass 实际是 UserService。
这一步的核心点，主要是创建剩余的各类对象，并将其保存到 singletonObjects 中。其中关联的前置知识为 Spring 中 bean 的生命周期 。它的核心方法是：
org.springframework.beans.factory.support.#doCreateBean
它的具体流程为：
ps：此处并不是只有这一步才会跟 bean 生命周期相关，bean 生命周期贯穿在 refresh 的很多流程中，只要执行doGetBean 方法，都会走这个流程。此处仅仅借楼关联一下。
这一步的核心点，是通知所有的监听器上下文刷新结束的事件。在这一步执行时，会通知到 ServiceBean。
此处暴露的是 UserService。
Dubbo 的启动条件是完全依赖于 Spring 的启动流程，Spring 的启动流程中核心的点是 refresh 方法。所以只要搞懂 refresh 方法，其他的拓展框架流程也会明白。只不过关联的知识点太多了，还是需要时间的积累才能一点一点的搞懂。
如果本篇有描述不清，或者描述有误的地方，还望在下方留言，大家一起交流，一起学习，一起进步~