Url-pattern differences between OAS and WebSphere
Today I was having a problem with my for a particular working in OAS 10g-9.0.4, but not on WebSphere-5.1. After poking around a bit, it ends up that OAS, OC4J and Tomcat are forgiving/ feature rich when sticking to the Servlet spec and WAS (at least 5.1) is pretty stringent.
The Servlet specification's web.xml DTD provides the to define a particular pattern to match on for particular resources. Usually you just use this for to map a Servlet class to a particular URL and to map a Filter class to a particular URL. You can also use it in security constraints, but I haven't used web.xml for security in many years.
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 context
path 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.