Contexts and Dependency Injection behavior changes between releases

The CDI 2.0 and CDI 1.2 features are built on the Weld implementation of CDI. The CDI 1.0 feature is built on Apache OpenWebBeans implementation of CDI. Thus, an application that is migrated from CDI 1.0 might behave differently or fail on the later CDI features.

You can choose between the CDI 2.0, CDI 1.2, and CDI 1.0 feature implementations for each server instance, with consideration for behavior changes. If the required behavior is contained in the CDI 2.0 feature only, then you must use the CDI 2.0 feature. If an existing CDI 1.0 application might be adversely affected by behavior changes in either the CDI 2.0 or CDI 1.2 feature, then use the CDI 1.0 feature to preserve the existing behavior for that application. It is not possible to use a combination of CDI features in the same server because the features are not compatible. If you configure more than one CDI feature, the server produces a configuration error.

Migrating from CDI 1.2 to CDI 2.0

Both CDI features are built on Weld implementations of CDI. Therefore, compatibility with an earlier version is maintained and application behavior on CDI 2.0 is consistent with that on CDI 1.2.

Migrating from CDI 1.0 to CDI 1.2 or to CDI 2.0

The behavior changes for CDI 1.0 to CDI 2.0 are the same as for CDI 1.0 to CDI 1.2.

The conversation ID CID

In the CDI 1.0 implementation, the CID is globally unique. In CDI 1.2 and CDI 2.0, 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 or CDI 2.0 implementation, the following example shows a schema that is referenced in the beans.xml file:

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 or CDI 2.0 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 or CDI 2.0 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 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 or CDI 2.0 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 enableImplicitBeanArchives 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.