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