Running
Tomcat
setenv.[sh|bat]
Set the following system properties
- -Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=true
context.xml
Make the following changes:
<Context crossContext="true" resourceOnlyServlets="jsp">
<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor" alwaysAddExpires="true" forwardSlashIsSeparator="false" />
...
</Context>
server.xml
Enable h2c on port 8080, and add some trailer headers
<Connector ... allowedTrailerHeaders="myTrailer, myTrailer2" >
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
</Connector>
Enable TLS on port 8443
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true">
<SSLHostConfig protocols="TLSv1.2" truststoreFile="conf/cacerts.jks">
<Certificate certificateKeystoreFile="conf/clientcert.jks"
certificateKeystorePassword="changeit"
type="RSA" />
</SSLHostConfig>
</Connector>
Note: Set protocols="TLSv1.2" to disable TLSv1.3 since the TCK requires post-handshake authentication and the Java 11 client does not support that.
tomcat-users.xml
Make the following changes:
<user username="CN=CTS, OU=Java Software, O=Sun Microsystems Inc., L=Burlington, ST=MA, C=US" roles="Administrator"/>
<user username="j2ee" password="j2ee" roles="Administrator,Employee" />
<user username="javajoe" password="javajoe" roles="VP,Manager" />
web.xml
Remove the sections setting the default character encoding for requests and responses to UTF-8.
Test Suite
Download the Jakarta Servlet 5.0.0 TCK
https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee9/promoted/servlet-tck-5.0.0.zip
Extract to SERVLET_TCK_HOME
cd $SERVLET_TCK_HOME/bin/certificates
Convert cts_cert to a truststore doing: "keytool -import -alias cts -file cts_cert -storetype JKS -keystore cacerts.jks" password should be "changeit"
Add $SERVLET_TCK_HOME/bin/certificates/cacerts.jks and $SERVLET_TCK_HOME/bin/certificates/clientcert.jks in the Tomcat conf folder
Edit $SERVLET_TCK_HOME/bin/ts.jte
You'll need to set the following properties (adjust the paths and values for your environment)
web.home=/path/to/tomcat
servlet.classes=${web.home}/lib/servlet-api.jar:${web.home}/lib/annotations-api.jar
webServerHost=localhost
webServerPort=8080
securedWebServicePort=8443
command.testExecute += -Djavax.net.ssl.trustStore=${ts.home}/bin/certificates/cacerts.jks
command.textExecute -= -Djava.endorsed.dirs=${endorsedlib.dir} (Java 11 only)
set JAVA_HOME
cd $SERVLET_TCK_HOME/bin
ant gui
Accept the defaults and then run the tests
Expected results
A default 10.0.x build (as of 10.0.0-M10) with the above configuration and the 5.0.0 TCK triggers 1 test failure with the following JREs:
- Adopt OpenJDK 8u275 b01
- Adopt OpenJDK 11.0.9 b11 (TCK and Tomcat)
1 Expected failures
- 1 x default context path test as Tomcat configuration always overrides this
Fixed TCK bugs
- PR 338
- Incorrect major version (1 failure),
- Using LF rather an CRLF (15 failures)
- Strange /j_security_check test (2 failures)
- Missing annotation marker in Java 8 signature tests (1 failure)
- Re-do Java 11 signature test based on Java 8
- Fix regression in error page tests (1 failure)
- Java 11 issues with HTTP/2 client
4 Comments
Olivier Lamy
Error page attributes maybe related to https://github.com/eclipse-ee4j/jakartaee-tck/pull/277
Mark Thomas
Looks like it. That at least explains how the test passed previously. I was wondering.
Remy Maucherat
https://github.com/eclipse-ee4j/jakartaee-tck/pull/338/files#diff-89fad4e6a2e15e52564d819014661653
Ouch ...
For default-context-path, I obviously hate this feature, whatever is done it will have to be a mess. First thing would be to add it to WebXml, the parser and the Context. Then figure out how workable it is to change the mapping.
Mark Thomas
Yep. One of my messier hacks.
I'm not interested in trying to pass the default-context-path test. If ignoring the failure is not an option (and lets be honest when was the last time anyone even asked if Tomcat passed the TCK?) then my first choice would be to challenge the TCK test on the grounds the spec says containers may override it - and Tomcat does. Always.
Don't get me wrong, having access to the TCK is useful - I'm just not particularly hung up on the certification process. If our users change their view on that then I will too. Until then...