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 25/11/2021 21:50, Mark Thomas wrote:
On 25/11/2021 21:32, Greg Wilkins wrote:

My understanding is that there are a lot of politics around optional features and that we may need to seek permission to have them, which is likely to be denied for this round.

I'd argue it is already effectively optional since containers are permitted to override it and there are no constraints on when containers can and can't do that.

I'm fine with not making it officially an optional feature. It was a suggestion to see what the community thought.

Surely there is something Tomcat can do to not override the default in some specific situation that will allow it to pass the TCK?

That would require significant code changes and introduce the possibility of start-up failures due to name clashes - something the Tomcat committers would like to avoid.

I think I misunderstood you when I wrote the above. Because Tomcat doesn't read and then override the default, I was thinking in terms of implementing support for the default. Thinking in terms of something along the lines of "If we detect we are deploying the TCK WAR that tests the default context feature, deploy it at the path it expects." that would be doable but feels like an awful hack.

I'll discuss that with the Tomcat committers as it would mean the test would remain enabled and relevant for those containers that have implemented the feature.


If excluding the test isn't an acceptable way forward (I think Stuart was reluctantly OK with that, my sense is that you are not) then Tomcat will continue as before - running the TCK expecting that one test to fail.


On Thu, 25 Nov 2021 at 17:37, Stuart Douglas <sdouglas@xxxxxxxxxx <mailto:sdouglas@xxxxxxxxxx>> wrote:

    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 that
         > 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 without
         > 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
        (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
        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 <mailto:sdouglas@xxxxxxxxxx>>> wrote:
         >     On Tue, 23 Nov 2021 at 23:03, Mark Thomas
        <markt@xxxxxxxxxx <mailto: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 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
         >     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
        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 lot
        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
        anywhere. The only documentation I could find for it was in the
        for web.xml.

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

         >         I lost the argument not to include the feature but I
        did obtain
         >         a change
         >         that stated words to the effect of "The configured
         >         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'?

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

        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

    I am ok with making it optional I guess, and not requiring a TCK
    test. It does greatly diminish the usefulness of the feature though
    if it is not properly portable.


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

    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

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

Back to the top