Chapter 20. Configuration

20.1. Excluding classes from scanning and deployment

20.2. Concurrent deployment configuration

20.2.1. Thread pool configuration

20.1. Excluding classes from scanning and deployment

Weld allows you to exclude classes in your archive from scanning, having container lifecycle events fired, and being deployed as beans.

In this tutorial, we'll explore this feature via an example; a more formal specification can be found in the xsd, located at http://jboss.org/schema/weld/beans_1_1.xsd.

All the configuration is done in the beans.xml file. For more information see Section 15.6, “Packaging and deployment”

Example 20.1. beans.xml


<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://java.sun.com/xml/ns/javaee" 

       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

       xmlns:weld="http://jboss.org/schema/weld/beans" 

       xsi:schemaLocation="

          http://java.sun.com/xml/ns/javaee http://docs.jboss.org/cdi/beans_1_0.xsd

          http://jboss.org/schema/weld/beans http://jboss.org/schema/weld/beans_1_1.xsd">

    

    <weld:scan>

      

        <!-- Don't deploy the classes for the swing app! -->

        <weld:exclude name="com.acme.swing.**" />

      

        <!-- Don't include GWT support if GWT is not installed -->

        <weld:exclude name="com.acme.gwt.**">

            <weld:if-class-available name="!com.google.GWT"/>

        </weld:exclude>

        

        <!--

            Exclude classes which end in Blether if the system property verbosity is set to low

            i.e.

              java ... -Dverbosity=low            

        -->        

        <weld:exclude pattern="^(.*)Blether$">

            <weld:if-system-property name="verbosity" value="low"/>

        </weld:exclude>

        

       <!--

             Don't include JSF support if Wicket classes are present, and the viewlayer system

             property is not set

        -->

        <weld:exclude name="com.acme.jsf.**">

            <weld:if-class-available name="org.apahce.wicket.Wicket"/>

            <weld:if-system-property name="!viewlayer"/>

        </weld:exclude>

    </weld:scan>

    

</beans>

In this example we show the most common use cases for exercising fine control over which classes Weld scans. The first filter excludes all classes in the package com.acme.swing, and in most cases this will be sufficient for your needs.

However, sometimes it's useful to be able to activate the filter depending on the environment used. In this case, Weld allows you to activate (or deactivate) a filter based on either system properties or whether a class is available. The second filter shows the use case of disabling scanning of certain classes depending on the capabilities of the environment you deploy to - in this case we are excluding GWT support if GWT is not installed.

Note

Notice how we use a ! character on the name attribute to invert the activation condition. You can invert any activation condition in this way.

The third filter uses a regular expression to select the classes to match (normally we use simple name-based patterns, as they don't require us to escape the period which delimits the package hierarchy).

Note

If you specify just a system property name, Weld will activate the filter if that system property has been set (with any value). If you also specify the system property value, then Weld will only activate the filter if the system property's value matches exactly.

The fourth filter shows more a advanced configurations, where we use multiple activation conditions to decide whether to activate the filter.

You can combine as many activation conditions as you like (all must be true for the filter to be activated). If you want to a filter that is active if any of the activation conditions are true, then you need multiple identical filters, each with different activation conditions.

Tip

In general, the semantics defined by Ant's pattern sets (http://ant.apache.org/manual/dirtasks.html#patternset) are followed.

20.2. Concurrent deployment configuration

Weld by default supports concurrent loading and deploying of beans. However, in certain deployment scenarios the default setup may not be appropriate. Bootstrap configuration may be altered using the org.jboss.weld.bootstrap.properties file located on the classpath (e.g. WEB-INF/classes/org.jboss.weld.bootstrap.properties in a web archive).

Table 20.1. Concurrent deployment configuration options

Configuration option	Default value	Description
`concurrentDeployment`	true	If set to false, `ConcurrentDeployer` and `ConcurrentValidator` will not be used.
`preloaderThreadPoolSize`	`Math.max(1, Runtime.getRuntime().availableProcessors() - 1)`	Weld is capable of resolving observer methods for container lifecycle events in advance while bean deployer threads are blocked waiting for I/O operations (such as classloading). This process is called preloading and leads to better CPU utilization and faster application startup time. This configuration option specifies the number of threads used for preloading. If set to 0, preloading is disabled.

20.2.1. Thread pool configuration

For certain types of tasks Weld uses its own thread pool. The thread pool is represented by the ExecutorServices service. It is possible to alter the thread pool configuration in the WEB-INF/classes/org.jboss.weld.executor.properties file.

Table 20.2. Executor configuration options

Configuration option	Default value	Description
`debug`	false	If set to true, debug timing information is printed to the standard output.
`threadPoolSize`	`Runtime.getRuntime().availableProcessors()`	The number of threads to be used for bean loading and deployment.
`threadPoolType`	`FIXED`	The type of the thread pool. Possible values are: `FIXED`, `FIXED_TIMEOUT`, `NONE`, `SINGLE_THREAD`