That of course would imply that its JavaDocs would need to be clarified a bit, example, the typical case is where ContextResolver<JAXBContext> is injected and then it is asked to create JAXBContext for a class like Book, etc.
So the text would have to say that it is the resolver specific action as to how to act to contextResolver.getContext(T.class), example, given ContextResolver<JAXBContext> and contextResolver.getContext(JAXBContext.class) returns null, while given ContextResolver<CustomContext> and contextResolver.getContext(CustomContext.class) is expected to return CustomContext.
Besides, the fact ContextResolver can have @Produces does not help as far as its use as a generic context injection mechanism is concerned but again it can be noted which resolvers might want to use @Producers.
It is a bit unfortunate but I guess this would imply a bit of overloading of the original ContextResolver idea. I reckon the careful wording might make it reasonable and save on introducing some new interface/mechanism to support the injection of custom contexts in 2.0. Not insisting but wondering what other think...
Sergey
________________________________________
From: Sergey Beryozkin <sberyozkin_at_talend.com>
Sent: 24 June 2015 13:19
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Using ContextResolver for getting custom contexts injected
Hi
is there any reason why the spec can not be enhanced to support using ContextResolver to have the custom contexts injected:
@Path("rs")
public class Root {
@Context CustomContext context;
}
MyContextResolver implements ContextResolver<CustomContext> ?
It appears some users expect it to work this way ?
As far as I know ContextResolver is mainly used with JAXB providers to help resolve JAXB contexts, but may be it can be reasonable to reuse it for injecting the custom contexts too as opposed to coming up with some new standard mechanism to support the injection of custom contexts ?
Sergey