利用Spring中同名Bean相互覆盖的特性,定制平台的类内容。

欢迎和大家交流技术相关问题:

邮箱: jiangxinnju@163.com

博客园地址: http://www.cnblogs.com/jiangxinnju

GitHub地址: https://github.com/jiangxincode

知乎地址: https://www.zhihu.com/people/jiangxinnju

今天处理了一个问题,J2EE项目依赖了底层平台的功能,平台JAR包中配置了一个Bean,对应的实现类也在该平台JAR包中,由于Bean的配置不是懒加载的,所以在Tomcat容器启动时就会调用该Bean对应实现类中的init方法,但是该方法会对我们的业务产生副作用。现在想屏蔽这种副作用,我们肯定不能要求底层平台去修改代码,去除该Bean。所以考虑采取hack的方法解决。

我们在我们的项目目录中新建了一个*.service.xml文件,然后在该文件中重新配置了一下这个Bean,配置内容与平台JAR包中的配置相同,仅是把实现类修改为我们自己的类,这个类是一个空实现,也就避免了对业务产生副作用。然后在web.xml中的contextConfigLocation参数中,将我们自己的*.service.xml所在路径配置到平台JAR包中的Bean配置文件之后,也就是说我们的配置文件优先级更高。这样的话Spring容器在扫描过程中会扫描所有的配置文件,先扫描到平台JAR包中的配置文件,然后扫描到我们自定义的*.service.xml文件,发现同一个bean-id有两个配置,默认情况下会使用后面的覆盖前面的Bean定义,然后调用优先级更高的实现类进行初始化。

经过测试,结果和预期一致。

其实还应该有一个方法,就是不修改web.xml文件也不添加*.service.xml文件,而是在自己的项目中添加一个包路径和类名与JAR包中Bean的实现类完全相同的空实现类,然后将该项目打包到远程服务器上的时候一定要保证自己的JAR包比平台JAR包先加载到,有两个办法:如果两个JAR包在同一个目录下,要保证自己的JAR包的名称在所处的文件系统中的自动排序靠前;如果两个JAR包不在同一个目录,要保证自己的JAR包所在的目录靠前。当然这都是在没有特殊指定classpath的情况下,如果可以指定classpath,则灵活性更大。

当然虽然解决了底层平台副作用的问题,但是最好的方式是将自己的业务和平台解耦,尽量避免这种副作用问题。另外如果必须采用hack的方法解决问题,一定要在相关文件中写清注释。

上一篇:Lucene中几种常用的Query


下一篇:TCP是如何实现三次握手的?