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
> @GET
> 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 https://jersey.java.net/documentation/latest/ioc.html <https://jersey.java.net/documentation/latest/ioc.html>
@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 <marek.potociar_at_oracle.com>
> Sent: 15 July 2015 13:57
> To: jsr370-experts_at_jax-rs-spec.java.net
> 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.
>
> Cheers,
> Marek
>
>> On 29 Jun 2015, at 14:12, Sergey Beryozkin <sberyozkin_at_talend.com> 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...
>>
>> 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
>