Hey David,
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.
Thank you!
Best Regards,
Andriy Redko
DB> Thanks for that test case, Andriy! Pulling it down to debug through it to
learn how all this is put together.
DB> Likely there's something unrelated then tripping this up.
DB> -David
>> On Apr 21, 2021, at 8:53 PM, David Blevins <[email protected]> wrote:
>> I'm investigating CXF-8516 (jaxrs.spec.provider.jaxbcontext
>> readWriteProviderTest) and have some questions on ContextResolvers in
>> general.
>> The TL;DR of readWriteProviderTest:
>> - There is an application supplied javax.ws.rs.ext.ContextResolver for
>> JAXBContext
>> - The resolver returns a custom JAXBContext with specialized Marshaller and
>> Unmarshaller
>> - The custom Marshaller/Unmarshaller are hard coded to append their class
>> names to the input and output
>> - The test is expecting to see their class names in the response
>> "SomeUnmarshaller" and "SomeMarshaller"
>> - The resolver is never called, so all of the above never happens and the
>> test fails
>> The test is essentially validating that a user can supply their own custom
>> JAXB marshalling/unmarshalling capabilities, not via custom
>> MessageBodyReader or MessageBodyWriter implementations but by supplying
>> alternate JAXBContext to the built-in JAXB support.
>> In an effort to investigate how we're calling ContextResolvers I decided to
>> find another test that uses them so I could step through, see something
>> working and learn how this should be working in a happy path scenario.
>> Unfortunately, there aren't any other tests that use ContextResolvers quite
>> like this.
>> The only other tests in the entire TCK that use a ContextResolver are in
>> scenarios where there is an `@Context Providers` injection and the test
>> itself is looking up and calling the resolver. The
>> jaxbcontext#readWriteProviderTest is the only test in the entire TCK that
>> expects the server itself to call the provider.
>> I put breakpoints in every area where ContextResolvers are touched
>> (ProvidersImpl, ProviderFactory, ContextResolverProxy, etc,) and wasn't able
>> to learn much, likely because there isn't much coverage in the TCK to
>> trigger those code paths meaningfully.
>> Is there a known feature gap with regards to ContextResolvers? Are there
>> any recommendations on where I'd put in the code to see if we have a custom
>> JAXBContext provider? I suspect it might be tricky as I bet that code is
>> generic and not JAX-RS specific.
>> -David
