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