Contexts and Dependency Injection 1.2 behavior changes

The Contexts and Dependency Injection (CDI) 1.2 implementation contains some behavior changes that might cause an application that was migrated from CDI 1.0 to behave differently or fail on CDI 1.2.

You can choose between the CDI 1.0 and CDI 1.2 feature implementations for each server instance, with consideration for behavior changes. If the required behavior is contained in the CDI 1.2 feature only, then you must use the CDI 1.2 feature. If an existing application might be adversely affected by behavior changes in the CDI 1.2 feature, then by using the CDI 1.0 feature the existing behavior is preserved for that application. It is not possible to use both the CDI 1.0 and CDI 1.2 features in the same server as the features are not compatible. If you configure both features, the server produces a configuration error.

The CDI 1.0 feature is built on Apache OpenWebBeans implementation of CDI. The CDI 1.2 feature is built on the Weld implementation of CDI. The behavior changes introduced are due to the differences in the two implementations.

The conversation ID CID

In the CDI 1.0 implementation, the CID is globally unique. In CDI 1.2, it is unique per HTTP session. This behavior is in line with the CDI specification and is a convention that is chosen by the Weld. To get a globally unique CID, the CID must be specified at conversation start by calling Conversation.begin.

Referencing schemas in the beans.xml file

In a CDI 1.2 implementation, here is an example of a schema that is referenced in the beans.xmlfile:
xmlns="http://xmlns.jcp.org/xml/ns/javaee" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
If you use an invalid schema, the server gives an exception error. You can turn off the validation of the beans.xml file by setting the org.jboss.weld.xml.disableValidating=true JVM property, which also prevents the error from being produced. If the beans.xml file specifies decorators or interceptors, a valid schema must be used, otherwise the decorators and interceptors are not correctly instantiated.

Implicit bean archives

The CDI 1.2 implementation defines two different types of bean archives: explicit and implicit.

An explicit bean archive is an archive that contains a beans.xml file:
  • with a version number of 1.1 (or later), and with the bean-discovery-mode of all
  • with no version number
  • that is an empty file

An implicit bean archive is any other archive, which contains one or more bean classes with a bean defining annotation as defined in the specification in Section 2.5.1, "Bean defining annotations", or one or more session beans. See the specification, Contexts and Dependency Injection for the Java™ EE platform.

When you update the schema to a CDI 1.2 implementation, to keep the bean archive as explicit the bean discovery mode must be set to all:
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
bean-discovery-mode="all"
		version="1.1">
Note: An implicit bean archive discovers only beans that have a bean defining annotation.
This new type of bean archive can result in an archive that is not intended to be a CDI bean archive but it becomes an implicit bean archive in the CDI 1.2 implementation. To stop this behavior, you can add a beans.xml file with the bean discovery mode set to none, preventing the archive from being a bean archive. An alternative solution is to add the following property to the server.xml file for your Liberty server:
<cdi12 enableImplicitBeanArchives="false"/>
Setting this property to false prevents the archives without beans.xml files from becoming implicit bean archives.

Setting this property to false gives an improved performance at startup time.


Icon that indicates the type of topic Concept topic

File name: cwlp_cdi_behavior.html