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 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 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>> wrote: 



    On Tue, 23 Nov 2021 at 23:03, Mark Thomas <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 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 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 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 consideration. 


        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'?


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 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.
ACK. Tomcat has a different way of solving that problem but I appreciate 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 introduces. 

Mark

Back to the top