Replacement is a very tough word, but indeed, common functionality across servlets can often be factored into a reusable Filter. The Cocoon framework is almost exactly that - effectively a 'filter based' request-response cycle, which works very well.
You have come to a significant level of enlightenment.
Originally posted by Bob CHOI: The screwdriver that is better for you is the one suitable for you.
You miss my point. A hammer is never "the screwdriver that is better for you".
There are technical reasons that a filter is not a suitable replacement for a servlet, but even brushing those aside, using a tool incorrectly, even if it can adequately do the job, obfuscates your design and code. Others will not be expecting you to misuse the tool in this manner and all you will do is create confusion and code that deviates from the conventional.
Using unconventional and obfuscating methods "just because I can" is not the sign of a mature developer.
Bear's point that replacing all servlets with filters would be to "obfuscate your design and code" is an important one. Another way to highlight the difference between servlets and filters is to consider the types of problems that each is designed to address.
My understanding of filters suggests that they are most powerful when used to modularly address cross-cutting concerns that would otherwise have to be coded in multiple places (ie servlets). But without any servlets, there would be no cross-cutting concerns.
For example, logging & security are both cross-cutting concerns that will apply throughout your application. Filters are one option for addressing those concerns in a single (code) location, rather than writing security and logging code into each servlet you write.