Struts2 Architecture

Struts2 Architecture

FilterDispatcher
FilterDispatch is 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 FilterDispatcher(org.apache.struts2.dispatcher.FilterDispatcher) is used in the early Struts2 development, and it's deprecated since Struts 2.1.3.
If you are using Struts version >= 2.1.3, it's always recommended to upgrade the new filter class - StrutsPrepareAndExecuteFilter (org.apache.struts2.dispatcher.ng.filter.StutsPrepareAndExecuteFilter).
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.
ActionInvocation
The ActionInvocation finds which Action class to invoke for this request and discovers the interceptors associated with the action mapping. ActionInvocation is the one which encapsulates the action and the associated intercteptors. ActionInvocation knows in which sequence the interceptors should be invoked.

Interceptor
ActionInvocation now invokes the intercept() method of the first interceptor in the stack. After execution of first interceptor Invoke() will check for the next interceptor.
Action
After the execution of all the interceptors the action class will be invoked. Finally a result string will be returned and the corresponding view will be rendered. This is the normal flow of events.
	public String intercept(ActionInvocation invocation) throws Exception
	{
		//Pre processing
		logMessage(invocation, START_MESSAGE);
		String result = invocation.invoke();
		//Post processing
		logMessage(invocation, FINISH_MESSAGE);
		return result;
	}
But what if an validation error occurs, in this case the request processing will be stopped. No further interceptors will be invoked. Action will not be executed.
The control flow changes, now the interceptors executed so far will be invoked in the reverse order to do the post processing if any and finally the result will be rendered to the user.

Let's come back to the normal flow. In our case the logger interceptor is the only interceptor in the stack, so after logging the "START_MESSAGE", the ActionInvocation's invoke() method will invoke the action. Our action simply returns "success", then again the logger interceptor will be invoked to do the post processing, this time the "FINISH_MESSAGE" is logged and the result is returned. Based on the result the corresponding view will be rendered to the user.