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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to