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: Wed, 04 Mar 2015 16:59:44 -0800

Jason Greene wrote on 03/02/15 15:09:
> The only code thats allowed to execute from a CDI perspective, is the
> portable extension class, which uses the service loader mechanism. Only when
> deployment has completed can code in the CDI component classes execute.

Right, but what is a portable extension allowed to do? Can it call
web services? EJBs? In the same app? Can it access the database?
Do JNDI lookups? Create threads? What resources are available?
All of this really needs to be fully specified.

>> The inconsistency we're trying to clarify is between Chapter 5, which says
>> that resource definition annotations can only appear on container-managed
>> classes, and Chapter 8, which says that all classes must be scanned for
>> annotations that specify deployment information.
>>
>> As I explained, there's some spec requirements, and use cases, that can't
>> be implemented properly unless all classes are scanned. That's why it
>> seems to us that this is just a clarification, not a change, and not an
>> expansion in scope.
>
> I guess I just don’t agree that having to scan an annotation means you have
> to define a component. To me this seems to be a bit of a false dichotomy. We
> can certainly improve things without making every Java class a component.

We're not making every Java class a component. Why do you think we are?

>> If, in fact, the CDI implementation is discovering all the CDI managed
>> beans at deployment time, and communicating that information to the
>> container so that it can discover all the resource reference and definition
>> annotations on those classes, we may be closer than I thought. Is CDI/Weld
>> doing that?
>
> Yes but only for valid injection points, so if its not a Resource producer
> then it wouldn’t be in that particular callback. That said the EE container
> can participate in a number of ways as part of the process. And the SPI could
> also be extended further.

So CDI managed beans that contain @DataSourceDefinition annotations
aren't being reported to the container? How does the container find
those annotations if it's limiting itself to only the classes supporting
injection?

And since the spec clearly says that CDI managed beans support resource
injection, they need to support all aspects of resource injection defined
by the platform spec, not some limited cases related to CDI producers.

>> If so, then we know that all the other classes don't support injection,
>> and thus shouldn't contain any annotations specifying injection. If they
>> did, and those annotations were ignored, that might be a gap we could live
>> with.
>>
>> That leaves us with these other classes specifying resource references or
>> definitions at the class level. Since these classes can use JNDI to look
>> up these resources at runtime, it seems perfectly reasonable for them to be
>> able to specify resource references or definitions. You have to scan all
>> the classes to find all the class level annotations anyway, so discovering
>> these class level annotations should be essentially no additional cost. It
>> seems like this is a perfectly reasonable use case that should work, and as
>> we saw from my earlier poll, many developers expect this to work. And it
>> works in the RI.
>
> 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) .

I tested it and it seems to be working for me.

Again, what started us on this path is some bugs in the way GlassFish is
handling some of this stuff, so we know it's not perfect. But in this case
it seems to be doing what we expect.