tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: servlet-mappings
Date Mon, 05 Nov 2001 00:01:08 GMT

On 3 Nov 2001, Dr. Evil wrote:

> Date: 3 Nov 2001 08:40:32 -0000
> From: Dr. Evil <>
> Reply-To: Tomcat Users List <>
> To:
> Subject: servlet-mappings
> I'm trying to do some fancy stuff with servlet mappings.  This
> mechanism leaves a lot to be desired; specificly, it would be
> amazingly useful to be able to do a getRequestDispatcher in some way
> that bypasses the servlet mappings in the web.xml file.

Such as ServletContext.getNamedDispatcher()?

>  Alternatively
> it would be extremely useful to be able to call the jsp servlet from
> within another servlet, but this doesn't seem to be possible.  rd =
> request.getRequestDispatcher("jsp") never seems to work.

This would work with the named dispatcher method above, but what are you
trying to do with it?  Since you're not referencing a particular JSP page,
getting a dispatcher to the JSP servlet isn't particularly useful for
anything.  (Besides, there is not necessarily any such a thing as "the JSP
servlet" on other containers, so you are locking yourself in to Tomcat).

> Anyway, here's the question:
> I know there are prefix mappings, such as /foo/bar/, and extension
> mappings such as *.foo, but it doesn't seem like it's possible to do
> mappings like /foo/bar/*.baz.  This mapping seems to never hit.  Is
> there a way to do that?

The legal mappings are those defined in the Servlet Specification, which
I've given you the URL for before (hint hint :-).

As you will find, patterns like "/foo/bar/*.baz" are not legal servlet
mapping patterns.

In a servlet 2.3 environment, one option you have is to define a Filter
that is mapped to "/*" (i.e. it will process every request to this web
app).  In your Filter, you can examine the request URI and use a request
dispatcher to forward to whatever servlet you like (and totally bypass the
mappings of the servlet container itself).  Although most Filters pass the
request on to the rest of the chain, this is *not* required.

Effectively, your filter would define exactly the mappings *you* want.
And, because Filters are portable, you would not be locked in to a
particular container.


To unsubscribe:   <>
For additional commands: <>
Troubles with the list: <>

View raw message