On 4 September 2015 at 02:15, Shing Wai Chan <shing.wai.chan_at_oracle.com>
wrote:
>
> As an example, the context-path is "/foo" and <context-root> is "foo".
> Do we want "/foo" or "foo" as the value in web.xml?
> I think we should be in the latter case.
I'm the opposite, I'd like to see
<default-context-path>/foo</default-context-path>
On 4 September 2015 at 01:40, Eirik Bjørsnøs <eirbjo_at_gmail.com> wrote:
>
> 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.
I definitely agree in principal with Mark and Eirik. However, I think the
horse has long ago bolted on
correctly separating concerns for webapp deployment.
web.xml is a called a deployment descriptor and in that respect it really
should have been were
deployment specific configuration was put: context paths, init parameters
and other properties,
authentication/authorization configuration. But web.xml also contain the
structure of the
webapp and it is baked into the WAR file, so in that sense it has always
been a poor deployment
descriptor. Concerns are not separated, control is already inverted and
there are many many
examples of poorly developed webapplications that contain assumptions about
their deployment
environment baked into the war.
So for me, this issue comes down to a choice between two evils: scrambling
the broken egg
some more vs trying to provide standard configuration for a parameter that
every webapp deployment
needs.
If we were having this conversation 10 years ago, I would have been
advocating for the specification
to define a real deployment descriptor that is external to the war file.
This is what all containers
provide in non standard ways in their context.xml or similar mechanisms.
In jetty, we also try to provide a sliver of standard based deployment
configuration by allowing an
external web.xml to be applied to a war file. Init parameters and mappings
can thus be externally
applied to an immutable war file using standard elements. Because of
this, having a
<context-path> element in the web.xml would actually work OK in Jetty and
could be
used with separated concerns.
However, no matter how well we define an external standard deployment
descriptor, containers are
still going to need proprietary context.xml style configuration as there
will always be more non standard
things to configure.
So I don't think that <default-context-path> is a massive win for
correcting the deployment descriptor,
but then I can see it might be useful in some circumstances and the egg is
already scrambled.
Thus on balance I think it does more good than harm.
Actually, I can almost see the need for both <default-context-path> where
a deployment is suggesting
a context path that should be used if non other is configured, plus also a
<context-path> element which
declares the application has been hard coded to assume that context-path
and you should fail to
deploy if that path cannot be assigned.
cheers
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com