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.
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).
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,
@Decorator were added,
all stereotype annotations (annotations annotated with
@Stereotype) were added.
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
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.
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:
more details on the diff
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
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
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.
We integrated all OSGi bundle information in CDI 1.2 api jar. So now it’ll be easier to use CDI in OSGi environment. Before that you had to grab a special OSGi release of CDI 1.1 to have the good bundle info in our
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.
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