Hi Marek
I do not understand CDI mechanics really well, sorry, though we do have CXF having the optional JAX-RS 2.0 CDI integration.
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 ?
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).
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
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. Besides a 'Context' annotation name much better reflects the nature of UriInfo or IdToken types.
Can we have a mechanism in 2.1 to inject something like IdToken using @Context as shown in MyResource example above ? If not then I'm afraid then we'd have to start supporting @Inject parameters manually in order to support a JAX-RS context injection into parameters, and that would appear very wrong to me, after all the dependency injection (@Inject) is not about supplying the request parameters
Marek, Santiago, please clarify
Thanks, Sergey
________________________________________
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