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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
