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.
>>
>> 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.
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.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com