SeamFramework.orgCommunity Documentation

Chapter 20. 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

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

        <!-- 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="!"/>
            Exclude classes which end in Blether if the system property verbosity is set to low
              java ... -Dverbosity=low            
        <weld:exclude pattern="^(.*)Blether$">
            <weld:if-system-property name="verbosity" value="low"/>
             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"/>

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.


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


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.


In general, the semantics defined by Ant's pattern sets ( are followed.