[cdi-dev] [JBoss JIRA] (CDI-321) Application wide CDI enablement

[Pete Muir (JIRA)]

    [ https://issues.jboss.org/browse/CDI-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12756183#comment-12756183 ] 

Pete Muir commented on CDI-321:
-------------------------------

I've spec'd this out almost exactly as discussed above. The only major change is that I've added that a container must provide a way to completely disable archives which have no beans.xml, in to provide exactly the CDI 1.0 behavior. This is language proposed by Bill Shannon, and can be implemented in anyway the vendor wants (e.g. -D, xml config, property file).

I think my changes make chapter 12 much easier to understand as well.

Pull is https://github.com/jboss/cdi/pull/166
                
> Application wide CDI enablement
> -------------------------------
>
>                 Key: CDI-321
>                 URL: https://issues.jboss.org/browse/CDI-321
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Pete Muir
>            Assignee: Pete Muir
>             Fix For: 1.1.PFD
>
>
> We introduce the concept of a "bean defining annotation" and define that any class in any deployment (including those with no beans.xml) with a bean defining annotation is discovered and may be a CDI bean, and can participate fully in the application. Any archive with a beans.xml continues to work in the same way, such that all classes in the archive are discovered and may be CDI beans.
> This addresses the startup time problem. Whilst a scan of classes is still required, the impact on startup time is negligible:
> * A Java EE server must scan all classes to discover other component defining annotations such as EJBs, Servlet's, JAX-RS resources etc.
> * This scan can be done at the bytecode level, with no need to classload the class, which our research shows is the costly part of CDI startup
> Any scope (normal scope or pseudo-scope) applied to a bean at source level is a bean defining annotation (so you must add @Dependent to your class in order to get it to be picked up as a dependent bean).
> Only classes with a bean defining annotation, or with an annotation, or meta-annotation, present specified by @WithAnnotations are passed to ProcessAnnotatedType observers (the exact semantics are defined by CDI 1.1 PRD for @WithAnnotations). As mentioned above, if a ProcessAnnotatedType is observed for a type without a bean defining annotation, as a result of having an annotation present that is specified by @WithAnnotations, it may instruct the container to add discover the class as a bean.
> Every archive in a deployment would be considered a bean archive, simply with differing contents depending on the presence of beans.xml
> If a developer adds a beans.xml to their archive, behavior is as CDI 1.0. We will add an attribute to beans.xml "auto-discover=true", which the user may set to false in order to add a beans.xml and only have classes with a bean defining annotation discovered, which allows beans.xml to be used as a deployment descriptor but still limit the classes discovered.
> OPEN ISSUE: Should auto-discover be false by default for beans.xml with version 1.1. This would mean that adding a beans.xml would have no impact on discovery for 1.1 apps, however it is a significant change from 1.0.
> OPEN ISSUE: Should only scopes for which a CDI context exists be considered component defining? This could introduce some thorny edge cases, but would address the JSR-330 compatibility issue better.
> OPEN ISSUE: Should we extend auto-discover in beans.xml to allow complete disablement of scanning e.g. auto-discover="all|bean-defining-annotations-only|none" ?
> OPEN ISSUE: How should the ProcessAnnotatedType event instruct the container to discover a class as a bean? Perhaps something like event.discover(clazz)?
> OPEN ISSUE: Should we integrate this with the package level scanning control we have proposed for CDI 1.1?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira