CDI tagcloud

Documentation

Weld reference documentation can be viewed online or downloaded as a PDF.

FAQ


If I create a thread in my CDI bean, how will Weld react?

Weld assumes requests are single threaded, and uses thread locals to isolate requests. This means that if user created threads are used then built in implementation of the session scope, the request scope and the conversation scope, will become dissociated, and you will find they are no longer active in the new thread, nor able to access their contextual data. The Weld reference guide contains information on how to associate a request to a context and activate it. Doing this in your new thread will cause the contexts to be active, and contain the same contextual data.

The dependent context and the application context will work as usual in any user created thread.

Why does Weld leave some proxy class definitions lying around when I undeploy my application? How can I prevent this?

When a Weld-enabled application is deployed on an application server or a web server, proxy classes for beans implementing interfaces or extending classes contained in common libraries are loaded in the class loader (CL) for that library, not the thread context class loader (TCCL). This means that these proxy classes will not be removed from the server when the application is undeployed.

The reason for this approach is to support the use of package scoped classes and members of classes which need to be proxied as beans. Thus the TCCL is not used for the proxy classes generated by Weld.

One way to prevent this problem is to simply deploy those libraries with your application. In this scenario, those classes are loaded in a CL associated with the application and will thus be removed when the application is undeployed.

Some of my beans aren’t deployed and I can’t see why?

Weld will not create beans if it can’t load the class, or some class dependency. If that happens, you’ll see a note in the server log.

WELD-000119: Not generating any bean definitions from org.jboss.weld.tests.beanDeployment.noclassdeffound.Bar because of underlying class loading error

You can view more details by increasing the log level of the application server to DEBUG.

Why does Weld set character encoding of an HTTP request/response body to ISO-8859-1?

An application may set character encoding of a request by calling the ServletRequest.setCharacterEncoding() method. This method has a limitation: it has to be called before the request parameters or request body are read, otherwise the method call has no effect.

In order to properly activate the conversation context, Weld reads the cid request parameter in the beginning of request processing (see the CDI spec for details). As a side-effect, this makes it impossible to change the character encoding later in the request processing (since request parameters have been read already). As a result, an application servlet or filter that tries to set character encoding will not work since it does that too late.

A workaround is to have the application encoding-setting filter to be called before Weld tries to read the "cid" parameter in the ConversationFilter. This can be done by mapping the custom filter before Weld’s ConversationFilter in web.xml

<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
    <filter>
        <filter-name>SetCharacterEncoding</filter-name>
        <filter-class>org.apache.catalina.filters.SetCharacterEncodingFilter</filter-class>
        <init-param>
            <param-name>encoding</param-name>
            <param-value>UTF-8</param-value>
        </init-param>
        <init-param>
            <param-name>ignore</param-name>
            <param-value>false</param-value>
        </init-param>
    </filter>
    <filter-mapping>
        <filter-name>SetCharacterEncoding</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
    <filter-mapping>
        <filter-name>CDI Conversation Filter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
</web-app>

My application bundles a third-party library which uses javax.inject annotations. This library was not intended to be a CDI library but on CDI 1.1 this library is being picked up as an implicit bean archive and breaks the deployment of my application. Why is this happening?

Firstly, this issue only affects CDI 1.1. If possible, go and upgrade to CDI 1.2 (Weld 2.2 or later) where this issue does not occur.

If you cannot do that, read further: This is a known issue in the CDI 1.1 specification and occurs with third-party libraries such as Guava.

A workaround is to configure the application server to require the beans.xml file in bean archives (suppress implicit bean archives). The way to configure this varies across application servers:

GlassFish 4

global configuration:

asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false

per-deployment configuration:

asadmin deploy --property implicitCdiEnabled=false <archive>

WildFly 8

global configuration:

/subsystem=weld:write-attribute(name=require-bean-descriptor,value=true)

per-deployment configuration - add the following content to META-INF/jboss-all.xml of the application

<jboss xmlns="urn:jboss:1.0">
    <weld xmlns="urn:jboss:weld:1.0" require-bean-descriptor="true"/>
</jboss>

How can I bundle my entire SE application with Weld into a single jar?

Weld internal classes are not intended to be used in a CDI deployment. As a result, you may encounter validation errors when packaging your application together with Weld in a single fat jar file.

A workaround is to exclude Weld classes from bean scanning:

<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"
       version="1.1" bean-discovery-mode="all">
    <scan>
        <exclude name="org.jboss.weld.**" />
    </scan>
</beans>

I use the Instance API to obtain bean instances. Why does it seem to cause a memory leak?

The Instance API is often used in loops to obtain multiple instances of a certain bean. Here is an example:

    @Inject
    private Instance<A> instance;

    public void foo() {
        // obtain multiple instances of A
        for (;;) {
            instance.get();
    }

By default, each object obtained using Instance remains managed (is not released) until the Instance object is destroyed. This can easily create a memory leak. Therefore, the application should explicitly destroy obtained instances when it no longer needs by calling the Instance.destroy() method.