To summarize: - com.sun.ts.tests.jaxrs.ee.rs.core.headers.JAXRSClient#getDateTest_from_s tandalone - com.sun.ts.tests.jaxrs.ee.rs.client.clientrequestcontext.JAXRSClient#ge tHeadersIsMutableTest_from_standalone
=> Can be fixed by upgrading the Java version on the TCK runners. Impl will pass. - com.sun.ts.tests.jaxrs.ee.rs.core.headers.JAXRSClient#getLengthTest_fro m_standalone" => If we use the old conduit, the impl will pass. CXF4 adds a "content- length" header with a value of "0", which makes the TCK fail. Reta (from CXF) will look into it but might be a TCK problem or CXF needs to add a workaround. - com.sun.ts.tests.jaxrs.spec.provider.standardnotnull.JAXRSClient#java#cl ientDataSourceProviderTest_from_standalone => It is an issue in CXF4. They missed a javax reference. I submitted a PR to fix. We have no real regression on the cxf4 branch. The related tck will pass, if the issues above are adressed. Gruß Richard Am Montag, dem 21.08.2023 um 14:48 +0200 schrieb Richard Zowalla: > Test: > com.sun.ts.tests.jaxrs.ee.rs.core.headers.JAXRSClient#getLengthTest_f > ro > m_standalone > > I did some more debugging and the difference is actually the > following: > > This test is setup as follows: > > - TCK sends a GET request to the following endpoint: [1] > - The endpoint returns the "content-length" header value as a String > - The tests parses the body (=the content length value) and checks > for > a value "val != 0": [2] > > If using CXF4 and the new conduit, CXF adds the content-length header > to the request explicitly as we are sending a GET without content: > [3] > This results in CXF4 adding the "content-length" header with a value > of > "0". Consequently, the TCK test will fail. > > In CXF 3.5.x (with the old conduit) the content-length header wasn't > set, so it returns "-1" -> the test passes. > > I don't think, that this test actually makes sense. In slack, Romain > mentioned, that CXf might have challenged this test, but I couldn't > find a related challenge. Does anybody know anything about it? > > [1] > https://github.com/jakartaee/platform-tck/blob/9.1.x/src/com/sun/ts/tests/jaxrs/ee/rs/core/headers/HttpHeadersTest.java#L202 > [2] > https://github.com/jakartaee/platform-tck/blob/9.1.x/src/com/sun/ts/tests/jaxrs/ee/rs/core/headers/JAXRSClient.java#L255 > [3] > https://github.com/apache/cxf/blob/main/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HttpClientHTTPConduit.java#L462 > [4] > https://github.com/apache/cxf/blob/59641959edcfaa379dba7d0adaca11e88c3cff7a/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/HttpHeadersImpl.java#L334 > > > Am Montag, dem 21.08.2023 um 13:53 +0200 schrieb Richard Zowalla: > > > > The test > > > > com.sun.ts.tests.jaxrs.ee.rs.core.headers.JAXRSClient#getLengthTest > > _f > > ro > > m_standalone > > > > fails due to the switch from `URLConnectionHTTPConduit` to > > `HttpClientHTTPConduit` (didn't debug deep into it but might be > > related > > to the fact, that content length is not mandated for h2) > > > > The conduit is hardcoded in cxf4: > > https://github.com/apache/cxf/blob/e2538a8919311c3fe7e4e9ec634a8d9d4cb62cbb/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HTTPTransportFactory.java#L236 > > > > I locally introduced a property in cxf4 to switch the conduit and > > the > > test passes. > > > > I am wondering, what would be the best way to proceed? > > > > > > Am Freitag, dem 18.08.2023 um 21:42 +0200 schrieb Richard Zowalla: > > > After some more digging: > > > > > > com.sun.ts.tests.jaxrs.ee.rs.core.headers.JAXRSClient#getDateTest > > > _f > > > ro > > > m_ > > > standalone > > > com.sun.ts.tests.jaxrs.ee.rs.client.clientrequestcontext.JAXRSCli > > > en > > > t# > > > ge > > > tHeadersIsMutableTest_from_standalone > > > > > > are failing on the TCK / AWS environment due to an old version of > > > the > > > JDK (11.0.10). The background is, that CXF 4.0.2 introduced a new > > > conduit and forces the usage of the default http client of the > > > jdk. > > > > > > As the TCK sends a "Date" header, which counts as restriced in > > > older > > > JDK versions, the tests fail. In recent JDK versions (>11.0.14), > > > the > > > restrictions were opened and the "Date" header isn't restricted > > > anymore. > > > > > > So if those tests are run with a newer JDK version, they are > > > passing. > > > > > > So we are done to 2 failures: > > > > > > com.sun.ts.tests.jaxrs.ee.rs.core.headers.JAXRSClient getLength > > > Te > > > st > > > _ > > > from_standalone FAILED > > > > > > com.sun.ts.tests.jaxrs.spec.provider.standardnotnull.JAXRSClient > > > clientDataSourceProviderTest_from_standalone FAILED > > > > > > The branch is on the TomEE repo here: [3]. > > > > > > I will try to look at those tests in the next days but any > > > additional > > > thoughts on them are warmly welcome ;) > > > > > > Gruß > > > Richard > > > > > > [1] > > > https://github.com/openjdk/jdk11u/commit/86cd9ba29d329a8fa310709c443e53e94888a517 > > > > > > [2] > > > https://github.com/apache/cxf/commit/9b36a4bc996615e0ed02795c74167586a2bb11df > > > > > > [3] https://github.com/apache/tomee/tree/cxf4 > > > > > > > > > Am Freitag, dem 18.08.2023 um 14:59 +0200 schrieb Richard > > > Zowalla: > > > > Jon triggered a run on tck.work for that branch [1] (thx!!) and > > > > we > > > > have > > > > only 4 regressions from the upgrade. > > > > > > > > Will have a look into those failures and see, if I can find out > > > > something useful. > > > > > > > > > > > > [1] > > > > https://tck.work/tomee/tests?path=com.sun.ts.tests.jaxrs&build=1692359054645&status=FAILED > > > > > > > > > > > > Am Freitag, dem 18.08.2023 um 11:47 +0200 schrieb Richard > > > > Zowalla: > > > > > Now I actually also ran my local setup again with 9.1.1- > > > > > SNAPSHOT > > > > > which > > > > > we know passes the TCK for EE 9.1. > > > > > > > > > > The result is: 2708 | 95 > > > > > > > > > > This suggests that my local setup is a bit wonky as the same > > > > > tests > > > > > are > > > > > failing ;) > > > > > > > > > > It would be great if someone could take my CXF4 branch and > > > > > run > > > > > the > > > > > EE > > > > > 9.1 TCK against it once. > > > > > > > > > > Gruß > > > > > Richard > > > > > > > > > > Am Donnerstag, dem 17.08.2023 um 17:29 +0200 schrieb Richard > > > > > Zowalla: > > > > > > > Hi, > > > > > > > > > > > > > > I've been doing some work to get rid of our cxf-shade and > > > > > > > migrate > > > > > > > to > > > > > > > cxf 4.0.2. The branch is here: [1]. > > > > > > > > > > > > > > Our own build is in progess and I expect some failures > > > > > > > due > > > > > > > to > > > > > > > missed > > > > > > > dependencies in test setups: [2] > > > > > > > > > > > > > > I did run the jaxrs part of the TCK (ee91) against my > > > > > > > branch > > > > > > > locally > > > > > > > and it looks promising but (as expected) we have some TCK > > > > > > > regressions > > > > > > > (*meh*): > > > > > > > > > > > > > > Completed running 2803 tests (1:34:15.098): > > > > > > > > > > > > > > Passed: 2706 > > > > > > > Failed: 97 > > > > > > > Errors: 0 > > > > > > > > > > > > > > > > > > > > > In the past, my local tck setup sometimes failed for > > > > > > > tests, > > > > > > > which > > > > > > > > > > > > > > > were > > > > > > > ok on other systems. Maybe someone can confirm, that > > > > > > > these > > > > > > > tests > > > > > > > are > > > > > > > actually failing for them too? Here is my list: [3] > > > > > > > > > > > > > > For reference I did run > > > > > > > > > > > > > > rm -rf target/ && ./runtests - > > > > > > > Dhttps.protocols=TLSv1.1,TLSv1.2 > > > > > > > -- > > > > > > > ee91 > - > > > > > > > j --env -nc -c -w tomee-plume com.sun.ts.tests.jaxrs > > > > > > > > > > > > > > Any feedback welcome. > > > > > > > > > > > > > > Gruß > > > > > > > Richard > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] https://github.com/rzo1/tomee/tree/cxf4 > > > > > > > [2] > > > > > > > https://ci-builds.apache.org/job/Tomee/job/pull-request-manual/15 > > > > > > > [3] > > > > > > > https://gist.github.com/rzo1/efbfbf568e7101842d3ffab2fdb38a3b > > > > > > > > > > > > > > >
