Hi all,
I argued strongly against this feature when it was proposed on the
grounds it was under specified. It did not address what happens if there
is a conflict between the defined default context path and web
applications already installed on the server.
We simply fail the deployment in this case. IMHO we should not really define this as in WildFly (and I assume other servers) you could have the same deployment name bound to different virtual hosts, or you could be supporting multiple different versions of an application at the same time.
I lost the argument not to include the feature but I did obtain a change
that stated words to the effect of "The configured default context path
may be overridden by container specific configuration".
The change was sufficient for Tomcat to completely ignore the default
context path feature on the basis that Tomcat has a mechanism in place
to define context path that was deliberately designed to make conflicts
impossible. This mechanism always applies and therefore always overrides
any default context path that may be set in web.xml.
What do you mean by 'has a method in place to make conflicts impossible'?
The feature is currently tested by the TCK. That TCK test assumes that
the default context path will always be used. This means it is
impossible for Tomcat to pass the TCK.
As a minimum, I would like to disable the default context path test in
the TCK. Users that wanted to test the feature would be able to enable
the test by using custom exclude list.
Ideally, I'd like to see this feature deprecated and eventually removed.
I doubt there is sufficient support for that in the community.
Another possibility would be to explicitly document support for the
feature as optional.
I am -1 on this, as IMHO it is a really useful feature. It removes the need to strip versions from your archive names.
We have always supported the ability to set this via a descriptor though, so I guess I am a bit biased in that respect. We have supported this through a custom jboss-web.xml descriptor, and through the standard application.xml mechanism for EAR packaging.
Stuart
Thoughts?
Mark
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
