Struts 2 Interceptors Example

In this example you will see how the interceptors are invoked both before and after the execution of the action and how the results are rendered back to the user. Let's understand this with the help of the following diagram.

The following actions happen in a sequence when a request comes to the Struts 2 framework.

· Framework first finds which Action class to invoke for this request and discovers the interceptors associated with the action mapping.

· Now the Framework creates an instance of ActionInvocation and calls its invoke() method. At this point the Frameworks hands the control over to the ActionInvocation for further processing of the request.

· ActionInvocation is the one which encapsulates the action and the associated intercteptors. ActionInvocation knows in which sequence the interceptors should be invoked.

· ActionInvocation now invokes the intercept() method of the first interceptor in the stack. We will understand this with the help of an example. Our example is very simple it uses only one interceptor for logging details.

· The LoggingInterceptor's intercept() method contains the following code.

view source

print ?

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;

}

· As you can see, first the logMessage() method is called and the message is logged, this is the pre processing done by the logger interceptor, then the invoke() method of the ActionInvocation is again called, this time the ActionInvocation will call the next intercetor in the stack and this cycle will continue till the last interceptor in the stack.

· 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.

· 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.

We get the following benefits by using the interceptors.

· Extremely flexiable.

· Cleaner and focused Action classes.

· Provides code readability and code reuse.

· Testing process becomes easier.

· We can add only the interceptors we need to the stack and customising the action processing for each request.

Now lets see the flow of the example. In the index.jsp page we forward the request to the "TestLogger" URL.

view source

print ?