Re: [cdi-dev] Proposal for global CDI enablement

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. We could btw also move CDI-18 'global enablement' to this condition. LieGrue, strub ----- Original Message ----- > From: Pete Muir <pmuir(a)bleepbleep.org.uk&gt; > To: cdi-dev <cdi-dev(a)lists.jboss.org>; jsr342-experts(a)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 > > > 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev >