[javaee-spec users] [jsr366-experts] Re: Compatibility Problems with MR Resource Annotation Widening

From: Jason Greene <>
Date: Fri, 27 Feb 2015 11:51:10 -0600

> On Feb 26, 2015, at 9:02 PM, Jason Greene <> 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.

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.

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.

Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat