> 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
