Hi Santiago
Sorry for not replying in context, haven't set up an email client
properly on the new laptop yet.
What I meant was that users who use Spring or Blueprint(OSGI) they will
not use CDI, they have JAX-RS supporting @Context just fine which is
about representing the request properties, while they use
Spring/Blueprint to do the traditional dependency injection. Therefore
MVC spec is not for them, but JAX-RS alone is for them so we have a case
of some potential MVC (specifically the spec as opposed to the
alternative MVC support, see below) audience dropping off automatically.
I thought I;d say in the scope of this thread because similarly one
would say the same about injecting new custom contexts with CDI only
(i.e - not for non-CDI users).
I recall we talked about AngularJS being not the only way to do views
with MVC being an alternative - similarly people do not use only CDI to
do the injection. But I did refer to the fact JAX-RS is an EE spec
because it can justify in principle at least restricting the future work
(such as supporting custom contexts, MVC) to CDI only at the cost of
some users migrating away. Sorry if I lost everyone :-)
Re the parameters - I agree, I was not suggesting CDI should inject the
parameters. My argument about parameters was not really useful.
But I'm indeed curious what Marek thinks about using CDI for the purpose
of supporting @Contexts. If it were possible then it would be the
perfect compromise. RI can use CDI/DI only to support @Inject/_at_Context
interchangeably and not worry about building something 'parallel' around
supporting @Context
Sergey
On 07/08/15 16:23, Santiago Pericasgeertsen wrote:
> Sergey,
>
>> 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.
>
> I don’t understand this point. All you need to do is properly support
> CDI and that’s it. In any case, this is not a JAX-RS discussion.
>
>>
>> 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).
>
> Think about it. How can CDI inject parameters in a method that it
> isn’t suppose to call? How/why should CDI call a resource method?
>
> CDI supports parameter injection in constructors and other things it
> has control over. Could CDI provide some utilities to help JAX-RS call
> the method and inject parameters? Yes, in fact, we had some
> discussions with them about this.
>
> In summary, this is “hybrid” by nature, although some help from CDI
> would possible. E.g., a method in BeanManager to invoke another bean
> method with “injection capabilities”.
>> 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).
>
> I’m not familiar with this, perhaps Marek can comment.
>
> Thanks.
>
> — Santiago
>
>> *From:* Santiago Pericasgeertsen <santiago.pericasgeertsen_at_oracle.com
>> <mailto:santiago.pericasgeertsen_at_oracle.com>>
>> *Sent:*07 August 2015 14:47
>> *To:*jsr370-experts_at_jax-rs-spec.java.net
>> <mailto:jsr370-experts_at_jax-rs-spec.java.net>
>> *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
>>> @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 seehttps://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
>>> <mailto:marek.potociar_at_oracle.com>>
>>> Sent: 15 July 2015 13:57
>>> To:jsr370-experts_at_jax-rs-spec.java.net
>>> <mailto: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
>>>> <mailto: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
>>>> <mailto:sberyozkin_at_talend.com>>
>>>> Sent: 24 June 2015 13:19
>>>> To:jsr370-experts_at_jax-rs-spec.java.net
>>>> <mailto: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
>