Filters vs Interceptors in Struts 2

Question

What\'s the difference, really, between filters and interceptors? I realize that interceptors fire before and after an action, recursively, and filters can be configured to fir

Answer 1

Struts 2 Framework is not dependent on Servlet API. Struts 2 Actions are not coupled to a container. Most often the servlet contexts are represented as simple Maps, allowing Actions to be tested in isolation.

Filter is a part of Servlet API so Struts 2 Framework uses the concept of Interceptors to share the solution for some common concerns by different actions.

Also you can easily write test cases for Interceptor and Action class.

Answer 2

The most significant difference is that "interceptors" are a part of the Struts 2 framework, and are only part of the request handling that is done by the Struts 2 framework. "Filters" on the other hand are a part of the Servlet Specifcation; in other words, they are part of the Servlet API. If you are using Struts 2, you should use interceptors for wrapping functionality around your Struts 2 actions. If you are trying to wrap functionality around requests coming to your webapp, but not being handled by Struts 2, then a filter might be more appropriate.

BTW, the entire Struts 2 Framework is deployed inside a filter configured in your web app, declared in your webapp's deployment descriptor ( web.xml ) like:

    <filter>
        <filter-name>struts2</filter-name>
        <filter-class>org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter</filter-class>
    </filter>

     <filter-mapping>
        <filter-name>struts2</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

This filter, which is configured to catch all requests URL patterns, is the entry point into the entire Struts 2 framework.

I hope that helps.

Answer 3

What is Interceptor ?

The Struts 2 Framework uses the concept of Interceptors to share the solution for some common concerns by different actions.

As we know the framework invokes a particular Action object on the submssion of a request for it. But before executing of Action, the invocation is intercepted by some other object to provide additional processing required.

Similarly after the execution of Action, the invocation can be intercepted again. This intercepting object is known as Interceptor.

So the purpose of using Interceptor is to allow greater control over controller layer and separate some common logic that applies to multiple actions.

Struts 2 framework has already provided its own set of Interceptors which can be used in the application to provide required processing before and after the Action classs execution.

One of those is "Alias Interceptor" that I am going to discuss here.

Alias Interceptor:

Alias Interceptor is used in case of Action chaining. Action chaining means one Action calls other Action after successful execution of first action.

This interceptor aliases a named parameter to a different parameter name. In action chaining, when two different action classes share a common parameter with a different name, this Interceptor is used to give an alias name to a parmeter of first action class, which matches the parameter name in the second action class.

The alias expression of action should be in the form of :

             #{ 'name1' : 'alias1' , 'name2' : 'alias2' }

Answer 4

the interceptor stack fires on every request.
filters only apply to the urls for which they are defined.

edit -- you use one or the other depending on need. Lets say you need to verify a cookie is present for every request. User an interceptor. Lets say that you need to pop up an external app on some requests (driven by a url), use a filter.

I think interceptors are the more commonly used tool...

why would you have a url with no associated action?

Answer 5

As per the struts 2 life cycle/architecture no interceptors are executed before filter. So if there is no action mapping for your request then it's failing in while passing through filter.

Answer 6

As a rule of thumb

• Filters are run before each request. The struts itself is a filter.
• interceptors can run before, after struts actions. They will not run if the request does not end with .action.

So, some example of filters could be:

• If you want to compress your js and css files, you should go for filters not interceptors.
• If you want only certain IP address access your web site you must develop it as filter and check request ip address.
• If you want to safe your site against CSRF attack you must write a filter to check CSRF token on requests.
• If you want to log your site response per request time, you can use a filter to calculate the time before and after chain.doFilter(request, response)

Theoretically you can develop an struts web application without developing your own interceptors and using filtersonly. But you will face lots problem and code boiler filters.

Lots of struts 2 features are build with interceptors, you can find it in struts-default.xml (https://struts.apache.org/docs/struts-defaultxml.html) the list will help to find when interceptors can be used. (For example ParametersInterceptor runs before actions to apply submited form values to actions)

While working with interceptors you can easily access struts features, for example getText from message resources, get current action name and name space, change the action flow.

Considering above here are some cases which can be developed by interceptors:

• If you want that only logged in users can access certain actions, you must develop it with interceptors.
• If you want to keep track which actions user is navigation. You can use an interceptor to keep track of visited actions.
• If you want to handle your action errors in a single point, you can use an interceptor which catch all invocation.invoke()

The interceptors are providing the filter and Chain of Responsibility design pattern for struts actions, while filters provide this pattern to your whole web application.