"In the last tutorial we discussed about the life cycle of the interceptors.In this part we will learn about controlling the behavior of interceptors.

 Like Servlet or Filter in the Servlet specification, there are provision  of passing parameters. The benefits are enormous; we can configure or control the behavior of the Servlets and Filters without even touching the code.Just modify the parameters from the deployment descriptor web.xml, and you are done.

The same comes with interceptors, but little differently.
 
Two different ways that we can control the behavior of the interceptors from within the strtus.xml  and those are

  1.  Passing parameters to the interceptors
  2.  Method filtering
     

 Lets take the first one:

 Unlike Filters and Servlets, parameter passing through param-name and param-value from init-param tag and then accepting values by reading it in init() method by getInitParameter(). The interceptor however , gives you a better way; no need of any method calling to read the values from the deployment descriptor (struts.xml). Just provide getters and setters of the instance field and then you are ready ,  even automatic conversion of passed value to appropriate type in the instance field of the interceptor is taken care of by the framework.
 Easy, it not it ?
 
 Lets take the clear cache interceptor from the earlier tutorial and implement parameter passing.
 
 Here is the tweak in the story of the cache interceptor ; it does help us clearing the cache, but as we know if this interceptor is in the stack of interceptors ( more on this later)  used as default stack then  you can't really control or can not prevent executing of this interceptor and eventually applying to all the actions and clearing cache in all JSPs. There can be a situation where you might want to cache the JSP/HTML renderings. However you can create another stack of interceptors where in clean cache interceptor in not placed. And you can use this named stack of interceptors in the action elements where in you want caching to happen. But this is not the solution. Parameterized interceptors are to the rescue.

Lets modify our interceptor class from earlier tutorial to as follows.
 

package com.bullraider.apps.interceptors;

import javax.servlet.http.HttpServletResponse;
import org.apache.struts2.StrutsStatics;

import com.opensymphony.xwork2.ActionContext;
import com.opensymphony.xwork2.ActionInvocation;
import com.opensymphony.xwork2.interceptor.AbstractInterceptor;

public class ClearCacheInterceptor  extends AbstractInterceptor{

 private boolean cleanCache;
 @Override
 public String intercept(ActionInvocation invocation) throws Exception {
  ActionContext context=(ActionContext)invocation.getInvocationContext();
  System.out.println("cleanCache is: "+cleanCache);
  if(cleanCache){
  HttpServletResponse response=(HttpServletResponse)context.get(StrutsStatics.HTTP_RESPONSE);
  response.setHeader("Cache-Control", "no-cache");
  response.setHeader("Pragma", "no-cache");
  response.setDateHeader("Expires", 0);
  }
  String result=invocation.invoke();
  return result;
 }
 public boolean isCleanCache() {
  return cleanCache;
 }
 public void setCleanCache(boolean cleanCache) {
  this.cleanCache = cleanCache;
 } 
}

 

What extra we did is,  provided a boolean field and the corresponding setters and getters. The name of the field is what we will use to to pass the value from struts.xml.Neither getInitParameter() required to fetch nor any type conversion is required(from string to Boolean,since interceptor framework takes care of this ),unlike Servlet specification.Once the interceptor is created the instance field is ready to use,unless there is any error in conversion. Lets have a look at the struts.xml file

<!DOCTYPE struts PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"
"http://struts.apache.org/dtds/struts-2.0.dtd">
<struts>
 <package name="test" extends="struts-default" >
  <interceptors>
   <interceptor name="clean-cache"
    class="com.bullraider.apps.interceptors.ClearCacheInterceptor" />
  </interceptors>
  <action name="Test" class="com.bullraider.apps.actions.TestAction" >
   <interceptor-ref name="clean-cache" >
   <param name="cleanCache">true</param>
   </interceptor-ref>
   <result name="success">/success.jsp</result>
  </action>
  <action name="Fest" class="com.bullraider.apps.actions.FestAction" >
   <interceptor-ref name="clean-cache" >
   <param name="cleanCache">false</param>
   </interceptor-ref>
   <result name="success">/success.jsp</result>
  </action>
 </package>
</struts>

 

 There are two actions FestAction for which the interceptor's parameter is configured to false and for TestAction it is set to true;which will allow caching and disallow caching in the corresponding JSPs, respectively,with the help of intercept() method at line 21 in the interceptor class which decides on the boolean field "cleanCache" and executes appropriate code. The print statements should help you indentify the flow.

Download the parameterizinginterceptor.war

In the next tutorial we will learn about the method filtering.