Java 자바 EE 7 CDI 1.2 is released

Java 자바 EE 7 CDI 1.2 is 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.

CDI API now officially supporting OSGi

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 META-INF/MANIFEST.MF.

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.