9月26,27和10月份的总的交通费共计44.4元，因为当时9月份的打卡记录发给我们时没有统计到9月26号以后的，所以行政这边让9月26号以后的交通费放在10月份进行报销，但是11月月初进行报销的时候我一直调休，所以没来得及报销，所以这3张报销单才一直拖到12月4号进行报销。望谅解！

9月最后几天和10月份的交通费没有报销，2012-11-13问过姜曼，说是放在11月份报。

 

 

 

 

spring研究点滴.txt

采用配置文件形式的手动装配的话，配置了几个bean，在spring容器启动的时候就会通过控制反转给你实例化几个bean。

 

3.采用伪类的方式，说白了就是把action也交给spring去管理。通过实际测试也证明了这一点：跟代码的时候就发现实际调用时候的action跟容器替我们实例化的aciton始终是同一个（aciton对象的id始终是同一个）。

4.其实控制反转和依赖注入真的较真起来，这两个是两个不同的概念，控制反转指的是bean的实例化的控制权由程序员转为spring容器了，不用程序员再关心在何时何地取new了，而依赖注入指的是bean之间的依赖关系靠什么方式来注入，可以靠手动装配（spring配置文件形式），也可以靠自动装配（注释的形式）。无论是手动装配还是自动装配，装配注入的都是单例的bean，因为要注入的bean都被spring容器管理起来了。

5.注入的顺序：通过实际的测试发现：spring容器替我们实例化bean的时候是按照配置文件的先后顺序进行实例化的，先配置的bean先进行实例化，后配置的bean后进行实例化。是先实例化后进行装配注入。

6.如果既有手动装配，又有自动装配，装配的先后顺序是什么？

采用了注释方式的自动装配的话，就无需采用配置文件形式的手动装配了。
至于既采用自动装配，又采用手动装配的话，先认哪一个？
7.如果手动装配的配置和自动装配的配置有冲突，比如手动装配配置的bean是一个实例，而自动装配配置的bean是另一个实例，最后真正装配起来的bean是哪一个实例？是不是与装配的先后顺序有关系？

 

 

 

 

 

 

配置环境经验总结.txt

伪类测试：
不采用伪类的方式，只通过struts的控制器就可以直接进入Action。但是Action里面其他的东西就需要到spring容器中去找了，如果找到还好说，找不到就会报null异常。

如果采用伪类的方式，就必须在spring的配置文件中配置Aciton，也就是说通过spring来实例化Action，那么就相应的必须通过spring来实例化Aciton里面的其他东西，要不然在调用的时候也会报相应的null异常。

其实真正的流程为：先通过spring容器去实例化这个Action（也就是先考虑伪类的方式），如果spring容器不能实例化这个Action（也就是说在spring容器中没有配置该Aciton的实例化配置），那么就考虑直接用strtus控制器去实例化这个Action，如果struts控制器也没办法实例化这个Aciton，那么就会报不能实例化该Aciton错误。如果能实例化的话就实例化，然后再赶紧到spring容器中去找其他的东西能不能实例化，如果配置了其他的东西的实例化配置，那么调用的时候就可以直接调用，如果没有配置相应的实例化配置的话，调用的时候就会抛出null异常。

其实也可以采用这样一种线条式思维来理解：就是不管struts实例化这个Action了没有，如果web环境中引入了spring容器，web容器总是要到spring容器中去实例化一遍这个Action，这就导致即使struts的控制器已经替我们实例化了这个Action，过一遍spring容器，又会把原来实例化的那个Aciton给覆盖掉，如果新实例化的这个Action中的其他东西没有被实例化，那么又会报null异常。

 

分发测试   -*.action   -{1}.action

 

采用Hibernate 工具生成的 User111 is no mapped
把这里环境里的User实体抄下来，回房间在笔记本环境里试试