https://issues.apache.org/bugzilla/show_bug.cgi?id=51278
--- Comment #5 from Christopher Schultz <ch...@christopherschultz.net> 2011-06-01 15:41:47 UTC --- (In reply to comment #4) > Actually, we are talking primarily about Servlets here. I was only mentioning > the FilterRegistration API momentarily above. Right. I was just pointing-out that the rules for Servlets and Filters are apparently different. > The critical issue is this: Tomcat users can override the DefaultServlet's > mapping to '/' within web.xml, but cannot do so within a > ServletContainerInitializer (or presumably any other programmatic context). > This inconsistency means that web.xml cannot be completely replaced by code in > a Tomcat environment, which is what we're aiming to facilitate. Yup, I get it, and you certainly /should/ be able to set these things from within the code. Tomcat's DefaultServlet should be a last-resort that handles requests only when no other servlet can be found. > I've been unable to pinpoint a passage in the spec that spells out that the > status quo is the way things *should* work, but then again - and if I > understand things correctly - the spec is silent on the way Tomcat registers > its DefaultServlet, so we're probably already in unspecified territory, yes? The closest I could come was looking at the javadoc for the addServlet and addFilter methods in ServletContext, which have some things to say about the behavior of those methods when a URL mapping already exists. I guess the question is really whether the DefaultServlet being mapped to "/" really "counts" as a traditional mapping, or if the DefaultServlet should be considered something that just handles all otherwise-unhandled requests. If you think about it that way, then registration of a Servlet on "/" should be able to happen at any time during the lifecycle of the webapp (even long after the context has been started) as long as no previous registration has occurred. I guess what I'm suggesting is that we might want to register DefaultServlet in a way that is orthogonal to the registration of all other servlets so we don't have to have special-case handling for processing web.xml, then annotations, then fragments, then running all ServletContextListeners, then processing conf/web.xml to get around this apparent oddity. -- 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
