> On Mar 4, 2015, at 7:03 PM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
>
> Jason Greene wrote on 03/02/15 16:07:
>>> Glassfish does not appear to be defining bindings on the CDI @Resource
>>> values, unless I am looking at the wrong code, or its duplicated in some
>>> other place (sorry if I am wrong about this, I still haven’t had time to
>>> test it) .
>>
>> Actually I misread, you were clearly talking about class annotations. In that
>> case the MR description behavior you are advocating did not match the
>> behavior I observed there either (I mentioned that in a previous email). It
>> can’t work unless you also fix the way namespaces are handled. Even doing
>> that its going to break compatibility, for largely no reason.
>
> What's an example of something you don't believe is working correctly?
I tested some more variations and it does seem to pick up bindings if they are explicitly set on module or app. If they are defaulted or set to comp it seems to ignore them, unless inherited by a component class (which is why I thought they weren’t working at all after my original test). So if the clarification makes that a failure, as it should be with them getting processed/evaluated/executed then that could be an issue for RI users.
In any case, here are some updated compatibility examples following the latest rules (your algorithm for all classes + default namespaces [relative names end up in module or app depending on location]):
+ Conflict in same jar
--------------------
non-component A in ejb.jar has @Resource(name=“foo”)
non-component B in ejb.jar has @Resource(name=“foo”)
Assume A and B have a different type, lookup, or sharable is false
If these are extended by an EJB they will work, since there is a comp, if they are not extended they default to module and should trigger an error.
+ Previously valid reference to comp
----------------------------------
non-component A in ejb.jar has @Resource(name=“java:comp/env/foo”)
If something extends A, it will work, but if it doesn’t, and is just a stale reference (perhaps after a past refactor, or maybe its just a test calls only enabled during staging) it should fail since non components don’t have a comp
+ Lookup failure
--------------
non-component A in ejb.jar has @Resource(name=“foo”, lookup=“java:comp/env/B”)
If an EJB extends A, it will work, if it doesn’t it will fail.
+ Alternative 250 framework users (Spring)
There is also some interesting problems that occur once you have this all classes behavior, as currently described:
Moving name issue
-----------------
non-component A in ear/lib has @Resource(mame=“foo”)
B in ejb.jar has @Resource(lookup=“java:app/env/foo")
This all works fine until I decide to create an EJB that subclasses A, and now my app/env/foo disappears.
Moving lookup issue
-------------------
non-component A in ejb.jar has
@Resource(name=“java:module/env/foo”, lookup=“java:module/env/bar”)
B in other-ejb.jar extends A
Now bar is expected to be in other-ejb.jar instead of ejb.jar
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat