Weld reference documentation can be viewed online or downloaded as a PDF.
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.
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.
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.
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 which 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>
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:
asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false
asadmin deploy --property implicitCdiEnabled=false <archive>
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>
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>