----- Original Message -----
> From: "Mark Thomas" <markt_at_apache.org>
> To: jsr369-experts_at_servlet-spec.java.net
> Sent: Wednesday, 2 September, 2015 5:22:26 PM
> Subject: [servlet-spec users] [jsr369-experts] Re: Re: SERVLET_SPEC-137: Allow context root
>
> On 01/09/2015 21:40, Edward Burns wrote:
> > MT> On 01/09/2015 01:15, Shing Wai Chan wrote:
> >
> > SWC> If this is a Servlet 4.0 feature, there is most likely a Servlet
> > SWC> TCK assertion for this. Mark, can you help us understand why you
> > SWC> are taking such a strong position against it as a representative
> > SWC> for the hugely important Tomcat community?
> >
> >>>>>> On Tue, 1 Sep 2015 19:19:45 +0100, Mark Thomas <markt_at_apache.org>
> >>>>>> said:
> >
> > MT> As I have said previously on this thread, web applications are meant
> > MT> to be independent of the context path at which they are
> > MT> deployed. Anything that encourages web application developers to
> > MT> think that they can code to a specific context path is a bad idea.
> >
> > May I paraphrase the spirit of your position as "don't make it any
> > easier than absolutely necessary to do bad things."
>
> No, that is not the spirit of my position. That is a secondary concern.
>
> The spirit of my position is a combination of "Web applications should
> be independent of the context path at which they are deployed" and
> "deployment is not a developer concern".
If tomcat required every deployment to explicitly have its context path specified
I could understand your concern, but it doesn't. Instead it defaults to the name
of the archive, so your default context path is already not independent from the
application packaging.
In some ways is very inconvenient, instead of leaving versions in filenames so it
is immediately obvious what is deployed (foo-1.2.1.Final.war) developers simply
follow the path of least resistance and rename the archive (foo.war).
Also your assertion that 'deployment is not a developer concern' is not true
for all organisations, especially not for any that have adopted devops principals.
At the end of the day this is a default, it can be changed, and it is a lot
more flexible that the current default of renaming the archive.
>
> > While I agree with
> > the spirit of your position, in this case I think that spirit is trumped
> > by several factors, in decreasing order of importance.
> >
> > 1. many containers already offer this in a proprietary fashion
>
> Many containers provide an in WAR method to define a preferred context
> path that can be overridden during deployment? References please.
We (JBoss) do, judging by earlier comments it appears that Glassfish does, and any EE container can control
it via application.xml for EAR deployments.
Stuart
>
> > 2. it sure would be convenient to offer it as a standard
>
> Convenient to who? For what use cases?
>
> The testing use case is the best argument made so far and I'm not
> convinced by that.
>
> > 3. we can put it at the bottom of a priority list, allowing the
> > preservation of out-of-webapp context-root specification
> >
> > 4. we can name the XML element sufficiently obviously to make it clear
> > the priority is below other ways of specifying the context-root.
> >
> > SWC> Yes, we should allow the container to override the context root
> > SWC> configuration. We can discuss more on the XML element name once we
> > SWC> agree to have this feature.
> >
> > MT> Then as I stated above, Tomcat will *always* override whatever is set
> > MT> here - effectively ignoring it. I have no wish to deal with the
> > MT> inevitable conflicts that will result when multiple applications all
> > MT> want to be deployed with a context path of "".
> >
> > This is a good point. What do you do in Tomcat if multiple apps are
> > attempted to be deployed with the same context root, even when it is ""?
>
> It is only possible to do this in Tomcat if the deprecated / strongly
> discouraged method of defining web applications in the main
> configuration file is used (which is bad because you have to restart
> Tomcat to make any changes). I'd need to look at the code to see what
> would happen. I think the second and subsequent apps with the same path
> will fail to start but it is possible that the entire container will
> fail to start.
>
> If using Tomcat's documented deployment approaches it simply isn't
> possible for a conflict to occur.
>
> Mark
>
>