jsr366-experts@javaee-spec.java.net

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

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Thu, 05 Mar 2015 14:38:20 -0800

Jason Greene wrote on 03/05/2015 02:19 PM:
>
>> 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.

It's always an issue when we fix bugs that people might have come to depend
on, perhaps accidentally.

> 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.

The proposed rule is *not* that they default to module. They always
default to java:comp/env. If you want this to work, you have to explicitly
use java:module or higher. Since they're in an ejb-jar file, they do have
a java:module context.

> + 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

Right, it should fail to deploy.

> + 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.

Right.

> + 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.

No, ear/lib classes don't default to java:app, they still default to
java:comp/env.

> 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

Yes, that's weird.

To be clear, I really don't like the way subclassing interacts with all of this.
I think it would be simpler if the namespaces only depended on where the class
was packaged. But that's not the way the spec was written.

Fortunately, I don't expect that people typically do any of the really strange
things that are possible. In the common cases, I think it all works "as
expected". In the unusual cases, people are going to have to understand
these subtleties.

We could explore changing the spec for these unusual cases to "fix" some of
this strange behavior, but I fear that that would make the spec significantly
more complex and thus harder to understand. Maybe only the java:comp
namespace should depend on the subclassing relationships, with java:module
depending only on packaging? It might be more weird that they behave differently.