What is a Servlet filter?

Servlet APIs have long ago become the cornerstone of enterprise application development, while Servlet filters are a relatively new supplement to the J2EE family. In the last article of the J2EE explorer series, the author Kyle Gabhart will introduce you to the Servlet filter architecture and define many applications of filters, it also guides you through three steps to implement a typical filter. He will also reveal some exciting changes to bean, which are expected to be introduced in the newly released Java Servlet 2.4 specification.

Servlet filters are pluggable Web Components that allow us to implement preprocessing and post-processing logic in Web applications. Filters support basic request processing functions of servlet and JSP pages, such as logging, performance, security, session processing, XSLT conversion, and so on. The filter was initially released along with the Java Servlet 2.3 specification, and was significantly upgraded by the recently finalized 2.4 specification. In the last part of this J2EE explorer series, I will introduce you to the basic knowledge of Servlet filters, such as the overall architecture design and implementation details, typical applications in J2EE Web applications will also involve some extended functions that are expected to be provided by the latest Servlet specifications.

What is a Servlet filter?
Servlet filters are small Web Components that intercept requests and responses to view, extract, or operate in some way the data being exchanged between the client and the server. Filters are Web Components that typically encapsulate some functions. These functions are important but not decisive for processing client requests or sending responses. Typical examples include recording data about requests and responses, processing security protocols, and managing session attributes. Filters provide an object-oriented modularization mechanism to encapsulate common tasks into pluggable components that are declared in a configuration file and processed dynamically.

Servlet filters combine many elements to make filters unique, powerful, and modular Web components. That is to say, the Servlet filter is:

Declarative: the filter is declared using the xml tag in the Web deployment descriptor web. XML. This allows you to add and delete filters without modifying any application code or JSP pages.

Dynamic: The Servlet container calls the filter at runtime to intercept and process requests and responses.

Flexible: filters are widely used in Web processing environments and cover many of the most common auxiliary tasks, such as logging and security. Filters are flexible because they can be used to perform preprocessing and post-processing for Direct calls from clients and to process requests scheduled between Web components after the firewall. Finally, you can link the filter to provide the required functions.

Modular: By encapsulating the application processing logic into a single class file, the filter defines modular units that can be easily added or deleted from the request/response chain.

Portable: Like many other aspects of the Java platform, Servlet filters are portable across platforms and containers, further supporting the modularization and reusable nature of Servler filters.

Reusable: thanks to the modular design of the filter implementation class and declarative filter configuration methods, filters can be easily used across different projects and applications.

Transparent: Include filters in the request/response chain, which is designed to supplement rather than replace in any way) core processing provided by servlet or JSP pages. Therefore, the filter can be added or deleted as needed without damaging the servlet or JSP page.

Therefore, Servlet Filters use a configuration file to flexibly declare modular reusable components. Filters dynamically process incoming requests and outgoing responses. They can be added or deleted transparently without modifying the application code. Finally, filters are independent from any platform or Servlet container, allowing them to be easily deployed in any compatible J2EE environment.

In the following sections, we will further examine the overall design of the Servlet filter mechanism and the steps involved in implementing, configuring, and deploying the filter. We will also discuss some practical application of Servlet filters. Finally, we will briefly examine the Servlet filters contained in the Model-View-controller MVC Architecture to end the discussion in this article.

Servlet filter architecture
As its name implies, the Servlet filter is used to intercept incoming requests and/or outgoing responses and monitor, modify, or process the data streams being passed in some way. Filters are self-contained and modular components that can be added to the request/response chain or deleted without affecting other Web Components in the application. Filters are only used to modify the runtime processing of requests and responses. Therefore, they should not be directly embedded into the Web application framework, unless they are implemented through standard interfaces well defined in Servlet APIs.

Web resources can be configured as not associated with a filter, which is the default condition), associated with a single filter, which is a typical case), or even associated with a filter chain. So what exactly does the filter do? Like servlet, it accepts requests and responds to objects. The filter then checks the request object and decides to forward the request to the next component in the chain, or abort the request and send a response directly to the client. If the request is forwarded, it will be passed to another resource filter, servlet, or JSP page in the chain ). After the request is processed by the server through the filter chain, a response will be sent back through the chain in reverse order. This gives each filter the opportunity to process the response object as needed.

When filters are first introduced in the Servlet 2.3 specification, they can only filter content between the Web Client and the specified Web Resource accessed by the client. If the resource then schedules the request to other Web resources, you cannot apply the filter to any requests entrusted by the background. 2.4 The specification eliminates this restriction. Servlet filters can now be applied anywhere in the J2EE Web environment where request and response objects exist. Therefore, the Servlet filter can be applied between the client and servlet, between servlet and servlet or JSP pages, and between each included JSP page. This is what I call powerful capabilities and flexibility!

Implement a Servlet Filter
They say "everything is fine ". I don't know who "they" refer to, or how real the old saying is, but there are three steps to implement a Servlet filter. First, you must write a program that implements the filter class, and then add the filter to the Web application by deploying the descriptor/Web in the web. declare it in xml), and finally package and deploy the filter with the application.

1. Servlet Container matching process
2. How to call Servlet to process requests
3. Extended Future Response Servlet
4. Three methods for compiling Servlet
5. Transactions in Servlet containers