> On Feb 27, 2015, at 5:38 PM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
>
> Jason Greene wrote on 02/27/15 09:51:
>>
>>> On Feb 26, 2015, at 9:02 PM, Jason Greene <jason.greene_at_redhat.com> wrote:
>>>
>>> So my recollection, was that this was intentional since the bindings aren’t useful to CDI applications, and you could always reference another binding defined by a component which did support it, if you needed such behavior. The deployment descriptor for CDI doesn’t allow you to override these bindings, and the other deployment descriptor locations don’t cover the full set where @Resource can appear (for example ejb-jar overrides are defined on ejb components and not globally). Finally, @Resource (and the other EE bindings) can only appear on producer fields, which is a subset of what 250 defined.
>>>
>>> I’ll ping Pete to see if he remembers the same, but yeah I agree the combination of the specs implies that it should work, other than the fact that it can’t work the way the global rules are defined.
>>
>> BTW I confirmed that this matched Petes understanding as well.
>>
>> There was never any interest for CDI managed beans to support:
>>
>> - Creation of @Resource (et al) JNDI Bindings
>> - Usage of @Resource (et al) Class declarations
>> - Usage of @Resource (et al) Method injection
>>
>> These all have no benefit to CDI applications because they are all superseded by other constructs. The annotations were just reused for the ties just to avoid creating new ones.
>
> Except that there's nothing anywhere in the spec that says in this specific
> case you don't have to create the bindings that the spec says you have to
> create. And for all the reasons described previously, we would not want
> the spec to say that.
My point is that even if you added in the bindings the semantics are still different. You aren’t really using EE injection (in the traditional sense) when you define @Resource on a CDI bean. You are instead defining a CDI field producer that does a resource lookup. In fact if you just renamed "@Produces @Resource" to be “@Produces @JNDIObject", this confusion likely would have never occurred.
You could add full Java EE injection to CDI managed beans, but it’s a lot of spec work that would serve little purpose. The whole point of CDI is to offer a strong type-safe injection mechanism, and for that reason CDI forces you to minimize your usage of @Resource to a single location that is then @Inject-ed where needed. If we defined the rest, we would end up saying “Hey this never worked before. We made it work now, but still don’t use it.”
I’m hoping we keep the scope limited by either letting CDI have its own semantics, or we change it to define bindings consistent with EE resource injection and stop there.
>
>> In an early CDI draft there was a complete xml description language in beans.xml that could be used to override/define all aspects of CDI managed beans (including annotations). However, that was dropped since portable extensions allowed third party definitions of such a thing.
>
> I only ever expected that to be able to change how @Inject worked, not
> change how @Resource worked, since @Resource was defined by the platform
> spec and not the CDI spec.
>
>> The bindings, if desired for consistency purposes, could be addressed by the EE spec, and the existing CDI RI looks like it already can support that. Class declarations could likewise be addressed, but would probably require some CDI RI SPI improvements. Method injection on the other hand probably would require CDI spec involvement.
>
> The platform spec clearly requires that these bindings are created, always.
>
> If you extract all the annotation information from an application using
> whatever technique you think is correct, turn it into the corresponding
> deployment descriptor information, merge it into the deployment descriptors,
> set metadata-complete, and remove all the annotations from the application,
> will the behavior be the same? It should. That was clearly our intended
> design when we introduced these annotations and extended the deployment
> descriptors to allow injection to be specified.
If you use any element of CDI in your application (whether @Resource is done by CDI or by something else, or not used at all) then no. CDI does not define an xml format that can substitute all usage of its annotations. You could do it with a portable extension that defined one though.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat