Santiago Pericas-Geertsen wrote on 08/31/12 14:12:
>
> On Aug 31, 2012, at 4:47 PM, Bill Shannon wrote:
>
>>> (ii) Have JAX-RS 2.0 define a small subset of CDI for non-EE
>>> environments. And carefully list the caveats of porting a JAX-RS EE
>>> application into a non-EE environment.
>>
>> I don't think we're planning to subset CDI. The decision to be made
>> is whether the dependency on CDI is hard or soft. If soft, JAX-RS would
>> work without CDI, but some things might have to be done in a less
>> convenient way.
>
> I'm not sure I fully understand the soft case. Less convenient for the developer or the JAX-RS implementor?
Developer. For example, instead of injecting something you might have
to get it from a factory.
>>> I'm not sure what you mean by the statement: "and JAX-RS is fully
>>> functional without injection,". JAX-RS actually depends very heavily on
>>> injection. I may be missing some context here.
>>
>> Are there objects that can only be acquired using injection, and can't
>> be acquired any other way?
>
> Yes, many. First, JAX-RS does HTTP request binding using annotations like @HeaderParam, @CookieParam, etc. I think all these are akin to qualified injections in CDI. Second, specifically about @Context injection, there are several framework-provided context objects that are only accessible via injection, things like UriInfo, Headers, Providers, SecurityContext, etc. In either case, injection can be in constructors, fields, properties and resource method parameters.
I suppose the good news is that JAX-RS is a strong supporter of the
injection approach!
There are tradeoffs between extending JAX-RS along the lines it's already
heading and changing the approach to make better use of CDI.
Just because JAX-RS did some injection before there was CDI doesn't mean
it should do all future injection without CDI.
Just because we now have CDI doesn't mean that all future injection in
JAX-RS should be done with CDI.
We need to look at the advantages and tradeoffs of each approach. If there's
a way to retrofit the existing JAX-RS injection so that it actually *is* CDI
injection, that might be the most attractive.
Probably some of the JAX-RS injectable objects only make sense in a JAX-RS
resource class. Integrating those with CDI is probably less important.
But should some of them be available in any managed bean used by the resource
class? If so, it may be worth integrating those with CDI.
This is not an "all or nothing" scenario. Let's see if we can find some things
that would make sense and be good for developers.