關於dubbo+shiro導致dubbo無法注入的問題解決方案
折騰了兩天,總算還是解決了,除錯進去看過一些原始碼,shiro的org.apache.shiro.spring.web.ShiroFilterFactoryBean會實現spring的bean注入攔截器,當shirofilter開始注入成功後就會攔截到每一個spring將執行注入的操作,然而這個攔截器也沒做什麼動作,就是判斷了一下是否是一個filter的實現類,不是就轉發了.
以上程式碼只是簡述,但是終究問題出在只要你給filter配置了securityManager就會導致dubbo的service無法注入,然而securityManager涉及程式碼太多了,由於時間有限,也沒仔細去除錯,畢竟是shiro的核心嘛...
至於解決方案的話,其實很簡單,dubbo不要用註解掃描@Reference(version="1.0"),應當使用dubbo的配置檔案
示例如下:
<!-- 消費方應用名，用於計算依賴關係，不是匹配條件，不要與提供方一樣 --> <dubbo:application name="base-admin" /> <!-- 使用multicast廣播註冊中心暴露發現服務地址 --> <dubbo:registry protocol="zookeeper" address="127.0.0.1:2181" /> <!-- <dubbo:registry protocol="zookeeper" address="192.168.2.18:2181" /> --> <!-- 生成遠端服務代理，可以和本地bean一樣使用demoService --> <!-- 不使用dubbo的註解掃描<dubbo:annotation/> --> <!-- ACT --> <dubbo:reference id="ActAttendService" interface="com.cykj.base.core.provide.act.ActAttendService" timeout="6000" check="false" version="1.0"/> <dubbo:reference id="ActGiftService" interface="com.cykj.base.core.provide.act.ActGiftService" timeout="6000" check="false" version="1.0"/> <dubbo:reference id="ActGiftMasterService" interface="com.cykj.base.core.provide.act.ActGiftMasterService" timeout="6000" check="false" version="1.0"/>
而service那邊直接使用autowired,注意一點,這裡是dubbo的消費者,提供者可以繼續使用註解掃描的方式
最後附上個人的一點簡單分析:
估計是跟AOP事務與dubbo衝突類似,shiro會先代理所有類,導致dubbo掃描時獲取到的類並不是DubboService,導致dubbo無法識別
(以下可能性不大,是之前寫的,想了下還是不刪除了,僅供參考)
因為spring的讀取配置檔案是一個一個掃描的,若掃描到是物件就會直接例項化(未配置lazy-init的情況下),若掃描到到annotation這種或者scan這種則會先做記錄.
那麼如果使用註解掃描方式的話,就會導致shiro的filter比dubbo的掃描先執行,那麼shiro或許會代理到dubbo的注入,或攔截dubbo產生的協議?(先大概這樣猜測,有深入研究的還請指正),但如果使用配置檔案的話,spring掃描到dubbo的配置就立馬先例項化了這些物件的代理,這樣dubbo的例項化就比shiro的filter要先了,結果自然就不一樣了(此處只是打比方,當然實際上沒那麼簡單,只為容易理解)