users@javaee-spec.java.net

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

From: Jason T. Greene <jason.greene_at_redhat.com>
Date: Fri, 6 Mar 2015 01:58:06 -0500 (EST)


> On Mar 5, 2015, at 7:28 PM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
>
> Jason Greene wrote on 03/05/2015 04:04 PM:
>> Looking into the weld history, it turns out that the CDI RI did subsequently
>> add everything (method support etc) except for the class annotations bit.
>
> So maybe there's only a small implementation bug?
>
> My expectation (based on the wording in Chapter 8 of the platform spec)
> was that CDI didn't need to know anything about these class level annotations
> because the deployment process would scan all classes and find them and
> process them at deployment time. I think that's what's happening in the RI,
> so I don't think the RI needs Weld to tell it anything about them.

Well the problem is still that if you go by table 5-1, only CDI managed beans should be eligible, and to know that you need to evaluate the rules according to CDI.

>
>
> Would you care to summarize where we are now? :-)

Yes, if you don’t mind I’ll just put it all in this email, instead of replying in piece-meal.

In a nutshell, we have a big mess :) Cleary the contradictions in the various specs have lead to a mishmash of differing behavior.

- Some of us are doing this at a component level (JBoss, IBM, JonAS). Some everywhere (RI, Geronimo).

- Resource bindings on CDI managed beans seem universally broken in ejb jars and ear/lib. On JBoss/WildFly they are not done at all. On the RI they appear ignored if they are in comp. Since the CDI spec itself, and a lot of existing code do not define a name value with resource, those resources are all in comp.

- On JBoss/WildFly, Resource bindings on @ManagedBean default to java:module (based on our interpretation of MB 2.1.2 and or expectation that a defaulted @Resource should not fail). The RI on the other hand stuck with a uniform interpretation of them being in comp, which is consistent with the 250 javadoc. Since comp is ignored on non-components, it also does not fail.

- ejb-jar.xml only allows DD ref overrides on ejbs and interceptors, so managed beans and CDI managed beans can’t be overridden there (portably)

- metadata-complete isn’t accurate with the latest definitions to the EE spec, since not all components are described in DDs (Managed Beans, CDI, Web Sockets, JAX-RS, etc). You can’t implement an EE7 container without processing annotations.

- CDI portable extensions probably need additional environment clarifications (and probably other extension mechanisms, e.g. web sockets extensions)

>
> What do you think *should* work (even if some implementations are broken)?

I strongly feel we shouldn't break any vendor's compatibility to fix this in EE7. We should do minor stuff that gets us closer.

However, even with EE8, I think that the inheritable nature of Resource annotations makes it too problematic to apply across the board to all classes. Further, I think inheritable behavior is a necessity, since the active relative context always applies to the subclass.

Specifically I think:

- The default namespace for binding names should be comp if there is a component namespace, otherwise module if there is a module namespace, otherwise app.

- Resource annotations should only create bindings on component classes (and their supertypes). This avoids optional or disabled code from creating bindings.

- Either the existing all classes scanning mode in beans.xml, or applying a component annotation can be used to expand this to almost everything.

- We should enhance ejb-jar.xml to allow module level overrides.

- We should deprecate metadata-complete.


--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat