You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2021/11/25 22:18:13 UTC
default context path
Hi all,
I am working on updating the Servlet TCK for Servlet 6 and I have been
discussing with the Jakarta Servlet community whether or not we could
disable the TCK test that checks default-context-path support.
Tomcat doesn't implement this feature as the container is allowed to
override this default and we always do - primarily to avoid a bunch of
edge cases.
Other containers do implement the feature and the preference looks to be
keeping the TCK test enabled.
If we want to fully pass the TCK, one option is to hard-code the
deployer to deploy the specific TCK WAR to the correct path if
STRICT_SERVLET_COMPLIANCE was enabled. This is a fairly ugly hack but it
would enable Tomcat to fully pass the TCK.
What do we think?
a) Do we want to fully pass the TCK? Is a hack along the lines I
described an acceptable way to do this?
b) Do we do nothing now and keep this as an option if we get to the
point where we do want to fully pass the TCK and certify compliance?
c) Do we make a formal challenge of the TCK test on the grounds the
little documentation there is says the container can override this
default so the test is invalid on the basis it doesn't allow for the
override?
Assuming the Servlet team decides to keep the test, I am leaning towards
b) or maybe a)
Thoughts?
The last time we discussed this:
https://tomcat.markmail.org/thread/4g7nb36fzf4byrej
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: default context path
Posted by Mark Thomas <ma...@apache.org>.
On 27/11/2021 19:03, Christopher Schultz wrote:
> Mark,
>
> On 11/25/21 17:18, Mark Thomas wrote:
>> Hi all,
>>
>> I am working on updating the Servlet TCK for Servlet 6 and I have been
>> discussing with the Jakarta Servlet community whether or not we could
>> disable the TCK test that checks default-context-path support.
>>
>> Tomcat doesn't implement this feature as the container is allowed to
>> override this default and we always do - primarily to avoid a bunch of
>> edge cases.
>
> Just how dangerous are these edge cases?
The edge cases are around conflicts. If the default-context-path
conflicts with a WAR, DIR or XML file. Is there a priority order? Should
behaviour be consistent regardless of deployment order?
No dangerous but it creates potential for inconsistent and/or unexpected
behaviour.
> How are other containers implementing these safely?
Generally they are failing deployments. Which ones in which scenarios
will vary as none of this is specified in the spec.
> Or is it a question of underlying
> implementation-specific details that make supporting this safely kind of
> a pain in Tomcat?
It is more that handling the edge cases is non-trivial and is
particularly annoying as we have a deployment system designed to avoid
exactly these sort of conflicts.
>> Other containers do implement the feature and the preference looks to
>> be keeping the TCK test enabled.
>>
>> If we want to fully pass the TCK, one option is to hard-code the
>> deployer to deploy the specific TCK WAR to the correct path if
>> STRICT_SERVLET_COMPLIANCE was enabled. This is a fairly ugly hack but
>> it would enable Tomcat to fully pass the TCK.
>>
>> What do we think?
>> a) Do we want to fully pass the TCK? Is a hack along the lines I
>> described an acceptable way to do this?
>
> I think we'd like to be able to pass the TCK, even if it requires a bit
> of a hack to get it done.
Yes but how much? We haven't passed this particular test for years. We
have been happy saying we pass the TCK except the one test we expect to
fail because Tomcat always overrides the setting (as allowed for this
feature).
I'd like to pass the TCK but I don't think we need to. If we wanted to
certify Tomcat as compliant then that would be different.
> Some users run Tomcat in STRICT_SERVLET_COMPLIANCE mode. Would that
> auto-deploy some weird TCK-only WAR file into their environments? That's
> obviously not okay to do. I'm not sure I'm fully understanding your
> suggestion.
The suggestion is something along the lines of:
if (STRICT_SERVLET_COMPLIANCE &&
nameOfWar.equals("servlet_spec_defaultcontextpath.war") {
dirName = "defaultContextPath";
} else {
// derive DIR name from WAR name as usual
...
}
HTH,
Mark
>> b) Do we do nothing now and keep this as an option if we get to the
>> point where we do want to fully pass the TCK and certify compliance?
>
> -0
>
>> c) Do we make a formal challenge of the TCK test on the grounds the
>> little documentation there is says the container can override this
>> default so the test is invalid on the basis it doesn't allow for the
>> override?
>
> +0
>
> For many standards, there are "must address" verses "may address"
> line-items. This one seems to be "may address" and I think therefore the
> TCK needs to treat it as such. If the EG chooses not to
> clarify^H^H^H^H^H^H^H change the rules to make this feature required,
> they should change the test such that the TCK report says
> "default-context-path: NOT ADDRESSED (OK)" instead of
> "default-context-path: FAILED".
>
>> Assuming the Servlet team decides to keep the test, I am leaning
>> towards b) or maybe a)
>>
>> Thoughts?
>>
>> The last time we discussed this:
>> https://tomcat.markmail.org/thread/4g7nb36fzf4byrej
>
> -chris
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: default context path
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 11/25/21 17:18, Mark Thomas wrote:
> Hi all,
>
> I am working on updating the Servlet TCK for Servlet 6 and I have been
> discussing with the Jakarta Servlet community whether or not we could
> disable the TCK test that checks default-context-path support.
>
> Tomcat doesn't implement this feature as the container is allowed to
> override this default and we always do - primarily to avoid a bunch of
> edge cases.
Just how dangerous are these edge cases? How are other containers
implementing these safely? Or is it a question of underlying
implementation-specific details that make supporting this safely kind of
a pain in Tomcat?
> Other containers do implement the feature and the preference looks to be
> keeping the TCK test enabled.
>
> If we want to fully pass the TCK, one option is to hard-code the
> deployer to deploy the specific TCK WAR to the correct path if
> STRICT_SERVLET_COMPLIANCE was enabled. This is a fairly ugly hack but it
> would enable Tomcat to fully pass the TCK.
>
> What do we think?
> a) Do we want to fully pass the TCK? Is a hack along the lines I
> described an acceptable way to do this?
I think we'd like to be able to pass the TCK, even if it requires a bit
of a hack to get it done.
Some users run Tomcat in STRICT_SERVLET_COMPLIANCE mode. Would that
auto-deploy some weird TCK-only WAR file into their environments? That's
obviously not okay to do. I'm not sure I'm fully understanding your
suggestion.
> b) Do we do nothing now and keep this as an option if we get to the
> point where we do want to fully pass the TCK and certify compliance?
-0
> c) Do we make a formal challenge of the TCK test on the grounds the
> little documentation there is says the container can override this
> default so the test is invalid on the basis it doesn't allow for the
> override?
+0
For many standards, there are "must address" verses "may address"
line-items. This one seems to be "may address" and I think therefore the
TCK needs to treat it as such. If the EG chooses not to
clarify^H^H^H^H^H^H^H change the rules to make this feature required,
they should change the test such that the TCK report says
"default-context-path: NOT ADDRESSED (OK)" instead of
"default-context-path: FAILED".
> Assuming the Servlet team decides to keep the test, I am leaning towards
> b) or maybe a)
>
> Thoughts?
>
> The last time we discussed this:
> https://tomcat.markmail.org/thread/4g7nb36fzf4byrej
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: default context path
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
We got a similar issue @johnzon and we went with option d) which was to
create a very minimalistic SPI enabling users to get compliance by adding a
jar in the classpath (common.lib for tomcat).
Guess it can be an option enabling any hack (and likely move
STRICT_SERVLET_COMPLIANCE there which would enable servers like tomee to be
compliant with a system prop instead of additional hacks but still aligned
on tomcat behavior by default).
So overall, even if it is not limited to this particular issue, idea could
be to move the compliance hacks in a dedicated SPI and jar.
Hope it makes sense.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le jeu. 25 nov. 2021 à 23:18, Mark Thomas <ma...@apache.org> a écrit :
> Hi all,
>
> I am working on updating the Servlet TCK for Servlet 6 and I have been
> discussing with the Jakarta Servlet community whether or not we could
> disable the TCK test that checks default-context-path support.
>
> Tomcat doesn't implement this feature as the container is allowed to
> override this default and we always do - primarily to avoid a bunch of
> edge cases.
>
> Other containers do implement the feature and the preference looks to be
> keeping the TCK test enabled.
>
> If we want to fully pass the TCK, one option is to hard-code the
> deployer to deploy the specific TCK WAR to the correct path if
> STRICT_SERVLET_COMPLIANCE was enabled. This is a fairly ugly hack but it
> would enable Tomcat to fully pass the TCK.
>
> What do we think?
> a) Do we want to fully pass the TCK? Is a hack along the lines I
> described an acceptable way to do this?
> b) Do we do nothing now and keep this as an option if we get to the
> point where we do want to fully pass the TCK and certify compliance?
> c) Do we make a formal challenge of the TCK test on the grounds the
> little documentation there is says the container can override this
> default so the test is invalid on the basis it doesn't allow for the
> override?
>
> Assuming the Servlet team decides to keep the test, I am leaning towards
> b) or maybe a)
>
> Thoughts?
>
> The last time we discussed this:
> https://tomcat.markmail.org/thread/4g7nb36fzf4byrej
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>