Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [servlet-dev] default context path

On 24/11/2021 09:37, Greg Wilkins wrote:

with jetty we use the deployed filename to determine the default contextPath.  If the app them itself sets a default filename then it replaces that default.   Then if the app uses the jetty specific APIs to set the context path (which are kind of equivalent to an ear file setting the context path) then that replaces the default.

So we don't have the problem at all.

Isn't that something Tomcat can do?

Not without introducing the potential for naming conflicts the current approach was explicitly designed to avoid.

The Tomcat committers did look at implementing the feature when it was first introduced but it created all sorts of issues.

Given the Tomcat committers' general dislike of the feature, lack of user demand for the feature and difficulties in implementation, the consensus of the Tomcat committers was not to implement the feature as the spec allowed for the container to override any provided default and that is what Tomcat always does.

Note: By lack of user demand I mean lack of user demand for this specific solution. There are issues this feature can address such as handling the version number in the file name. There was demand for a solution to that problem but Tomcat implemented a different solution.


On Wed, 24 Nov 2021 at 18:49, Mark Thomas <markt@xxxxxxxxxx <mailto:markt@xxxxxxxxxx>> wrote:

    On 24/11/2021 06:25, Greg Wilkins wrote:
     > I'm not seeing the issue/conflict?
     > If a webapp has a context path configured by the container, then
     > wins.  If it doesn't then the default context path is used.
     > Or are you saying it is impossible to deploy a webapp in tomcat
     > specifying the contextPath in a way that always overrules?

    Yes, that is what I was trying to say.

    Tomcat derives the context path from the file name. The short version
    (skipping over some detail) is that you can't have two files with the
    same name so you can't get context path conflicts.

    That puts Tomcat in the position where it is spec compliant (container
    configuration is allowed to override default-context-path) but it can't
    pass the TCK. Hence my minimum request to exclude the test.

     > On Wed, 24 Nov 2021 at 11:16, Stuart Douglas <sdouglas@xxxxxxxxxx
     > <mailto:sdouglas@xxxxxxxxxx <mailto:sdouglas@xxxxxxxxxx>>> wrote:
     >     On Tue, 23 Nov 2021 at 23:03, Mark Thomas <markt@xxxxxxxxxx
     >     <mailto:markt@xxxxxxxxxx <mailto:markt@xxxxxxxxxx>>> wrote:
     >         Hi all,
     >         I argued strongly against this feature when it was
    proposed on the
     >         grounds it was under specified. It did not address what
     >         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 was assuming that the deployments were targetting the same virtual
    host. I hadn't thought about versions (since the spec doesn't) but in
    this instance I'm considering the case where the versions are the
    same too.

    I agree failing the deployment is reasonable. However, that leaves a
    of open questions. Do you fail one or both? If one, which one. If you
    restart the server will it be the same one?

    I looked though the 5.0 spec document and the feature isn't mentioned
    anywhere. The only documentation I could find for it was in the schema
    for web.xml.

    I dislike this lack of clarity but the lack of clarity is a secondary

     >         I lost the argument not to include the feature but I did
     >         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
     >         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'?

    See above where Greg asked a similar question.

     >         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
     >         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
     >         removed.
     >         I doubt there is sufficient support for that in the
     >         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
     >     the need to strip versions from your archive names.

    ACK. Tomcat has a different way of solving that problem but I
    that having a solution to that use case is important.

    Just to confirm, -1 on all of the above options?

     >     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.

    It is clear that there isn't support for deprecating / removing the
    feature and I can understand why that is the case.

    If all of the above options, including the minimal request, aren't
    acceptable, do you have any alternative suggestions on how to solve
    this? The constraint from the Tomcat side is that there is no wish to
    add support for default-context-path because of all the ambiguity that

    servlet-dev mailing list
    servlet-dev@xxxxxxxxxxx <mailto:servlet-dev@xxxxxxxxxxx>
    To unsubscribe from this list, visit

Greg Wilkins <gregw@xxxxxxxxxxx <mailto:gregw@xxxxxxxxxxx>> CTO <>

servlet-dev mailing list
To unsubscribe from this list, visit

Back to the top