users@javaee-spec.java.net

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

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Fri, 20 Feb 2015 15:43:48 -0800

Jason Greene wrote on 02/20/15 10:56:
>
>> On Feb 19, 2015, at 6:59 PM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
>>
>> In order to tighten the spec and improve application portability, we're going
>> to have to break some non-portable applications and some incompatible
>> implementations. If you think we can never do that, it's going to be very
>> hard to move the spec forward. And if every time we do that we have to add
>> a "compatible with old incorrect behavior" flag, we won't be able to manage
>> the complexity.
>
> I’m not convinced it’s incorrect. The spec states in EE 5.2.5:
>
> "Resource annotations may appear on any of the classes listed above, or on any superclass of any class listed above. A resource annotation on any class in the inheritance hierarchy defines a resource needed by the application component.”
>
> The table referenced defines whats a component and what is not. So from the user’s perspective what they are doing is correct and should be portable.
>
> So perhaps some examples (note I put question marks below because the MR language doesn’t actually define which namespaces our bound for these new non-component classes):
>
> Example 1:
>
> Base.class in ear/lib, defines @Resource(name = “myresource”)
> A.class (an EJB) extends Base in ejb1.jar
> B.class (an EJB) extends Base in ejb1.jar
>
> Before MR, we have two bindings:
> A has a comp entry for “myresource"
> B has a comp entry for “myresource"
>
> After MR, we have three? bindings:
> A has a comp entry for “myresource"
> B has a comp entry for “myresource”
> Base creates java:app/env/myresource?

No, this case is an error. The @Resource annotation attempts to define
an entry in the java:comp namespace, which doesn't exist for libraries.

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

> Example 3:
>
> Base.class (not a component) in ejb1.jar,
> @Resource(name = “java:module/env/myresource”, sharable=false)
>
> 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 an error, since sharable is false?
> A binds:
> "java:module/env/myresource”
> Base binds:
> "java:module/env/myresource”?

No, it's still an error. Libraries don't have a java:module namespace.
Shareable has nothing to do with it. If it had been java:app/env/myresource
with shareable=false, it would be up to the application to ensure that the
resource is used appropriately.

> Example 4:
>
> Base.class (not a component) in ejb1.jar,
> @Resource(name = “myresource”, sharable=false)
>
> M.class (a managed bean) extends Base.class
>
> Before MR we have one binding:
> java:module/env/myresource
>
> After MR we have an error, since sharable is false?
> M binds:
> “java:module/env/myresource”
> Base binds:
> “java:module/env/myresource”?

This should also be an error because Base.class is not a component and
thus has no component namespace.

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.