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.

<?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.

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).

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.