users@servlet-spec.java.net

[servlet-spec users] Re: [jsr369-experts] Re: SERVLET_SPEC-137: Allow context root

From: Edward Burns <edward.burns_at_oracle.com>
Date: Fri, 4 Sep 2015 08:02:38 -0700

>>>>> On Thu, 3 Sep 2015 17:40:10 +0200, Eirik Bjørsnøs <eirbjo_at_gmail.com> said:

Eirik> (Posting to users list, hopefully this will reach the experts)

Thanks for using the users list, that is *exactly* why we have it!

Eirik> Being a long time user of the servlet spec (I cut my teeth on
Eirik> Apache JServ back in ~99), and having developed several
Eirik> deployment related tool stacks on top of it, I must say I agree
Eirik> pretty strongly with Mark on this issue.

Thanks for making your voice heard.

Eirik> In the age of micro services and container-less applications, the
Eirik> reason I'm still even using the servlet spec and its war
Eirik> packaging format is exactly the distinct and clearly communicated
Eirik> separation between development and deployment responsibilities
Eirik> that the spec provides. Everyone understands what a war is and
Eirik> how it relates to deployment.

To be fair, that clearly communicated separation of responsibilities is
already breaking down the minute any one of the container-specific ways
of baking the context-root into the WAR is employed.

Eirik> The mapping of these responsibilities onto organisational roles
Eirik> was speculative and never really materialised. That does not at
Eirik> all mean that the separation itself does not have a high
Eirik> technical and practical value.

No doubt, it certainly does.

Eirik> Adding a deployment-time concept such as context path
Eirik> configuration to a development-time resource such as web.xml
Eirik> breaks this clear separation of concerns. It muddies the water of
Eirik> an otherwise pretty clear lake. People don't like to swim in
Eirik> muddy waters.

I have never looked at the web.xml as a development time resource. Not
for nothing is the web.xml more correctly referred to as the Deployment
Descriptor.

Eirik> Adding to this, it also breaks inversion of control, another
Eirik> important design principle. A webapp should be configurable from
Eirik> _outside_ the app. This lets us keep the war as a single binary
Eirik> artifact that never changes between environments.

Yes, it does that indeed, but we crossed that bridge back in Java EE 5
when we whole-heartedly embraced a programming model based on Java
Annotations that are baked into .class files at compile time.

And this feature, like annotations, is not required to be used, so if
you don't like it, you don't have to use it.

Eirik> The fact that that the expert group accepts sneaking this into
Eirik> the spec just because someone have a smelly itch to scratch
Eirik> disappoints me. It is a stellar example of bad API design.

On the contrary, the very fact that we are having this discussion is a
consequence of the JCP transparency being employed in the development of
Servlet 4.0.

Eirik> The argumentative style used is also quite dubious. "We'll
Eirik> include this unless nobody can present a compelling enough reason
Eirik> (decided by us) not to"

Well, that's indeed the job of the spec lead. Innovation happens
elsewhere. The spec lead takes ideas proposed by the EG (and by proxy
the community at large represented by the EG members) and determines
which ones should be in the spec, and, more importantly *how* they fit
into the spec when they originate in different contexts that may not map
exactly to the spec.

Eirik> I think the onus probandi should fall heavily on those who try to
Eirik> introduce this, not those trying to prevent it.

I think the EG and users list discussion does bear that burden of proof.

Eirik> Please: When in Doubt, Leave It Out

Eirik> https://www.youtube.com/watch?v=aAb7hSCtvGw&feature=youtu.be&t=24m37s
Eirik> <https://www.youtube.com/watch?v=aAb7hSCtvGw&feature=youtu.be&t=24m37s>

Ah yes, that old chestnut. Thanks for sharing it. Josh had just
recently left Sun at that point.

Ed

-- 
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 42 Business days til JavaOne 2015
| 57 Business days til DOAG 2015