最近發現dubbo的小
bug，順便整理了一下dubbo中的filter呼叫順序及如何確定的。
服務提供方的過濾器被呼叫順序：
echofilter->classloaderfilter->genericfilter->contextfilter->(這4個是在**中指定的)
exceptionfilter-> timeoutfilter ->monitorfilter-> tracefilter
服務消費方的過濾器順序：
consumercontextfilter->futurefilter->monitorfilter
負責載入過濾器的類
這個順序和spi配置檔案的順序並不一致。那麼是什麼決定了filter的順序呢？
通過檢視源**可以看到，在初始化filter時，有乙個對所有的過濾器排序的過程，其使用的比較類是activatecomparator。在這個類中，可以看到，是使用filter中的activate類進行排序的。而activate註解中，有乙個order的屬性，這個屬性指定了filter在chain中的順序。
通過檢視echofilter的activate屬性，可以看到其order = -110000，而classloaderfilter的order=-30000,因此可以斷定，order值越小，其越位於呼叫端的最頂層。那麼當order相同時（都沒有設定時），又是根據什麼排序的呢？
collections.sort演算法
從其說明文件可以看出，這個演算法是乙個穩定的排序演算法，如果兩個值相同，不會改變其前後順序。並且從其文件可以看出，其所使用的是乙個修改過的歸併排序演算法。
但是activate的compare方法故意將兩個相同的order類弄成了不同，導致排序有些變化。造成了最終上述順序。
所以導致原來配置檔案中的位置為：
1、monitor
2、trace
3、exception
4、timeout
排序後變成了
1、exception
2、timeout
3、monitor
4、trace
Dubbo的全域性Filter配置
前言 之前也寫過dubbo的filter的文章,後來和同事也有過交流,才發生自己對dubbo的filter的機制,還是存在一些誤解,尤其是自定義filter的定位,不是那麼清晰.本文主要是補充一下,自定義的filter如何成為全域性filter,或者說,它不需要在bean的定義申明中指定filter...
Servlet 中 Filter的執行順序
servletfilter 中 dofilter 方法將呼叫過濾鏈中的下乙個過濾方法，當下乙個方法完成後，控制權將重新回到呼叫改方法的上級過濾器中。類似於遞迴呼叫。另外，如果過濾器的dofilter 方法中 寫出了定製的響應後，方法無需連到其它過濾器就能返回。這就是過濾器阻止後續處理的方法。publ...
web中filter的載入順序
web.xml載入過程 步驟 1.啟動web專案的時候,容器 如 tomcat 會去讀它的配置檔案web.xml.讀兩個節點 和 2.緊接著,容器建立乙個servletcontext 上下文 這個web專案所有部分都將共享這個上下文.3.容器將轉化為鍵值對,並交給servletcontext.4.容...