Filters can be chained together, to run one after the other. Filters are designed to be totally self-contained. A filter doesn’t care which (if any) filters ran before it did, and it doesn’t care which one will run next.
The DD controls the order in which filters run; we’ll talk about filter DD configuration a little later in the chapter.
DD configuration 1:
Using the DD, you can link them together by telling the Container: “For these URLs, run filter 1, then filter 7, then filter 3, then run the target servlet.”
DD configuration 2:
Then, with a quick change to the DD, you can delete and swap them with: “For these URLs, run filter 3, then filter 7, and then the target servlet.”
 We’re fudging a little. The deployer often does need to configure the order based on the consequences of the transformations performed by the filters. You wouldn’t, for example, add a watermark to an image after you applied a compression filter. In that example, the watermark filter would have to do its thing before the data hits the compression filter. The point is, you as the programmer will not build dependencies into your code.