ApplicationContext is a treasure chest.
ApplicationContext is the core of spring, the context we usually interpret as a contextual environment, I want to use "container" to express it easier to understand some, ApplicationContext is "Application container": Spring puts the bean in this container and, when needed, takes the Getbean method out.
How Webapplicationcontext was born.
In the Web app, we'll use Webapplicationcontext,webapplicationcontext to inherit from ApplicationContext, let's look at the Web application, How to initialize Webapplicationcontext?
defined in Web. xml:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
What is webapplicationcontext from medical perspective when he was born?
So what exactly did you do in Contextloaderlistener and Contextloaderservlet?
Taking Contextloaderlistener as an example, we can see
public void contextinitialized (Servletcontextevent event) {
This.contextloader = Createcontextloader ();
This.contextLoader.initWebApplicationContext (Event.getservletcontext ());
}
Protected Contextloader Createcontextloader () {
return new Contextloader ();
}
Contextloader is a tool class used to initialize Webapplicationcontext, the main method is Initwebapplicationcontext, We continue to track initwebapplicationcontext this method (specific code I do not post, we can see the source in spring), we found that the originalContextloader is to put Webapplicationcontext (Xmlwebapplicationcontext is the default implementation class) in the ServletContext, ServletContext is also a " Container "is also a map-like structure, and the key to Webapplicationcontext in ServletContext is Webapplicationcontext.root_web_application_ Context_attribute, if we want to use webapplicationcontext, we need to take the ServletContext out, Spring provides a webapplicationcontextutils class, Can be easily removed webapplicationcontext, as long as the ServletContext incoming on it.
the issues that spring integrates with struts are:
Above we introduce the principle of webapplicationcontext initialization in the servlet container, the general Web application can be used easily, but with the wide application of struts, it is a problem to put struts and spring all together. , spring itself provides the relevant classes of struts, The main use of the org.springframework.web.struts.ActionSupport, we just have to inherit their action from Actionsupport, is to call Actionsupport Getwebapplicationco The ntext () method takes out the Webapplicationcontext, but so in action, where the business logic needs to be getbean, it doesn't look concise enough, so spring provides another way With Org.springframework.web.struts.ContextLoaderPlugIn, this is a struts plug, loaded at struts startup, for action, it can be managed like a bean. The configuration of the action in Struts-config.xml changes to look like this
<action attribute= "aform" name= "Aform" path= "/aaction" scope= "Request" type= " Org.springframework.web.struts.DelegatingActionProxy ">
<forward name= "forward" path= "forward.jsp"/>
</action>
Note that the type becomes org.springframework.web.struts.DelegatingActionProxy, and then we need to build action-servlet.xml such a file, action-servlet.xml conforms to the SPR ING's SPRING-BEANS.DTD standard, defined in the inside like below
<bean name= "/aaction" class= "Com.web.action.Aaction" singleton= "false" >
<property name= "Businessservice" >
<ref bean= "Businessservice"/>
</property>
</bean>
Com.web.action.Aaction is the implementation class for action, Businessservice is the business logic that is needed, and spring injects businessservice into the action, and in action just write Businessservice ge The T and set methods are OK, and the action Bean is singleton= "false", that is, a new instance is created each time, which also solves the thread synchronization problem of action in struts, when the user does "/aaction" HTTP request (which should be "/aaction.do", of course), Struts will find the corresponding class of this action Org.springframework.web.struts.delegatingactionproxy,delegatingactionproxy is a proxy class, it will go to find Action-servlet.x ml file "/aaction" corresponds to the real implementation class, and then instantiate it, while injecting the required business object, and then execute the action method.
Using the Contextloaderplugin, it becomes like this in the Struts-config.xml configuration
<plug-in classname= "Org.springframework.web.struts.ContextLoaderPlugIn" >
<set-property property= "contextconfiglocation" value= "/web-inf/applicationcontext.xml,/web-inf/ Action-servlet.xml "/>
</plug-in>
In Web. XML, Contextloaderlistener or Contextloaderservlet are no longer required.
Speaking here do not know whether we will have such a problem, if we use Contextloaderplugin, if some of our programs are out of the struts action environment, we how to deal with, such as we want to customize the tag library, in the tag library, We need to invoke the business layer logic objects that spring manages, and we are in trouble because only the business logic is injected dynamically in the action, and other we don't seem to get the webapplicationcontext of spring.
Don't worry, we still look at the source code of Contextloaderplugin (source no longer posted), we can find that The original contextloaderplugin is still put Webapplicationcontext in ServletContext, but this key is not quite the same, This key value is Contextloaderplugin.servlet_context_prefix+moduleconfig.getprefix () (see the source code for details), this is OK, We know where the webapplicationcontext is, as long as we can get the ServletContext in the Web application, we can take webapplicationcontext:)
What does Applicationcontex do?