Thanks for that test case, Andriy! Pulling it down to debug through it to learn how all this is put together.
Likely there's something unrelated then tripping this up. -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 >
smime.p7s
Description: S/MIME cryptographic signature
