最近开发项目遇到一个问题。
错误日志跟踪发现是spring IOC报出来的错误
org.springframework.beans.factory.BeanCreationException: Error creating bean with name ****: Injection of autowired dependencies failed;nested exception is ......nested exception is org.hibernate.MappingException: Could not get constructor for org.hibernate.persister.entity.SingleTableEntityPersister
竟然是hibernate的注入问题,由于代码并没有添加新的实体,也找到任何有注释问题的service,dao,entitiy类。无奈下只能通过svn对比代码差异。
结果发现由于开发需求某开发新人在某个表映射实体中添加了一个方法public double getAvg(),其方法内容就是针对此实体的某些。由于本人并没有参考过hibernate orm的最新源码,对其原理仅仅停留于曾经远古年代的XML经验--没有在XML中配置的hibernate不会对其进行映射。推论到目前的注解,没有注解的应当也不会被映射。
由于没有找到其他原因,也只能对此方法下手,从代码中注释了此方法和相关代码,发现程序正常跑了,catch!!!
-----------------------------------------------至此罪魁祸首代码已经找到---------------------------------------------------- 既然找到问题代码,hibernate的原因也基本被排除,那么出错的责任应在spring IOC。将该方法名改为avg() 发现程序可以正常运行,方法名由get变为set,程序也可正常运行,删除该改方法添加属性avg发现程序同样正常,最后保留get情况下添加了set方法,程序依然正常。
这让我对之前的spring认识有了变更,入门时师傅告诉我spring是根据属性去查找get/set方法进行注入。从上面的表现上来看其顺序应该是获取所有的get方法,查找对应的set方法,不存在就报错。注入原理与属性无关!
------------------------------------------------------------总结-------------------------------------------------------------------
![](/qrcode.jpg)
经此一役,让我收获最大的是对于项目管理上要严格把控代码质量,对所有源码在经过多层测试和审核。在技术上加强新人培训,杜绝简单问题的出现。同时也不应迷信于前人的经验和方法,做到谨慎质疑,大胆证实。最后本人从事的是业务架构设计对于技术了解一般,如有技术错误请指出。