Thanks a lot, we have this TCK build on Jenkins [1] which we run regularly, we have 70 failing tests (+2 failures which we know about).
Thanks! [1] https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-TCK/ Best Regards, Andriy Redko AM> Sounds good. I'll try to have a PR tomorrow. The fix is easy enough, but AM> I want to make sure that we have a good test case for it too. AM> Andriy and I (mostly Andriy) were looking at Jakarta TCK issues about a AM> year ago. He has some results posted at AM> https://issues.apache.org/jira/browse/CXF-7996 - in the most recent report, AM> there were ~80 failures, but it's possible that some of them have already AM> been fixed since then. It might help if you post your failures in that AM> issue to keep better track of them. AM> Thanks, AM> Andy AM> On Tue, Apr 13, 2021 at 8:44 PM David Blevins <[email protected]> AM> wrote: >> > On Apr 13, 2021, at 9:10 AM, Andy McCright <[email protected]> >> wrote: >> > >> > Hi David, >> > >> > I had to do some digging - but yes, we addressed that issue in our Open >> Liberty fork of CXF and I must not have contributed that fix back to the >> main CXF fork (apologies for that). >> > >> > Here are the changes I made in the OL fork: >> https://github.com/OpenLiberty/open-liberty/pull/2504 - basically >> deferring the decoding until after the map has been populated. If you >> want, I can try to push this change back to the main CXF fork. >> Thanks for the update, Andy! >> Your patch sounds much better than mine. I was able to get the test to >> pass by effectively keeping two cached copies of the parsed form -- one >> decoded and one encoded. >> - >> https://github.com/apache/tomee/commit/5c47f4482ea80601e17ead56e6f0a72e494a5b7e#diff-472b947a3abe2e03b6959ef6ad4e1137ff3012dee9de1a4c15acf57919ab525bL1027-L1035 >> Works, but feels a little too hacky. If you want to submit a PR for >> yours, that's great. I'll post a list of the remaining 30-ish failures >> that we working through in a separate thread. >> -David
