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
  • No labels

4 Comments

    1. Looks like it. That at least explains how the test passed previously. I was wondering.

  1. 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.

  2. 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...