[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:all-tabpanel ]

Pete Muir resolved CDI-321.
---------------------------

    Resolution: Done


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