[jax-rs-spec users] Re: Using ContextResolver for getting custom contexts injected

From: Sergey Beryozkin <>
Date: Fri, 7 Aug 2015 15:06:09 +0000

Hi Santiago

Many thanks for all the comments, I think I may need to think a bit more about what I can reasonably dispute, few basic thoughts so far,

I guess @Context is the lowest portability denominator as far as the injection of JAX-RS contexts is concerned. For example, as far as MVC is concerned, all we can say to our large community of users who use Spring and Blueprint is well, MVC is not for you, continue using a CXF specific Request Dispatcher support or whatever else you use for binding the data to views. Of course one can always say JAX-RS is a EE spec.

You've mentioned that JAX-RS frameworks itself would need to take care of having a parameter injection with @Inject working. That is not CDI any longer but a hybrid (CDI does the injection of properties/fields, JAX-RS - of parameters).

I'm actually not sure that supporting @Context to get some new custom context injected means competing with CDI. I guess @Context would have to be supported for a while, and from the Jersey docs I can see CDI/etc can react to custom context annotations. So perhaps one idea can be to get JAX-RS frameworks like Jersey use CDI/etc such that it reacts to @Context the same way it reacts to annotations like @SessionInject (as in Jersey docs).

Cheers, Sergey

From: Santiago Pericasgeertsen <>
Sent: 07 August 2015 14:47
Subject: Re: [jax-rs-spec users] Using ContextResolver for getting custom contexts injected

Hi Sergey,

 Well, this certainly connects with the other MVC discussion we’ve been having :)

So suppose, taking the earlier example from Bill where he wanted to inject an OIDC ID Token using a standard mechanism, if we could do with @Context (which as far as I understand all JAX-RS 2.0 implementations can do, they use their own specific solutions to support custom contexts via @Context):

MyResource {
@Context IdToken token;
// or
public Response get(@Context idToken token)

Can the parameter injection (a standard JAX-RS 2.0 feature) work with CDI Inject ?

 There is no support for this type of parameter injection in CDI. But even without it, JAX-RS implementations _could_ support it in the same way they do @Context, with the difference that the injected bean should be created using CDI. In other words, JAX-RS is responsible for calling the method and injecting any required beans in this case.

Even if it can: the request context injection is a 'core' feature of JAX-RS. Should the core feature now depend on CDI ? I'm worried about the overall push to have CDI as a prerequisite (eg. MVC).

 Aren’t you (more) worried about multiple injection frameworks within the same app? CDI is used by lots of other frameworks and applications. Why should JAX-RS continue to develop its own injection framework at this point?

Section 10.2.7 of JAX-RS 2.0 spec says:
"Implementations MUST NOT require use of @Inject or @Resource to trigger injection of JAX-RS annotated fields or properties. Implementations MAY support such usage but SHOULD warn users about non-portability.".

As far as JAX-RS 2.0 is concerned it still supports @Context, right ?
I see

 @Context is still supported.

not even using @Context, all @Inject/etc. The Jersey IOC will still support Context I assume.
So having:

@Context UriInfo uirInfo;
@Inject IdToken idToken;

would look bizarre IMHO where some parts of the requests are represented by contexts injected with @Context and some - with @Inject.

 You already see that, all the time. I think you’re forgetting that CDI is used by applications for their own beans as well,

 @Context UriInfo uriInfo;
 @Inject MyBean myBean;

 That is, CDI is not limited to managing framework beans. Any enhancement in the DI area in JAX-RS should be to “align" and not “compete" with CDI.

— Santiago

From: Marek Potociar <<>>
Sent: 15 July 2015 13:57
Subject: Re: [jax-rs-spec users] Using ContextResolver for getting custom contexts injected

Hi Sergey,

I would instead suggest people to turn to CDI if they need custom injection. I’m not convinced that we should do any additional work on JAX-RS specific injection now that DI and CDI is around. Better DI and CDI integration is, of course a different question - we should invest into improvements on that front IMO.


On 29 Jun 2015, at 14:12, Sergey Beryozkin <<>> wrote:

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...


From: Sergey Beryozkin <<>>
Sent: 24 June 2015 13:19
Subject: Using ContextResolver for getting custom contexts injected


is there any reason why the spec can not be enhanced to support using ContextResolver to have the custom contexts injected:

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 ?