Thanks for the tip; I can't confirm it right now but it seems to me I tried to do just such a mapping and it also violated the parsing rules and was rejected by the webapp loader.
regardless though, I am in a high-volume real-time environment where editing the web.xml to insert a new service is simply not an option, the recognition of .jsp scripts with pathinfo appended needs to be fluid and generic to allow ad-hoc insertions. Even with an auto-recognition of the update to the web.xml, it would take down all the jsp-generated servlets every time a change is made and that would upset a lot of client business. Oh well. Thanks for your help in all this and for the ideas and explanations; looks like I'm stuck with resin and jetty; there's far too many scripts and other systems dependent on these URL patterns to rewrite it all now (the eternal curse of the legacy software) On Tue, Dec 14, 2010 at 7:30 PM, Mark Thomas <ma...@apache.org> wrote: > On 15/12/2010 00:00, Mark Thomas wrote: > >> On 14/12/2010 22:54, Gary Lawrence Murphy wrote: >> >>> On Tue, Dec 14, 2010 at 4:35 PM, Christopher Schultz< >>> ch...@christopherschultz.net> wrote: >>> >>> >>>> however when called with http://localhost:8080/test.jsp/this it >>>>> fails as >>>>> >>>> a >>>> >>>>> 404 not found >>>>> >>>> >>>> Actually, this makes sense to me: the default mapping for the JSP >>>> servlet is "*.jsp". Your path doesn't end in .jsp, and therefore does >>>> not match the url-pattern. >>>> >>>> this is the crux of the problem, and the showstopper preventing us from >>>> >>> deploying under Tomcat -- all our applications use this convention >>> and, as I >>> said, it works in other servlet containers. >>> >>> I tried using *.jsp/* and this threw a parsing error, >>> >> Hmm. Odd. I'll look into that. It won't work they way you want but I'd >> like to get to the bottom of the parsing error. >> >> the webapp refused to run load. *.jsp* ignored all jsp files. >>> >> The * characters are probably being treated literally. >> >> I think other servlet containers >>> are using a globbing that is assumed to be the complete expression, >>> which in >>> regex would be .*\.jsp, whereas it appears that tomcat is taking it in >>> what >>> a regex would phrase as .*\.jsp$, ie it is enforcing the end of the >>> string >>> as the end of the candidate string. If this behaviour cannot be >>> changed, I >>> have to change servlet containers, so I'm eager to find out one way or >>> the >>> other if tomcat can accommodate this. >>> >> >> Tomcat is following the mapping rules in the Servlet spec. It looks like >> Resin has some proprietary extensions to the mapping rules. I'd be >> surprised if you found other containers supporting them. >> > > I can get Tomcat to behave the way you want but configuring web.xml isn't > going to be pretty. I'd strongly recommend moving to an approach more in > line with the Servlet spec rather than the current container-specific > mapping approach. > > If you have a JSP in the root of your webapp called snoop.jsp (I took this > from the examples web app) then you'll need to add the following: > <servlet> > <servlet-name>snoop</servlet-name> > <jsp-file>/snoop.jsp</jsp-file> > </servlet> > <servlet-mapping> > <servlet-name>snoop</servlet-name> > <url-pattern>/snoop.jsp/*</url-pattern> > </servlet-mapping> > > As I said, adding that for every single JSP isn't going to be pretty but it > does give you a way to make this work on Tomcat (or any other container). > > > Mark > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- *Have Blog, Will Travel: blog.teledyn.com* *A Serviceable Substitute: post.teledyn.com*
