(Posting to users list, hopefully this will reach the experts)
Being a long time user of the servlet spec (I cut my teeth on Apache JServ
back in ~99), and having developed several deployment related tool stacks
on top of it, I must say I agree pretty strongly with Mark on this issue.
In the age of micro services and container-less applications, the reason
I'm still even using the servlet spec and its war packaging format is
exactly the distinct and clearly communicated separation between
development and deployment responsibilities that the spec provides.
Everyone understands what a war is and how it relates to deployment.
The mapping of these responsibilities onto organisational roles was
speculative and never really materialised. That does not at all mean that
the separation itself does not have a high technical and practical value.
Adding a deployment-time concept such as context path configuration to a
development-time resource such as web.xml breaks this clear separation of
concerns. It muddies the water of an otherwise pretty clear lake. People
don't like to swim in muddy waters.
Adding to this, it also breaks inversion of control, another important
design principle. A webapp should be configurable from _outside_ the app.
This lets us keep the war as a single binary artifact that never changes
between environments.
The fact that that the expert group accepts sneaking this into the spec
just because someone have a smelly itch to scratch disappoints me. It is a
stellar example of bad API design.
The argumentative style used is also quite dubious. "We'll include this
unless nobody can present a compelling enough reason (decided by us) not to"
I think the onus probandi should fall heavily on those who try to introduce
this, not those trying to prevent it.
Please: When in Doubt, Leave It Out
https://www.youtube.com/watch?v=aAb7hSCtvGw&feature=youtu.be&t=24m37s
Cheers,
Eirik.
On Thu, Aug 27, 2015 at 12:42 AM, Mark Thomas <markt_at_apache.org> wrote:
> On 25/08/2015 20:53, Shing Wai Chan wrote:
> > I am looking at https://java.net/jira/browse/SERVLET_SPEC-137
> > (“Allow context root”)
> >
> > In Java EE ear application, one can configure the context-root in
> > application.xml.
> > For war, there is no such configuration in web.xml.
> >
> > Most servlet containers take default context-root = name of the
> > applications.
> > And there are different solutions to configure the context-root as
> follows:
> > i) configure context-root through the proprietary descriptors.
> > For instance glassfish-web.xml in GlassFish and weblogic.xml in
> > WebLogic.
> > ii) configure context-root at the time of deployment without editing
> > descriptors in the war.
> > iii) support the configuration of context-root “after” the deployment
> > through administration tool.
> >
> > I am considering adding a context-root element in web.xml.
> > Any comments?
>
> I don't like it.
>
> Web applications are meant to be independent of the context path they
> are deployed to.
>
> Containers already provide container specific ways to specify the
> context path as part of the deployment process (which is where the
> context path should be defined).
>
> I'm pretty sure if this features makes it into Servlet 4.0 (and I am -1
> on that happening) then Tomcat is simply always going to ignore whatever
> is set.
>
> Mark
>
>