[Struts2 Study Notes (5)] processing process and working principle of Struts2, struts2 Study Notes

[Struts2 Study Notes (5)] processing process and working principle of Struts2, struts2 Study Notes

(1) Struts2 processing process

(2) processing functions

1. strutsPrepareAndExecuteFilter is the core controller of Struts 2 Framework (after Struts 2.1.3, org. apache. struts2.dispatcher. filterDispatcher has been marked as obsolete). It is used to intercept all user requests specified by <url-pattern>/* </url-pattern>,

2. When a user's request arrives, the Filter filters the user's request. By default, if the path requested by the user does not contain a suffix or suffix ending with. action, the request will be transferred to the Struts 2 Framework for processing,

Otherwise, the Struts 2 Framework skips the processing of the request. When a request is transferred to the Struts 2 Framework for processing, it passes through a series of interceptors and then to the Action. Unlike Struts1,

Struts2 creates an Action for each user request, so the Action in Struts2 is thread-safe.

(3) Struts2 web. xml file

<? Xml version = "1.0" encoding = "UTF-8"?> <Web-app version = "2.5" xmlns = "http://java.sun.com/xml/ns/javaee" xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: schemaLocation = "http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"> <display-name> </display-name> <! -- Is the StrutsPrepareAndExecuteFilter class under org. apache. struts2.dispatcher. ng. filter in the struts2-core-2.1.8jar package --> <! -- Use org. apache. struts2.dispatcher. filterDispatcher has been marked as obsolete --> <filter-name> Struts2 </filter-name> <filter-class> org. apache. struts2.dispatcher. ng. filter. strutsPrepareAndExecuteFilter </filter-class> </filter> <filter-mapping> <filter-name> Struts2 </filter-name> <url-pattern>/* </url-pattern> </filter-mapping> <welcome-file-list> <welcome-file> index. jsp </welcome-file> </welcome-file-list> </web-app>

(4) Multiple struts configuration files are specified for the application in most applications. As the application scale increases, the number of actions in the system increases greatly, leading to struts. the xml configuration file becomes very bloated. To avoid struts. xml files are too large and bloated to improve struts. for the readability of xml files, we can set a struts. the xml configuration file is divided into multiple configuration files, and then in struts. the xml file contains other configuration files. The following struts. xml uses the <include> element to specify multiple configuration files:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE struts PUBLIC    "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"    "http://struts.apache.org/dtds/struts-2.0.dtd"><struts><include file="struts-user.xml"/><include file="struts-order.xml"/></struts>

In this way, we can add the Action of Struts 2 to multiple configuration files by module.



How Struts2 works, simply put

Struts2 Process
1. The client sends a request (the client initializes a request pointing to a Servlet container (such as Tomcat)
2. The request goes through a series of filters (such as ActionContextCleanUp and SiteMesh) and ActionContextCleanUp --> FilterDispatcher
3. FilterDispatcher uses ActionMapper to determine which Action the Request needs to call.
4. If ActionMapper decides to call an Action, FilterDispatcher will hand over the request processing to ActionProxy,
5. ActionProxy asks Struts configuration file (Struts. xml) through ConfigurationManager and finds the Action class to be called.
6. Create an ActionInvocation instance using ActionProxy
7. ActionInvocation calls the real Action. Of course, this involves the call of the relevant interceptor (interceptor)
8. After the Action is executed, ActionInvocation creates the Result and returns the Result. You can also perform some actions before returning the Result.

What is the struts2 processing process?

1. The client submits a request to the Servlet container (such as Tomcat ).
2. The request goes through a series of filters (such as ActionContextCleanUp (empty objects discarded by JVM and WEB containers)
3. The core controller is called. Ask ActionMapper to determine whether the request needs to call an Action.
4. If ActionMapper decides to call an Action, the core controller delegates control to ActionProxy (Note: JSP requests do not need to call Action)
5. ActionProxy queries the framework Configuration file (struts. xml) through Configuration Manager and finds the Action class to be called.
6. ActionProxy creates an ActionInvocation instance. (ActionInvocation is used to execute Action. The Interceptor is implemented in ActionInvocation)
7. ActionInvocation is responsible for calling Action. Before that, all configured interceptors will be called in turn.
8. After the Action is executed, ActionInvocation finds the corresponding returned results in struts. xml configuration based on the result code string.
9. The Interceptor is executed again.
10. The filter is executed again.