A study of Webapplicationcontext in spring

A study of Webapplicationcontext in spring

ApplicationContext is the core of spring, which we usually interpret as context, I want to use "container" to express it easier to understand some, ApplicationContext is "the container of Application": P, Spring puts the bean in this container and, when needed, takes it out with the Getbean method, although I have not seen the source code of this part, but I think it should be a map-like structure.
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>

<!--OR Use the Contextloaderservlet INSTEAD of the LISTENER
<servlet>
<servlet-name>context</servlet-name>
<servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
-

As can be seen, there are two ways, one is to use Contextloaderlistener this listerner, the other is Contextloaderservlet this servlet, Both of these methods initialize the Webapplicationcontext when the Web App is launched, and I personally think that Listerner is better than the servlet because Listerner listens to the start and end of the application, And the servlet has to be started slightly delayed some, if at this time to do some business operations, the pre-and post-activation sequence is affected.

What exactly did you do in Contextloaderlistener and Contextloaderservlet?
Take 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 being 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 original Contextloader 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 Webapplicationcontext's key 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.

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 that is loaded at struts startup and, for action, can be managed like a bean, in struts-config.x The configuration of the action in ML 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 type becomes org.springframework.web.struts.DelegatingActionProxy, and then we need to build action-servlet.xml such a file, Action-servlet.xml conform to spring's SPRING-BEANS.DTD standard, defined in the inside like the following
<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:)

Spring is a very powerful framework, I hope you in the process of continuous in-depth, to understand its more features, I am here to initiate, what is wrong, please point out.

Study of Webapplicationcontext in spring