There is a big difference between
One is trailing with / and another one is not.
- <!-- Is Different from <url-pattern>/three/*</url-pattern> -->
- <!-- Is Different from <url-pattern>/three/SomeSpecificResource</url-pattern> -->
Following is the "Mappings" section of the servlet 3.1 specification which talks about the difference between / and /* mappings:
The Specification section:
6.2.4 Configuration of Filters in a Web Application
Refers to the "12.2 Specification of Mappings" section as following:
The requirement about the order of the filter chain means that the container, when receiving an incoming request, processes the request as follows: ■ Identifies the target Web resource according to the rules of “Specification of Mappings” on page 122.
12.2 Specification of Mappings
In the Web application deployment descriptor, the following syntax is used to define mappings:
■ A string beginning with a ‘/’ character and ending with a ‘/*’ suffix is used for path mapping.
■ A string beginning with a ‘*.’ prefix is used as an extension mapping.
■ The empty string ("") is a special URL pattern that exactly maps to the application's context root, i.e., requests of the form http://host:port//. In this case the path info is ’/’ and the servlet path and context path is empty string (““).
■ A string containing only the ’/’ character indicates the "default" servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null.
■ All other strings are used for exact matches only.
If the effective web.xml (after merging information from fragments and annotations) contains any url-patterns that are mapped to multiple servlets then the deployment must fail.
Hi, thanks for the reference to the 3.1 specification. I think I understand how that works.
What I don't get is why the filter with the pattern "/three", which should and does match the URL http://localhost:8080/SimpleWebApp/three stops the servlet with the pattern "/three/*" matching. That servlet should be matched and *is* if the filter is not there but it doesn't match when the filter is present. I don't think there should be an interaction between the two like this. Certainly wasn't in the appserver I'm porting from (the old JBoss 6.1).