What you describe is what we call the "filter pattern" (and we're pushing this for the
Servlet 2.3 "usage" docs). For this you need a Filter, not a Servlet, since servlets
are not "see through". More in detail about the filter pattern at a later date, there
will hopefully be a short walk through of it's flow and common design patterns at that
point (this is one of our favourite flow patterns if we have such a thing).
/Magnus Stenman, the Orion team
PS. If you're bound to 2.2 or lower then you will not be able to use Filters, in that
case you'd have to apply a more complex solution with duplicate resource roots and so
on. Also note that the Filter spec may change before the finalization of the spec,
mainly in the method naming etc category though.
----- Original Message -----
From: "Gerald" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Tuesday, March 20, 2001 10:39 PM
Subject: How to do this servlet-mapping?
>
> Here's a challenge. It was for me.
>
> For all URLs that start with /app (e.g. /app/login, /app/mainmenu,
> /app/ball.gif), have all requests go to a servlet for processing. If the
> servlet recognizes the URL, perform an action and return the appropriate
> output. If the URL is not recognized, treat the URL as a filename and return
> the named resource.
>
> Hence, if the URL /app/login was recognized and requested, the servlet
> takes an action on them. If the URL /app/ball.gif was requested, the servlet
> doesn't recognize it as an action to be performed, and tries to return the
> contents of /app/ball.gif to the user.
>
> I've tried using the servlet-mapping of /app/* and pointing this to the
> servlet. While this makes requests go to the servlet, if, within that
> servlet, I try to get a request dispatcher to /app/ball.gif and forward
> there, I get back into the servlet again , presumably because /app/ball.gif
> maps to the servlet. This, of course, creates an recursive infinite loop and
> soon the server dies.
>
> One alternative that might work, but seems somehow "wrong" to me is to name
> every action in the web.xml file, e.g. individually map /app/login,
> /app/logout, /app/dothis, /app/dothat, etc. and then have /app/* for all
> other resources. I'd like to avoid this particular solution.
>
> Any bright ideas?
>
