I stumbled upon a bug in my web application that had me scratching my head (and eventually pulling my hair) for a while before I found out what was going on.
Basically, I had 2 filters defined in my web.xml, and the two mappings like that :
<filter-mapping> <filter-name>encodingFilter</filter-name> <servlet-name>SpringMVCDispatcher</servlet-name> </filter-mapping> <filter-mapping> <filter-name>SpringFormMethodFilter</filter-name> <url-pattern>/administration/*</url-pattern> </filter-mapping>
They are both Spring MVC filters. My problem was that the form data I got was not interpreted as UTF-8 despite the fact that the encodingFilter was supposed to set the request encoding to UTF-8 before anything else had the opportunity to read from it.
I finally noticed that the form method filter was executed BEFORE the encoding filter, although the order in which filter mappings are defined is supposed to be the order in which they are chained :
The order of the filters in the chain is the same as the order that filter mappings appear in the web application deployment descriptor.
(from Oracle)
When I used the same mapping, i.e. mapping to a servlet instead of a URL pattern, for both mappings, the order is restored and everything works as intended:
<filter-mapping> <filter-name>encodingFilter</filter-name> <servlet-name>SpringMVCDispatcher</servlet-name> </filter-mapping> <filter-mapping> <filter-name>SpringFormMethodFilter</filter-name> <servlet-name>SpringMVCDispatcher</servlet-name> </filter-mapping>
Is that part of the Servlet
specification or is it a glitch of Tomcat ? Is it documented somewhere, should I submit a bug report ?
I am using Tomcat 7.0.39 with Java 7.
First, it receives ServletRequest and ServletResponse object pairs for incoming requests. Depending on the counter, it then either passes them down the chain by invoking the next doFilter() method on the FilterChain object, or rejects them by generating its own response.
First, the <url-pattern> matching filter mappings in the same order that these elements appear in the deployment descriptor. Next, the <servlet-name> matching filter mappings in the same order that these elements appear in the deployment descriptor.
xml determines the order in which the web container applies the filter to the servlet. To reverse the order of the filter, you just need to reverse the filter-mapping elements in the web. xml file.
When the container recives a request, it first finds all the filter mappings with a <url-pattern>
that matches the request URI. This becomes the first set of filters in the filter chain.Next it finds all the filter mappings with a <servlet-name>
that matches the request URI. This becomes the second set of filters in the filter chain.In both the sets the filters are executed in the order in which they are declared in the Deployment descriptor(D.D.)
According to the specs
The order the container uses in building the chain of filters to be applied for a particular request URI is as follows:
- First, the
<url-pattern>
matching filter mappings in the same order that these elements appear in the deployment descriptor.- Next, the
<servlet-name>
matching filter mappings in the same order that these elements appear in the deployment descriptor.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With