Hey David,
Thanks a lot for debugging it, I have few pointers why we have such
ordering of the message body readers / writers, will continue looking into
it over the weekend. Thanks!
Best Regards,
Andriy Redko
On Thu, Apr 22, 2021, 11:24 PM David Blevins <david.blev...@gmail.com>
wrote:
> 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
> >
> >
> >
> >
>
>
