1. A filter as the name suggests is a Java class executed by the servlet container for each incoming http request and for each http response. This way, is possible to manage HTTP incoming requests before them reach the resource, such as a JSP page, a servlet or a simple static page; in the same way is possible to manage HTTP outbound response after resource execution.
  2. The filter runs in the web container so its definition will also be contained in the web.xml file
  3. filer include three main methods:
    • init: executed to initialize filter using init-param element in filter definition
    • doFilter: executed for all HTTP incoming request that satisfy “url-pattern”
    • release resources used by the filter

web.xml

<filter>
    <filter-name>CORSFilter</filter-name>
    <filter-class>com.listfeeds.components.CORSFilter</filter-class>
    <init-param>
        <param-name>fake-param</param-name>
        <param-value>fake-param-value</param-value>
    </init-param>
</filter>
<filter-mapping>
    <filter-name>CORSFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

TestFilter.java

package com.listfeeds.filters;

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletResponse;
import org.springframework.stereotype.Component;

public class TestFilter implements Filter {

    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {

        HttpServletResponse response = (HttpServletResponse) res;
        response.setHeader("Access-Control-Allow-Origin", "*");
        response.setHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE");
        response.setHeader("Access-Control-Max-Age", "3600");
        response.setHeader("Access-Control-Allow-Headers", "x-requested-with");
        chain.doFilter(req, res);
    }

    public void init(FilterConfig filterConfig) {}

    public void destroy() {}

}

Filters can perform many different types of functions.

  1. Authentication-Blocking requests based on user identity.
  2. Logging and auditing-Tracking users of a web application.
  3. Image conversion-Scaling maps
  4. Data compression-Making downloads smaller
  5. Localization-Targeting the request and response to a particular locale

Request Filters can:

  1. perform security checks
  2. reformat request headers or bodies
  3. audit or log requests

Response Filters can:

  1. Compress the response stream
  2. Append or alter the response stream
  3. Create a different response altogether
  1. Spring Interceptors are similar to Servlet Filters but they acts in Spring Context so are many powerful to manage HTTP Request and Response but they can implement more sophisticated behavior because can access to all Spring context.
  2. Spring interceptor execute in Spring context so they have be defined in rest-servlet.xml file:
  3. The interceptor include three main methods:
    • preHandle: executed before the execution of the target resource
    • afterCompletion: executed after the execution of the target resource (after rendering the view)
    • posttHandle: Intercept the execution of a handler

rest-servlet.xml

<mvc:interceptors>
    <bean class="com.listfeeds.interceptors.LogContextInterceptor" />
    <bean class="com.listfeeds.interceptors.TimedInterceptor" />
</mvc:interceptors>

LogContextInterceptor.java

public class LogContextInterceptor extends HandlerInterceptorAdapter 
{
 private static final Logger log = LoggerFactory.getLogger(LogContextInterceptor.class);

 @Override
 public void afterCompletion(
  HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex)
 throws Exception 
 {
  HandlerMethod methodHandler = (HandlerMethod) handler;
  log.debug("END EXECUTION method {} request: {}", methodHandler.getMethod().getName(), request.getRequestURI());
  }
 

 @Override
 public boolean preHandle(HttpServletRequest request,
  HttpServletResponse response, Object handler) throws Exception 
  {

  } catch (IllegalArgumentException e) 
  {
   log.warn("Prehandle", e);
   return true;
  } finally 
  {
   HandlerMethod methodHandler = (HandlerMethod) handler;
   log.debug("START EXECUTION method {} request: {}", methodHandler.getMethod().getName(), request.getRequestURI());
  }
  return true;
}

Q1.What is the Difference between Filters and Interceptors?
Filter: – A filter as the name suggests is a Java class executed by the servlet container for each incoming HTTP request and for each http response. This way, is possible to manage HTTP incoming requests before they reach the resource, such as a JSP page, a servlet or a simple static page; in the same way, it’s possible to manage HTTP outbound response after resource execution.

  1. A filter dynamically intercepts requests and responses to transform or use the information contained in the requests or responses.
  2. Filters typically do not themselves create a response, but instead provide universal functions that can be “attached” to any type of servlet or JSP page.
  3. They provide the ability to encapsulate recurring tasks in reusable units. Organized developers are constantly on the lookout for ways to modularize their code.
  4. Modular code is more manageable and documentable, is easier to debug, and if done well, can be reused in another setting.

Interceptor: – Spring Interceptors are similar to Servlet Filters but they act in Spring Context so are many powerful to manage HTTP Request and Response but they can implement more sophisticated behavior because can access to all Spring context. Interceptors are used in conjunction with Java EE managed classes to allow developers to invoke interceptor methods in conjunction with method invocations or lifecycle events on an associated target class. Common uses of interceptors are logging, auditing, or profiling.

  1. Interceptor can be defined within a target class as an interceptor method, or in an associated class called an interceptor class.
  2. Interceptor classes contain methods that are invoked in conjunction with the methods or lifecycle events of the target class.
  3. Interceptor classes and methods are defined using metadata annotations, or in the deployment descriptor of the application containing the interceptors and target classes.
  4. Interceptor classes may be targets of dependency injection. Dependency injection occurs when the interceptor class instance is created, using the naming context of the associated target class, and before any @PostConstruct callbacks are invoked.

Refer Here

Q2.Spring interceptor vs servlet filter?

  1. Using Interceptor we can inject other beans in the interceptor
  2. Can use more advanced mapping patterns (ant-style)
  3. You have the target handler object (controller) available, as well as the result ModelAndView
  4. It is a bean, so you can use AOP with it (althoug that would be rare)

Q3.How to avoid multiple submission of Form to Server?

  1. Use JavaScript to disable the button a few ms after click. This will avoid multiple submits being caused by impatient users clicking multiple times on the button.
  2. Send a redirect after submit, this is known as Post-Redirect-Get (PRG) pattern. This will avoid multiple submits being caused by users pressing F5 on the result page and ignoring the browser warning that the data will be resend, or navigating back and forth by browser back/forward buttons and ignoring the same warning.
  3. Generate an unique token when the page is requested and put in both the session scope and as hidden field of the form. During processing, check if the token is there and then remove it immediately from the session and continue processing. If the token is not there, then block processing. This will avoid the aforementioned kinds of problems.

Q4.What is POST-REDIRECT-GET Pattern?
The client gets a page with a form.The form POSTs to the server.The server performs the action, and then redirects to another page.The client follows the redirect.
For example, say we have this structure of the website as below

  1. /posts (shows a list of posts and a link to “add post”) and / (view a particular post)
  2. /create (if requested with the GET method, returns a form posting to itself; if it’s a POST request, creates the post and redirects to the / endpoint)

For retrieving posts /posts/ might be implemented like this:

  1. Find the post with that ID in the database.
  2. Render a template with the content of that post.

For creating posts /posts/create might be implemented like this:

  1. If the request is a GET request for the Insert posts page Show an empty form with the target set to itself and the method set to POST.
  2. If the request is a POST request
    • Validate the fields.
    • If there are invalid fields, show the form again with errors indicated.
  3. Otherwise, if all fields are valid
    • Add the post to the database.
    • Redirect to /posts/ (where is returned from the call to the database)

null