https://issues.apache.org/bugzilla/show_bug.cgi?id=51278

Chris Beams <cbe...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cbe...@gmail.com
         OS/Version|                            |All

--- Comment #1 from Chris Beams <cbe...@gmail.com> 2011-05-28 08:25:07 UTC ---
Thanks for filing this issue, Mark.  I encountered this behavior when designing
a ServletContainerInitializer for the Spring Framework.  The SCI declares
@HandlesTypes for a spring-specific SPI (WebApplicationInitializer).  The
intent of this interface is to allow users a convenient and automatically
detected way to replace web.xml with code.

Many users map Spring's DispatcherServlet to '/', and this works fine when done
from web.xml.  However, for the reasons you've described, a direct translation
of this mapping into code does not work, because Tomcat's DefaultServlet has
already been mapped.

Your suggested resolution sounds like just what we need in the immediate term. 
As for the future (i.e. Servlet 3.1), perhaps the EG could consider making the
overriding rules a bit more flexible.  For example,
FilterRegistration#addMappingForUrlPattern[1] currently accepts a boolean
"isMatchAfter" argument that suggests this kind of flexibility.

In any case, short term or long, the question is whether mapping to '/' will be
portable.  I'm about to try this same scenario against Jetty and Glassfish; it
will be interesting to see if they too have ordering issues with default
mappings to '/', or perhaps have already addressed this very scenario.

[1]
http://download.oracle.com/javaee/6/api/javax/servlet/FilterRegistration.html#addMappingForUrlPatterns(java.util.EnumSet,
boolean, java.lang.String...)

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to