Difference between servlet/servlet-mapping and filter/filter-mapping?

Question

As part of exploring/learning Struts2, JSP and Servlets, I see from here and there that servlets and servlets-mapping can be used in web.xml. However, Struts2 mentions filters and filter-mapping too for web.xml.

What is the difference between both? Are these mutually exclusive? When should I use which and why? Can someone clarify the concepts? Thanks.

CLARIFICATION

I just got to understand that I needed to understand how Struts2 and Servlets are related: http://www.coderanch.com/t/57899/Struts/Difference-between-servlet-struts

Answer 1

Servlet filters implement intercepting filter pattern. While servlet is the ultimate target of web request, each request goes through a series of filters. Every filter can modify the request before passing it further or response after receiving it back from the servlet. It can even abstain from passing the request further and handle it completely just like servlet (not uncommon). For instance caching filter can return result without calling the actual servlet.

Answer 2

Filters are used like Servlet Filters. For example, if you need to do security checks on certain URLs then you can add a filter for those pages. For instance, you can say /secure/pages/*.do needs to be intercepted by securityFilter. Then the doFilter() method of the SecurityFilter class (a class that implements the Filter interface) will handle the security audit before forwarding it to the actual requesting servlet.

Servlets are pretty much the standard stuff. You define a servlet and then let the servlet container know what type of requests needs to be mapped to that servlet.

They are not mutually exclusive. They both can be used at the same time. Think of filter like the way the word means - it "filters" things (logging, security,etc) before proceeding to the next servlet/action.

Answer 3

The request lifecycle according to the servlet specification goes through a chain of filters before finally being executed by a servlet.

This is fairly intuitive when you look at the signature for the doFilter method in the Filter interface

doFilter(ServletRequest request, ServletResponse response, FilterChain chain) 

That is, in the filter you have access to the request and response and the chain. The contract is that you, as implementer, should invoke the chain either before or after the operations you do in the filter, or not at all if it is desired to not continue execution. Calling chain.doFilter(...) will cause the next filter in the chain of filters with a mapping matching the requested URL to be executed. The final member of the chain is the servlet whose mapping matches the requested URL.

Technically, you can do everything in a filter that you can do in a servlet. You can build your application to do all processing and rendering in a filter and have a blank servlet that does nothing. The main difference is that if there is no servlet mapped against a given URL, the container must respond with a 404 error so there must always be a servlet mapped against any URL you want to serve. You can also only have one servlet mapped against a URL, but you can have any number of filters.