① 日誌實體類信息包括哪些內容
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 方法，其他的拓展框架流程也會明白。只不過關聯的知識點太多了，還是需要時間的積累才能一點一點的搞懂。
如果本篇有描述不清，或者描述有誤的地方，還望在下方留言，大家一起交流，一起學習，一起進步~