Skip to end of metadata
Go to start of metadata

WildFly 8 uses Weld, the CDI reference implementation as its CDI provider. To activate CDI for a deployment simply add a beans.xml file in any archive in the deployment.

This document is not intended to be a CDI tutorial, it only covers CDI usage that is specific to WildFly. For some general information on CDI see the below links:

CDI Specification
Weld Reference Guide
The AS7 Quickstarts

Using CDI Beans from outside the deployment

For WildFly 8 onwards, it is now possible have classes outside the deployment be picked up as CDI beans. In order for this to work you must add a dependency on the external deployment that your beans are coming from, and make sure the META-INF directory of this deployment is imported, so that your deployment has visibility to the beans.xml file (To import beans from outside the deployment they must be in an archive with a beans.xml file).

There are two ways to do this, either using the MANIFEST.MF or using jboss-deployment-structure.xml.

Using MANIFEST.MF you need to add a Dependencies entry, with meta-inf specified after the entry, e.g.

Using jboss-deployment-structure.xml you need to add a dependency entry with meta-inf="import", e.g.

Note that this can be used to create beans from both modules in the modules directory, and from other deployments.

For more information on class loading and adding dependencies to your deployment please see the Class Loading Guide

Suppressing implicit bean archives

CDI  1.1 brings new options to packaging of CDI-enabled applications. In addition to well-known explicit bean archives (basically any archive containing the beans.xml file) the specification introduces implicit bean archives.

An implicit bean archive is any archive that contains one or more classes annotated with a bean defining annotation (scope annotation) or one or more session beans. As a result, the beans.xml file is no longer required for CDI to work in your application.

In an implicit bean archive only those classes that are either annotated with bean defining annotations or are session beans are recognized by CDI as beans (other classes cannot be injected).

This has a side-effect, though. Libraries exist that make use of scope annotation (bean defining annotations) for their own convenience but are not designed to run with CDI support. Guava would be an example of such library. If your application bundles such library it will be recognized as a CDI archive and may fail the deployment.

Fortunately, WildFly makes it possible to suppress implicit bean archives and only enable CDI in archives that bundle the beans.xml file. There are two ways to achieve this:

Per-deployment configuration

You can either set this up for your deployment only by adding the following content to the META-INF/jboss-all.xml file of your application:

Global configuration

Alternatively, you may configure this for all deployments in your WildFly instance by executing the following command:

Non-portable mode

CDI 1.1 clarifies some aspects of how CDI portable extensions work. As a result, some extensions that do not use the API properly (but were tolerated in CDI 1.0 environment) may stop working with CDI 1.1.If this is the case of your application you will see an exception like this:

org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization

Fortunatelly, there is a non-portable mode available in WildFly which skips some of the API usage checks and therefore allows the legacy extensions to work as before.

Again, there are two ways to enable the non-portable mode:

Per-deployment configuration

You can either set this up for your deployment only by adding the following content to the META-INF/jboss-all.xml file of your application:

Global configuration

Alternatively, you may configure this for all deployments in your WildFly instance by executing the following command:

Note that new portable extensions should always use the BeanManager API properly and thus never required the non-portable mode. The non-portable mode only exists to preserve compatibility with legacy extensions!

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.