Struts 2 Framework = Struts 1 + webwork
Request Lifecycle in Struts 2 applications
User Sends request: User sends a request to the server for some resource.
FilterDispatcher determines the appropriate action: The FilterDispatcher looks at the request and then determines the appropriate Action.
Interceptors are applied: Interceptors configured for applying the common functionality such as workflow, validation, file upload etc. are automatically applied to the request.
Execution of Action: Then the action method is executed to perform the database related operations like storing or retrieving data from the database.
Output rendering: Then the Result renders the output.
Return of Request: Then the request returns through the interceptors in the reverse order. The returning request allows us to perform the clean-up or additional processing.
Display the result to user: Finally the control is returned to the servlet container, which sends the output to the user browser.
The Struts 2 Framework allows us to define exception handlers and interceptors.
Exception handlers allows us to define the exception handling procedure on global and local basis. Framework catches the exception and then displays the page of our choice with appropriate message and exception details.
The Interceptors are used to specify the "request-processing lifecycle" for an action. Interceptors are configured to apply the common functionality like workflow, validation etc.. to the request.
Struts 2 Architecture
Struts 2 is a very elegant and flexible front controller framework based on many standard technologies like Java Filters, Java Beans, ResourceBundles, XML etc.
For the Model, the framework can use any data access technologies like JDBC, EJB, Hibernate etc and for the View, the framework can be integrated with JSP, JTL, JSF, Jakarta Velocity Engine, Templates, PDF, XSLT etc.
The following diagram depicts the architecture of Struts 2 Framework and also shows the the initial request goes to the servlet container such as tomcat, which is then passed through standard filer chain.
The filter chain includes:
The ActionContextCleanUp filter is optional and it is useful when integration has to be done with other technologies like SiteMash Plugin.
Next the FilterDispatch is called, which in turn uses the ActionMapper to determine whether to invoke an Action or not. If the action is required to be invoked, the FilterDispatcher delegates the control to the ActionProxy.
The ActionProxy takes help from Configuration Files manager, which is initialized from the struts.xml.
Then the ActionProxy creates an ActionInvocation, which implements the command pattern. The
ActionInvocation process invokes the Interceptors (if configured) and then invokes the action. The the ActionInvocation looks for proper result. Then the result is executed, which involves the rendering of JSP or templates.
Then the Interceptors are executed again in reverse order. Finally the response returns through the filters configured in web.xml file. If the ActionContextCleanUp filter is configured, the FilterDispatcher does not clean the ThreadLocal ActionContext. If the ActionContextCleanUp filter is not present then the FilterDispatcher will cleanup all the ThreadLocals present.