折腾了两天,总算还是解决了,调试进去看过一些源码,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要先了,结果自然就不一样了(此处只是打比方,当然实际上没那么简单,只为容易理解)