The Servlet specification's web.xml DTD provides the
The javax.servlet.Filter was not processing for my STRUTS actions. This was strange as everything was working fine on developers' local workstations and our test environments. Of course the devs use OC4J and the test environments run OAS, so there was some differences that could lead to this problem.
The pattern a developer is trying to use is: "/path/*.do". You would think that the app server would apply the mapped filter to any http request ending with .do in the /path/ path. OAS, Tomcat and OC4J think this as well. However, WAS sees this as not matching the servlet spec and checks for the literal http request "/path/*.do".
It looks like section 11.2 of the Servlet 2.3 spec has the following to say about defining mappings:
- A string beginning with a '/' character and ending with a '/*' postfix is used
for path mapping.
- A string beginning with a '*.' prefix is used as an extension mapping.
- 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 contextpath and the path info is null.
- All other strings are used for exact matches only.
As it is currently written, an architect has to plan the structure of his application depending on what servlet and request filters he expects to use. This is an unpleasant limitation as the implementation affects the structure and is hard to change several years into a project.
I'm not sure if OAS and Tomcat specifically extended support of the spec, or they were just too lazy to use * for anything other than a string wild card match (a good thing).
So WebSphere is adhering to the letter of the law, but not the spirit. I hope that WAS6 or WAS7 make this change.
I will add a comment to the new JSR for Servlet 2.6 when it is created (jsr154 for 2.4/2.5 just wrapped up in May), as I think this is a bit of useful logic that should be in every servlet container.