Jason T. Greene wrote on 03/03/15 20:56:
> So looking at what would be required to make CDI (the spec) fully support EE
> injection I think we would need the following (note this does not include the
> proposed change to make 250 annotations just work everywhere):
We need to distinguish what has to be supported for an application in a
Java EE product, whether that application uses CDI or not, vs. what an
implementation of the CDI spec outside of Java EE has to support. I'm
only talking about the former. If you think the latter is intended to
support some specific use of @Resource, that needs to be fully specified
by the CDI spec. I didn't expect there to be such a requirement.
> 1. Clearly define (in EE and CDI) how the bean scanning mode impacts which
> beans are eligible for EE resource injection.
The CDI spec defines (not as clearly as I would like) how it discovers the
"managed beans".
The platform spec clearly says that CDI managed beans are eligible for
resource injection.
> 2. Define how EE method injection is supposed to work in CDI (e.g. What
> happens with producer methods)
There's not intended to be anything special about CDI. Method injection
works the same no matter what the class is being used for.
> 3. Define how EE resource (et al) class annotations work with CDI (e.g.
> Abstract classes)
This is one of the key things we're trying to clarify with this platform MR.
Chapter 8 says that "all" classes are scanned for deployment information.
Resource references and resource definitions are deployment information.
> 4. Define what happens to the above (1-3) when a bean is @Veteod or an
> alternative
This is one of the gaps between our specs. @Vetoed or alternatives have
no impact on what is scanned for deployment information. The current
spec says that all classes are scanned, but doesn't say anything about
ignoring the information that you find on (e.g.) @Vetoed beans.
We've talked about filling this gap by adding something to the deployment
descriptors that would allow to to specify which resources are available
in which types of deployments or which project stages. We had hoped that
some of this might also have been addressed by the proposed Config JSR.
If you believe that only classes supporting injection need to be considered,
and CDI can tell the deployment process about all the beans it finds, then
maybe this could be made to work. But this brings us back to the question
of how much CDI initialization needs to be done in order to complete the
deployment process, and what environment the CDI portable extensions are
run in if the results of the annotation scanning have not yet been processed.
So anyway, yes, we need to define how we want this to work.
> 5. Define new default namespace rules for CDI (e.g. Module vs App)
If by "default namespace rules" you mean the rules for what namespace
is used when the name doesn't explicitly specify a namespace, we aren't
planning to change that. For simplicity, we've kept the default namespace
as "java:comp/env" everywhere.
What we are trying to clarify is which namespaces can be used by which
classes in which contexts. CDI beans don't have their own component
namespace, so they can't use the default java:comp/env namespace, except
in the web container where all classes are in the java:comp namespace.
Yes, that's a pretty big "except" since that's probably the common case.
If you have suggestions about how to make this more clear than what we've
proposed in the MR, let us know.
> 5. Add support to either beans.xml or relevant ee deployment descriptors to
> allow redefining all names that can possibly be created by @Resource on a CDI
> bean, such that metadata-complete can work. (This would also be needed to
> allow @ManagedBean to work with metadata-complete)
What's an example of something that's currently not possible?
You can define (and thus override) resource references in the application.xml,
the web-app.xml, and the ejb-jar.xml.
> 6. If metadata-complete is really supposed to work universally, then we need
> a complete bean definition language (also needed for @ManagedBean,
> interceptors, and probably many other EE specs)
As above, it was intended to be there. What did we miss?
> 7. Redefine the interaction, or alternatively lack thereof with portable
> extensions.
This is mostly an issue of how portable extensions can influence what's
considered a CDI bean, right? Are there other aspects we need to define?