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

From: Bill Shannon <>
Date: Mon, 16 Mar 2015 13:39:41 -0700

I'm finally picking up this conversation again after several days of
vacation and catch-up...

Jason T. Greene wrote on 03/05/15 22:58:
>> On Mar 5, 2015, at 7:28 PM, Bill Shannon <> 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.

Yes, the confusion is that 5-1 is only supposed to be telling you where
injection works, because obviously injection can only work on classes that
are managed by the container. It was not intended to be telling you
where resources can be defined.

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

Yup! And we'll all be better reviewers of the spec in the future, right? :-)

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

Ya, that was way wrong. MB.2.1.2 says nothing about @Resource names.

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

At one point we planned to address this by adding the ability to specify
module-level resources in the ejb-jar.xml not associated with any EJB
component. I don't remember why that got dropped, but maybe it's time
to bring it back.

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

metadata-complete was never intended to say that. It only ever talks
about how the deployment process uses metadata-complete when looking for
deployment information. There's lots of other uses of annotations that
have nothing at all to do with deployment. The spec even says explicitly
that other specs that also use annotations and xml descriptors might want
to define their own metadata-complete.

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

We can defer some of these changes, but if that means another 3 years of
inconsistent behavior, I'm worried that we'll never be able to fix it.

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

I think it's too late to change this, and I'm not convinced that having
different defaults in different cases wouldn't be more confusing.

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

I'm really torn on the two above. My original goal was that deployment
did *NOT* need to run any application code. Running CDI bootstrapping
during deployment really messes that up. I should be able to deploy an
application without starting it, and not have to create any class loaders
or initialize any containers for the application.

The disadvantage of this approach is that the deployment process doesn't
have access to all the information that CDI collects, and so can't tell
which beans are actually usable. Again, our original plan was to expose
some of these capabilities in the deployment descriptors. We probably
need it there anyway for lots of cases that don't involve CDI.

So, while I see the attraction of using the results of the CDI bootstrap
at deployment time, I think it's simpler if we don't have to do that.
I need feedback from the expert group on what the right approach is here.

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


> - We should deprecate metadata-complete.

We're not going to do that.