On 02/09/2015 09:49, Stuart Douglas wrote:
>> 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.
The base name of the WAR is only used to provide the context path for
the simplest of configuration approaches (drop the WAR in a directory
with no other information provided). As soon as the deployer wants to
provide deployment specific configuration they need to provide a Tomcat
specific configuration file (context.xml) and that then controls the
context path.
I'll add that it is possible to package context.xml within a WAR file
but the Tomcat community has had mixed experiences with this. It has
caused more problems for users that need to change whatever was set in
the packaged context.xml than being able to package it has solved. With
hindsight, allowing context.xml to be packaged in the WAR was a bad idea.
I take the point that there is a dependency from the file name to the
context path in the simple deployment case but it does not require the
WAR to be unpacked, web.xml to be edited and the WAR to be re-packed.
> 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).
Even in the simplest deployment model (drop the WAR in a directory) it
is possible to retain the version info in the file name. In the example
above it would be foo##1.2.1.Final.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.
In the JavaEE spec, component development, application packaging and
application deployment are clearly defined, separate roles. I think that
logical separation should be retained (it encourages re-use of
components) even for organisations that are going down the devops route.
> 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.
As a default, Tomcat will simply ignore it (possibly logging that it has
been ignored) although I image folks will quickly complain about the log
messages if we do that.
If all it does is specify a default, I only see it creating problems
(WARs with conflicting defaults) and don't see it solving any deployment
challenges users currently face.
>>> 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.
I'm aware of application.xml for EAR files. Pointers to the docs for
other containers would be appreciated since I don't know them at all.
Mark