tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 51278] Unable to override default servlet other than in main web.xml
Date Wed, 01 Jun 2011 15:41:47 GMT

--- Comment #5 from Christopher Schultz <> 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:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message