Sorry for the delayed reply, response inline.
> On Feb 20, 2015, at 5:43 PM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
>
-snip-
>
>> Example 2:
>>
>> Base.class (not a component) in ejb1.jar, @Resource(name = “myresource”)
>> A.class (an EJB) extends Base in ejb1.jar
>>
>> Before MR we have one binding:
>> A has a comp entry for “myresource”
>>
>> After MR we have two? bindings:
>> A has a comp entry for “myresource”
>> Base creates java:module/env/myresource?
>
> No. Again, it's still an error.
(As a slight tangent, I just tried this on the RI and it works as I would expect (the behavior that is pre-[MR proposal]), Base.class uses the comp namespace of A.class)
But, back to my point; If the MR proposal is supposed to trigger an error, then that would be even less intuitive result, since this new non-component class behavior would be the only scenario that doesn’t support unqualified name attribute values on @Resource.
In all cases things get really bizarre though with the MR proposal, since simply moving an annotation on the same class changes behavior.
Since JSR 250 says:
"Even though this annotation is not marked Inherited, if used all superclasses MUST be examined to discover all uses of this annotation. All such annotation instances specify resources that are needed by the application. Note that this annotation may appear on private fields and methods of the superclasses. Injection of the declared resources needs to happen in these cases as well, even if a method with such an annotation is overridden by a subclass.”
(and when combined with the EE language previously quoted) We know that the following on Base should reference A’s comp:
@Resource(name=“myresource”)
protected DataSource ds;
However, if I simply move that annotation to the top of class (and add the type value of course), there is now an error.
>
-snip-
> Once you start controlling the namespace of resources based on where
> the class is *used* instead of *defined*, it gets very complicated.
> Yes, you can make up some simple cases that might work reasonably,
> but when you examine all the possible cases it's not at all clear
> how it should work.
This is already the case today though. The inheritance model for EE injection annotations is a form of use, since components ultimately define the meaning of the values on their supertypes.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat