Because of caching in XmlJAXBContextFinder (see XmlJAXBContextFinder.findCachedContext()) user can't define two ContextResolver<JAXBContext> for a same generic container type on two separate webTarget instances (see XmlJAXBContextFinderTest.java).

The goal of ContextResolver is to let user provides context information to a provider. So if registered by user it must be called and taken into account by the provider. Plus, there is nothing nothing preventing the user from registering two ContextResolver<JAXBContext> on totally separate webTarget instances (one is not inheriting from the other so https://issues.jboss.org/browse/RESTEASY-1284 does not apply).

Maybe it would have been better, to always call user custom ContextResolver<JAXBContext> first and not cache JAXBContext instance coming from them. Only JAXBContext created by XmlJAXBContextFinder.createContext should be cached.

Doing that it's up to the user implementing its own ContextResolver<JAXBContext> to also implement similar kind of cache mechanism as it is done in XmlJAXBContextFinder or any JAXBContext lazy loading pattern just like in the test example.