[cdi-dev] Proposal for global CDI enablement

Thu Dec 20 05:01:19 EST 2012

On 20 Dec 2012, at 08:35, Mark Struberg wrote:

> 
>> 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).
> 
> 
> wohuuuuuuu, finally my dream became true!
> 
> I've been rambling over the auto-bean-pickup since years :D
> 
> My proposal: 
> 
> 
> If we detect 
> 
> 
> <beans version="1.1">... 
> 
> 
> or a higher version, we disable this auto pickup for this BDA in the scanning.

So far, this does seem to be the consensus :-)

> We could btw also move CDI-18 'global enablement' to this condition.
> 
> LieGrue,
> strub
> 
> 
> 
> ----- Original Message -----
>> From: Pete Muir <pmuir at bleepbleep.org.uk>
>> To: cdi-dev <cdi-dev at lists.jboss.org>; jsr342-experts at javaee-spec.java.net
>> Cc: 
>> Sent: Monday, December 10, 2012 2:52 PM
>> Subject: [cdi-dev] Proposal for global CDI enablement
>> 
>> I've been working with the Bill and Linda, the Java EE spec leads, as well 
>> as with Jason, Stuart and Emmanuel at Red Hat, to come up with a proposal for 
>> global enablement for CDI in Java EE 7. Based on Linda and Bill's poll of 
>> the community, this appears to be much more popular than we had previously 
>> thought, so we have decided to propose it, despite it being quite late into the 
>> spec development. I think what we have come up with represents a good approach 
>> to achieve it, and also addresses a long requested feature request, that CDI 
>> should not consider every class a bean. Please let us know your thoughts. If you 
>> aren't on the Java EE EG, or the observers list, or the same for CDI, then 
>> please say, and I'll forward your thoughts.
>> 
>> --------------------------------
>> 
>> Background
>> -----------------
>> 
>> Globally enabling CI would allow other specifications in the Java EE platform to 
>> rely on CDI, and not have to provide an abstraction over DI services, such as 
>> those introduced by JSF managed beans, and considered by JAX-RS, Batch and 
>> others.
>> 
>> 
>> Challenges
>> ----------------
>> 
>> * The startup time of Weld is O(n) with the number of beans. We assert that it 
>> is not possible for a CDI impl to attain an O(1) startup time, therefore 
>> globally enabling CDI will increase the startup time of Java EE servers. For Red 
>> Hat, low startup time is a top priority.
>> * Compatibility with other users of JSR-330. By considering all deployments as 
>> CDI deployments without any enablement marker, we will likely cause deployments 
>> which used another JSR-330 implementation to fail. This would have worked on 
>> Java EE 6. Other JSR-330 impls that fall into this camp are Spring and Guice.
>> * Backwards compatibility. Some users may have intentionally not placed a 
>> beans.xml into a deployment, but used CDI annotations, and enabled the beans 
>> some other way, eg. via a portable extension.
>> * A large proportion of Java EE users 800/1000 indicate they want this feature, 
>> thus meaning we should try to address it
>> 
>> 
>> Proposed solution
>> -------------------------
>> 
>> 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?
>> 
>> ---------------------------------
>> 
>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev