Last week the JCP posted the CDI 1.1 public review draft. This draft continues to incrementally improve the 1.0 spec. We haven't added any major new features, instead we're concentrating on honing 1.0 :-)
- The CDI class, which provides programmatic access to CDI facilities from outside a managed bean
- Ability to veto beans declaratively using @Vetoed
- Conversations in Servlet requests
- Application lifecycle events in Java EE
- Injection of Bean metadata into bean instances
- Programmatic access to a container provided Producer, InjectionTarget, AnnotatedType
- Ability to override attributes of a Bean via BeanAttributes
- Ability to process modules via ProcessModule
- Ability to wrap the InjectionPoint
- Honor WEB-INF/classes/META-INF/beans.xml to activate WEB-INF/classes in a bean archive
- Global ordering and enablement of interceptors and decorators
- Global selection of alternatives
- @New deprecated
- Clarify interceptors and decorators must be implemented using proxying
- Allow multiple annotated types per Java class
- Allow Extensions to specify the annotations that they are interested in
There are a number of open issues about which we would appreciate your feedback:
Bean visibility
The CDI 1.0 specification clearly states that only beans whose bean class is accessible (using standard classloader visibility rules) can be injected into another bean. For example, if you have a bean A in WAR, assuming standard Java EE classloader structure, it wouldn't be available for injection in bean B, in an EJB module. This generally makes sense, as the type is not visible either.
CDI also offers two options to replace bean implementations transparently, without explicitly selecting that implementation (either by type or using a qualifier) - alternatives and specialization. In this case, it is less clear that the bean class of the specializing bean, or the bean class selected alternative, must be visible.
The CDI EG is still debating this issue, including whether to offer a backwards incompatible mode here.
@ApplicationScoped beans shared between all EAR modules
CDI implementations have not consistently shared @ApplicationScoped beans across all modules of an EAR. This issue heavily relates to Bean visibility. The CDI 1.1 specification will clearly state how @ApplicationScoped are shared.
Startup event
A commonly requested feature is for the application to be able to do some work once the application has started but before it starts servicing requests originating remotely. Currently CDI 1.1 defines a @Initialized(ApplicationScoped.class) which is called when the application context starts, but we are investigating whether this can be extended to provide a more general startup event.
If we define such an event, we need to allow custom contexts to activate themselves whilst it is executing, however this is likely beyond the scope of CDI 1.1 and will likely be addressed in CDI 2.0.
@WithAnnotations
CDI 1.1 adds @WithAnnotations which allows an extension observing ProcessAnnotatedType to filter which types it sees. We would like to provide such functionality for all container lifecycle event observers, but there are some interesting things to consider, including whether it would be better to filter on qualifiers for later events. CDI 1.1 may or may not add such support, and we are looking for feedback on this.
Allowing arrays as qualifier members
CDI 1.0 requires array valued members of qualifiers to be annotated with @Nonbinding, excluding them from the resolution process. The JDK defines that annotation equality for array valued members should use Arrays.equals(), which requires two identical arrays (equal values, in the same order) in order to return true.
We feel that to make array valued members of qualifiers useful, we need to offer a pluggable strategy for checking equality of arrays, as often it would be desirable to consider two arrays with the same values, in any order, as equal. We intend to add this for CDI 1.1.
Restricting what CDI scans
CDI 1.0 will scan all classes in a jar with beans.xml. We plan to add a syntax to beans.xml that will the application developer to exclude classes using a variety of filtering options (e.g. by package). Weld offers such a syntax, and will be used as a starting point for CDI http://docs.jboss.org/weld/reference/1.1.5.Final/en-US/html/configure.html#d0e5769.
Observer resolution
CDI 1.0 requires the type used for observer resolution to be based on the runtime type of the event object. Unfortunately, the JDK erases generic type information about objects that we need to allow firing of many events with parameterized types. CDI 1.0 also completely ignores the generic type of the injected event object, which does typically contain the needed type information. We therefore intend to change the event observer resolution rules to allow the generic type of the event object to be taken into account if the runtime event object does not contain sufficient information.
Note that this may seem like a backwards incompatible change, however CDI 1.0 is essentially unimplementable today - examples in the spec do not work as described.
