CDI 1.2 released
After one year of existence, the CDI 1.1 specification is updated by a maintenance release. This maintenance review known as CDI 1.2 was adopted by the JCP with 24 yes and one Expert Member forgetting to vote. The minor increment (from 1.1 to 1.2) instead of a 1.1-SP1 is due to the the fact that we changed the javadoc and the TCK but beyond that there are far less changes from 1.1 to 1.2 than from 1.0 to 1.1. That’s being said, CDI 1.2 brings a lot of clarifications and small behavior changes. Let’s check what’s on the menu.
Major changes
Some of these changes are only big clarifications but some other have an impact on the implementations (these last ones have an asterisk in their title below). In order to use them you’ll have to grab a CDI 1.2 implementation (more info at the end of this post).
Rethinking the default bean discovery mode *
The default bean discovery mode (annotated
) that allows CDI to be activated by default in Java EE 7 without beans.xml
, file was the root of a lot of issues with other frameworks implementing the AtInject specification (JSR-330) or with libraries thought to be used with such frameworks.
To solve these issues we changed the set of Bean defining annotations (class annotations that make a class an implicit bean candidate) :
-
all pseudo scopes annotations except
@Dependent
were removed, -
@Interceptor
and@Decorator
were added, -
all stereotype annotations (annotations annotated with
@Stereotype
) were added.
Clarification of conversation resolution
Conversation resolution mechanism could bring conflicts with servlet spec as stated in CDI-411.
We clarified the fact that implementation should prevent these conflict during conversation resolution in conversation context lifecycle
Rework on event chapter
You think you know how event resolution works in CDI? If you gained this knowledge by a careful reading of chapter 10 of the specification, think again. This chapter had a lot of approximations and confusing mentions. It was reviewed and partly rewritten (and yes, @Any
is totally useless for Event<>
injection, event firing and observers resolution).
This chapter is worth the re-reading.
You can also check the diff, if you prefer.
BeanManager more permissive during initialization *
In CDI 1.1, some BeanManager methods couldn’t be called before the AfterDeploymentValidation
was fired. A non portable behavior was tolerated to allow use of these in AfterBeanDiscovery
observers. These brought confusing mention in specification and javadoc. We decided to standardized the non portable behavior (not a big deal since all implementations adopted it). So in CDI 1.2 the following BeanManager
method can be called (with restrictions) in an AfterBeanDiscovery
observer method:
-
getBeans(String)
, -
getBeans(Type, Annotation…)
, -
getPassivationCapableBean(String)
-
resolve(Set)
, -
resolveDecorators(Set, Annotation…)
, -
resolveInterceptors(InterceptionType, Annotation…)
, -
resolveObserverMethods(Object, Annotation…)
, -
validate(InjectionPoint)
.
more details on the diff
Clarification on container lifecycle event use
We clarified the fact these event should only be used during invocation of their observer methods. Check the diff of the whole 11.5 paragraph
Rework on the initialization phase parts
Description of initialization phase in chapter 11 & 12 was very messing. No chronological ordering of event fired by the container, missing events. For instance we forgot to speak with ProcessInjectionPoint
and ProcessBeanAttributes
and ProcessProducer
was wrongly placed before ProcessBean
in chapter 12.
So if you’re planning to write portable extensions you should perhaps re-read chapter 12. Not yet a page turner but far more accurate than it use to be.
More minor changes
You can check the change section of the spec to check the more minor changes we introduces in the spec. We also work on Javadoc to synchronize it with the specification by updating it or correcting the spec when api description were wrong.
Concrete stuff
You’ll find concrete raw and final data in the links below.
-
You’re interested by the release notes? it’s here.
-
You want to check the diff between CDI 1.1 spec and CDI 1.2 spec? You’ll find it there
-
You can’t wait to read this new spec, the Javadoc or use with the API or TCK? Go to our download page
-
You want to start coding in CDI 1.2? Good news reference implementation (Weld 2.2.0) is available and provide all that’s needed to be integrated to a Java EE 7 server. More information on Weld 2.2.0 announcement