关于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要先了,结果自然就不一样了(此处只是打比方,当然实际上没那么简单,只为容易理解)