The listener listener is used to load the configuration, and the listener listener is typically used in struts+spring+hibernate projects. As follows
<listener> <listener-class>org.springframework.web.context.contextloaderlistener</ Listener-class> </listener>
Spring creates a webapplicationcontext context, called a container, which is stored in ServletContext, and key is the value of Webapplicationcontext.root_web_application_context_attribute.
the context object can be fetched using the tool class provided by spring: Webapplicationcontextutils.getwebapplicationcontext (servletcontext);
Dispatcherservlet is a servlet,multiple can be configured at the same time, each dispatcherservlet has its own context object (Webapplicationcontext), called a child context (sub-container), the child context can access the contents of the parent context, However, the parent context cannot access the content in the child context. It is also stored in the ServletContext, and key is the "Org.springframework.web.servlet.FrameworkServlet.CONTEXT" +servlet name. when awhen the request object is generated, the Child context object (Webapplicationcontext) is saved in the Request object, and key is DispatcherServlet.class.getName () + ". CONTEXT ".
You can use the tool class to remove the context object: Requestcontextutils.getwebapplicationcontext (request);
Description: Spring does not restrict us, and must use a parent-child context. We can decide for ourselves how to use it.
scheme One, traditional type:
The parent context container holds the bean for the data source, the service layer, the DAO layer, and the transaction.
The bean that holds the MVC-related action in the child context container.
transactions are controlled at the service level.
because the parent context container cannot access the content in the child context container, the transaction's bean cannot access the contents of the child context container in the parent context container, and the action in the sub-context container cannot be AOP (transactional).
of course, as a "traditional" scheme, there is no need to do this.
Scenario Two, radical:
The Java world's "interface-oriented programming" idea is correct, but in the deletion and modification of the main business system, DAO layer Interface, DAO Layer implementation class, service layer interface, service layer implementation class, action parent class, action. Plus a multitude of O (vo\po\bo) and JSP pages. Write a small function 7, 8 classes are written out. Developers say I just want to contact private work, and php,asp rob a job, but I am a Java programmer. The best result is that large projects can do well and small projects can be done quickly. So the "aggressive" scenario arises-----No interface, no service layer, and no large number of O (Vo\po\bo). What layer does the service level transaction control? Had to rise the action layer.
This article does not want to say that this is not the right idea, and I would say that spring does not restrict you from doing so.
because of the parent-child context, you will not be able to achieve this goal. The solution is to use only the child context container, not the parent context container. So the data source, the service layer, the DAO layer, the transaction bean, and the action bean are all placed in the child context container. Can be implemented, the transaction (annotation transaction) is working properly. That's enough to be radical.
Summary: Do not use the listener listener to load the spring configuration file, only use Dispatcherservlet to load the spring configuration, not the parent-child context, using only one dispatcherservlet, things are simple, There's nothing wrong with the trouble.
