> > >Ok, but this changes the bahavior of Tomcat, so this has the potential to >break things. >Also, the new spec clarifies it a bit, and requires to be able to do welcome >files on non-existing paths, but which map to something (so getResource is >not a good test). Since everything maps to the default servlet, I don't see >how to implement this. > >
It seems like there are only a few things we can do about this: 1. Call the servlet, buffer its output, and see if it is an error. If it is an error, try the next file in the welcome list. If not, use it. This relies on servlets honoring this convention. It also slows down throughput. 2. API change or some kind of convention for the servlet to tell the container that the servlet can handle the path given. This seems icky. 3. Decide bug 9016 behavior is by design, and wait for the spec to clarify how to implement the behavior wanted in bug 9016. >I'd say no, because it could be a directory listing. > Ok. >>As for the speed issue, I would be happy to address it with caches or >>something else ( I love optimizing ) when someone gave me very >>conclusive proof that the mapping overhead is significant. >> >> > >I did some OptimizeIt profiles, and the mapping is quite bad. Going with a >byte-based mapping would help. > > Ok, when everything is all coded, I'll think about addressing this. -Dan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
