Actually, not sure why I did not reply in scope below, I can do it with
a new client too :-), sorry, see one comment below
On 07/08/15 16:57, Sergey Beryozkin wrote:
> 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
>
With the net effect that well those non-CDI users projects would still
be able to use @Context for getting new custom contexts injected -
should the given framework decide to support such an injection without
CDI...
Either way - enjoy the weekends, all, I'm signing off now...
Sergey
> 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
>>
>