I agree with you.
The static resources where never a problem to me, but since I messed with
the web.xml they started to behave oddly.
Maybe this line is causing trouble:
<servlet-mapping>
<servlet-name>invoker</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
It used to be:
<servlet-mapping>
<servlet-name>invoker</servlet-name>
<url-pattern>/servlet/*</url-pattern>
</servlet-mapping>
What do you think? Can this be interfering with the requests to resources?
-----Mensaje original-----
De: Tim Funk [mailto:funk...@apache.org]
Enviado el: miércoles, 08 de junio de 2011 14:09
Para: Tomcat Users List
Asunto: Re: Static resource mapping in web.xml
If your images are in the correct directory then tomcat will serve them for
you with its DefaultServlet. There should be nothing to do.
Then to serve resources via the invoker - this is where the filter is handy.
You declare the invoker servlet - but you do not map it. The servlet api
allows you to invoke an unmapped servlet by requesting it by name from the
ServletContext. So the filter is doing the access control mapping to
determine if the invoker should be invoked.
-Tim
On Wed, Jun 8, 2011 at 12:34 PM, <falva...@geocom.com.uy> wrote:
> I thought the filter would allow me to serve the static resources under
> "/images/".
>
> I understand if it is in order to make invoker more secure.
>
> But what I'm actually trying to achieve is the proper serving of
resources.
>
> I don't know exactly why, but mapping the default servlet to "/*" is not
> working (probably my fault). What Mark pointed in his first mail is that
> this kind of mapping was added in release 6.0.30. I'll try this as soon as
> possible.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
