son of bitch! 该死的sakai配备
son of bitch! 该死的sakai配置
实在是忍不住的郁闷啊，累积八个多小时的不间断调试，但问题也算最终解决了。
本文说说两个问题，一是，结论：在sakai中configuration-bundles-2.6.2.jar\org\sakaiproject\config中有一个配置文件，里面的值会覆盖组件目录下的xml文件的配置。
二是，谈sakai（其实是spring）启动时的Property注入。
下面堆栈反映的是从tomcat加载开始，到找到我们的目标字段cacheMinutes
从SakaiApplicationContext.refresh开始分析。
在AbstractApplicationContext中
从注释中知道，这一步是要调用注册到context中的bean。
再次跟进：
那么这时候的getBeanFactoryPostProcessors()的所有值有下面这些：
跟进到PropertyResourceConfigurer（继承自BeanFactoryPostProcessor）中，有：
注意上面的mergeProperties():
其中的localProperties为动态注入。
然后就是porcessPropertise操作了，对bean的字段赋值，出现在这里的Property会覆盖xml配置文件中的值。
就是这么简单--事后诸葛亮。但为什么我花了那么的多时间 来解决这个问题。那么我是怎么调试的呢。
在引用Properties的地方下条件断点，然后慢慢看，慢慢理。
比如我知道我需要找的属性cacheMinutes在org.sakaiproject.authz.api.SecurityService中，那么我可以在DefaultListableBeanFactory中的getBeanDefinition下条件断点beanName.equals("org.sakaiproject.authz.api.SecurityService")
我之所以费了这么多时间，一是对spring处理Properties不熟悉，二是为了偷懒，花了大量时间寻找调试技巧，比如变量值变化时中断。
实在是忍不住的郁闷啊，累积八个多小时的不间断调试，但问题也算最终解决了。
本文说说两个问题，一是，结论：在sakai中configuration-bundles-2.6.2.jar\org\sakaiproject\config中有一个配置文件，里面的值会覆盖组件目录下的xml文件的配置。
二是，谈sakai（其实是spring）启动时的Property注入。
下面堆栈反映的是从tomcat加载开始，到找到我们的目标字段cacheMinutes
从SakaiApplicationContext.refresh开始分析。
在AbstractApplicationContext中
从注释中知道，这一步是要调用注册到context中的bean。
再次跟进：
那么这时候的getBeanFactoryPostProcessors()的所有值有下面这些：
跟进到PropertyResourceConfigurer（继承自BeanFactoryPostProcessor）中，有：
注意上面的mergeProperties():
其中的localProperties为动态注入。
然后就是porcessPropertise操作了，对bean的字段赋值，出现在这里的Property会覆盖xml配置文件中的值。
就是这么简单--事后诸葛亮。但为什么我花了那么的多时间 来解决这个问题。那么我是怎么调试的呢。
在引用Properties的地方下条件断点，然后慢慢看，慢慢理。
比如我知道我需要找的属性cacheMinutes在org.sakaiproject.authz.api.SecurityService中，那么我可以在DefaultListableBeanFactory中的getBeanDefinition下条件断点beanName.equals("org.sakaiproject.authz.api.SecurityService")
我之所以费了这么多时间，一是对spring处理Properties不熟悉，二是为了偷懒，花了大量时间寻找调试技巧，比如变量值变化时中断。