Sounds good. I'll try to have a PR tomorrow. The fix is easy enough, but I want to make sure that we have a good test case for it too.
Andriy and I (mostly Andriy) were looking at Jakarta TCK issues about a year ago. He has some results posted at https://issues.apache.org/jira/browse/CXF-7996 - in the most recent report, there were ~80 failures, but it's possible that some of them have already been fixed since then. It might help if you post your failures in that issue to keep better track of them. Thanks, Andy On Tue, Apr 13, 2021 at 8:44 PM David Blevins <[email protected]> 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 > >
