I think what I'll do on my side is dig into the details of another test. A good chunk of the effort is just trying to understand what the test expecting and how. You're definitely more in tune with the CXF internals, but I can probably do that and try and copy the test case pattern you used. That might make for a good way to get through these really quickly (or at least quicker).
Thank you so much for all the help, Andriy! -David > On Apr 22, 2021, at 7:44 PM, David Blevins <david.blev...@gmail.com> wrote: > >> On Apr 22, 2021, at 6:38 PM, Andriy Redko <drr...@gmail.com> wrote: >> >> You are very fast :-D I found the problem but I don't know yet what is >> happening in details. The test >> fails not because of ContextResolver but the presence of TckJaxbProvider. So >> what is happening, on the reading >> side, the CXF's JAXBElementProvider take precedence over TckJaxbProvider, >> but on the write side, this is not >> the case, TckJaxbProvider is picked up. The effect we see is that >> unmarshaller is not needed / called, and >> TckJaxbProvider just dumps "OK" into response stream. I am able to reproduce >> it with test case (I could share >> with you, didn't commit it since it fails) but I haven't yet pinpointed the >> cause, still lookin. > > That's very interesting. What I'm seeing in the TomEE integration is that > TckJaxbProvider is 1st in the ServerProviderFactory.messageReaders list and > JAXBElementProvider is 8th in the list. I'm not sure if there is any sorting > behind this order or if it's just the order things are found on the > classpath, whatever that may be. > > The TckJaxbProvider.readFrom is hardcoded to return null, which appears to be > by design of the test as the HTTP message body doesn't actually contain valid > xml and is simply the bare word "anything". As if the test writer was > thinking "doesn't matter, this will be ignored." From there the > Resource.jaxb method is invoked and null is passed in and therefore returned. > No writers are triggered and the test client receives a 204 and fails as it > was expecting a 200. > > I'm not 100% certain by what appears to be the expected behavior/design of > the test case is that the invalid xml is posted by the client is supposed to > be caught and ignored by the TckJaxbProvider. The JaxbContextProvider is > somehow supposed to be found and invoked anyway where it allows > SomeUnmarshaller to create the real request payload of "<SomeUnmarshaller>". > The Resource.jaxb method receives and returns that element and somehow > SomeMarshaller is found and called which turns the "SomeUnmarshaller" > JAXBElement back into invalid xml and appends SomeMarshaller. The test > client looks for 200 and the two strings. > > I am reading tea leaves, however, as I don't know this spec to that level. > There is a not-well-advertised assertions file that tries to explain what > each test is about. > > The implementation-supplied entity provider(s) for > javax.xml.bind.JAXBElement and application-supplied JAXB classes > MUST use JAXBContext instances provided by application-supplied > context resolvers, see section 4.3. If an application does not > supply a JAXBContext for a particular type, the > implementation-supplied entity provider MUST use its own default > context instead. > > - > https://github.com/eclipse-ee4j/jakartaee-tck/blob/8.0.2/internal/docs/jaxrs/JAXRSSpecAssertions.xml#L758-L762 > > It seems to be implying that TckJaxbProvider.readFrom should be called, but > we're supposed to see that it failed to do its job and default to > JAXBElementProvider and therefore all the downstream magic happens. > > Of course, were all that to happen we'd logically be in a spot where > JAXBElementProvider would effectively be seen as "first". You're already > seeing as first (first first, not fallback first) and the test still fails. > > I suspect we might be a couple fixes away from getting this to pass. > > > -David > > > >
smime.p7s
Description: S/MIME cryptographic signature
