Yes, this is what I do also, I have an app with a webservice so needed it to not get caught in the Struts filter. It is a shame however, as I would like to have kept the URLs neat without the action on the end. But as they say, don't get caught up in what the URL says.
-----Original Message----- From: Greg Lindholm [mailto:greg.lindh...@gmail.com] Sent: 02 November 2009 15:53 To: Struts Users Mailing List Subject: Re: strust2: filter-mapping best practice - <url-pattern>/*</url-pattern> I have a number of servlets in the same web app so to make it work I have restrict the filter mapping as follows. <filter-mapping> <filter-name>struts2</filter-name> <url-pattern>*.action</url-pattern> </filter-mapping> <filter-mapping> <filter-name>struts2</filter-name> <url-pattern>/struts/*</url-pattern> </filter-mapping> The first one catches all requests with .action extensions which is what I use. The second one was suggested on this mailing list since there are resources that struts UI controls can request. On Sun, Nov 1, 2009 at 9:38 AM, Graham Leggett <minf...@sharp.fm> wrote: > Hi all, > > I am trying to develop a struts2 app, and I am struggling to find a > reference that explains the thinking and/or best practice behind the > url-pattern in web.xml. > > Google uncovers hundreds of articles showing the url-pattern being > specified as follows: > > <filter-mapping> > <filter-name>struts2</filter-name> > <url-pattern>/*</url-pattern> > </filter-mapping> > > This has the side effect that every URL in the application passes > through struts2 - is this intentional? > > What I am trying to achieve is to include a directory of images within > my war file, and none of the images display, because struts2 grabs the > URLs and processes the request instead. > > What is the recommended best practice for embedding images within a web > application, so that the images are displayed without being fiddled with > by struts2? > > Regards, > Graham > -- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
