On Aug 28, 2012, at 4:29 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> On 8/28/2012 9:43 AM, Marek Potociar wrote:
>> On Aug 28, 2012, at 2:42 PM, Bill Burke <bburke_at_redhat.com> wrote:
>>
>>> Comment on issue too?
>>
>> I think it will be more convenient to discuss via email.
>>
>>>
>>> From a CDI perspective, I'm against this idea as there is already sufficient APIs in CDI:
>>>
>>> #1 CDI's BeanManager interface provides this functionality already
>>> #2 The Sub-resource locator itself could be an injected CDI bean.
>>> #3 Components needed by the sub-resource locator could be injected into the parent and passed in via a constructor or setter methods
>>
>> For some reason I thought you're not a big fan of introducing a hard dependency between JAX-RS and CDI. Are you suggesting we're only supporting this with CDI-based JAX-RS resources? Or would it make sense to specify how BeanManager should be used in the implementation of the API in runtimes where CDI is available/enabled?
>>
>
> Well, the actual JIRA issue talks about CDI specifically. If this feature is going in solely to solve a CDI problem, then I'm against it because the problem doesn't exist.
I get it. Even though this particular issue may seem CDI-focused IIRC the issue priority was set to CRITICAL because the scope of the issue goes beyond CDI and covers problems with sub-resource injection in general (at least based on how Jersey users use the similar API, which seems to correspond with what you had to solve in your impl).
>
>>>
>>> BUT...
>>>
>>> Resteasy does have something similar to access JAX-RS @Context injected things programmatically.
>>
>> Right, as you may have noticed, the proposed API is based on a Jersey-specific API that our users seem to use quite heavily. Also, I think we really need to keep in mind that life's not revolving just around CDI.
>>
>
> What kind of things does jersey use it for? @Context injected things only? Or as an injection abstraction? Resteasy does have a feature like this, but it is a static method that can be used anywhere and doesn't require a @Context injection to get the service. I also kinda want to move away from this as I feel that things like Configurable are filling in the gaps.
In Jersey users typically use it to provision (fully-initialized and properly scoped) sub-resource instances, regardless of what container manages each particular instance, using the ResourceContext.getResource(...) method. Another problem the users are facing is that in many cases if a user wants to support more complex URI spaces, it would make a lot of sense to leverage the JAX-RS matching engine to internally "find" a proper resource instance or information about it. For those cases the ResourceContext contains the matchXxx() methods that expose the matching engine to the end user.
>
>
> FYI, I don't mind you adding this stuff in GIT. It actually makes things clearer if I see the code first. As we saw with the async stuff, its pretty easy to rollback.
Yup. It's convenient. It will be good if we can continue this way.
I just should have done a better job in setting the right expectations for the EG earlier. Hope that things are clear now and people feel comfortable with this approach.
Thanks,
Marek
>
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com