如果你使用了listener监听器来加载配置，一般在struts+spring+hibernate的项目中都是使用listener监听器的。如下
java代码
<listener> <listener-class>org.springframework.web.context.contextloaderlistener</listener-class> </listener>
spring会创建一个webapplicationcontext上下文，称为父上下文（父容器） ，保存在 servletcontext中，key是webapplicationcontext.root_web_application_context_attribute的值。
可以使用spring提供的工具类取出上下文对象：webapplicationcontextutils.getwebapplicationcontext(servletcontext);
dispatcherservlet是一个servlet,可以同时配置多个，每个 dispatcherservlet有一个自己的上下文对象（webapplicationcontext），称为子上下文（子容器），子上下文可以访问父上下文中的内容，但父上下文不能访问子上下文中的内容。 它也保存在 servletcontext中，key是"org.springframework.web.servlet.frameworkservlet.context"+servlet名称。
当一个request对象产生时，会把这个子上下文对象（webapplicationcontext）保存在request对象中，key是dispatcherservlet.class.getname() + ".context"。
可以使用工具类取出上下文对象：requestcontextutils.getwebapplicationcontext(request);
说明 ：spring 并没有限制我们，必须使用父子上下文。我们可以自己决定如何使用。
方案一，传统型：
父上下文容器中保存数据源、服务层、dao层、事务的bean。
子上下文容器中保存mvc相关的action的bean.
事务控制在服务层。
由于父上下文容器不能访问子上下文容器中内容，事务的bean在父上下文容器中，无法访问子上下文容器中内容，就无法对子上下文容器中action进行aop（事务）。
当然，做为“传统型”方案，也没有必要这要做。
方案二，激进型：
java世界的“面向接口编程”的思想是正确的，但在增删改查为主业务的系统里，dao层接口，dao层实现类，service层接口，service层实现类，action父类，action。再加上众多的o(vo\po\bo)和jsp页面。写一个小功能 7、8个类就写出来了。 开发者说我就是想接点私活儿，和php，asp抢抢饭碗，但我又是java程序员。最好的结果是大项目能做好，小项目能做快。所以“激进型”方案就出现了-----没有接口、没有service层、还可以没有众多的o(vo\po\bo)。那没有service层事务控制在哪一层？只好上升的action层。
本文不想说这是不是正确的思想，我想说的是spring不会限制你这样做。
由于有了父子上下文，你将无法实现这一目标。解决方案是只使用子上下文容器，不要父上下文容器 。所以数据源、服务层、dao层、事务的bean、action的bean都放在子上下文容器中。就可以实现了，事务（注解事务）就正常工作了。这样才够激进。
总结：不使用listener监听器来加载spring的配置文件，只使用dispatcherservlet来加载spring的配置，不要父子上下文，只使用一个dispatcherservlet，事情就简单了，什么麻烦事儿也没有了。
java--大项目能做好--按传统方式做，规规矩矩的做，好扩展，好维护。
java--小项目能做快--按激进方式做，一周时间就可以出一个版本，先上线接受市场(用户)的反馈，再改进，再反馈，时间就是生命(成本)。
如对本文有疑问， 点击进行留言回复！！
Xshell连接本地VMware Linux虚拟机的简单配置（NAT模式）
我要评论
网友评论