This is a new feature introduced in Weld 2.1.0.Beta2 (see also WELD-1480 and WELD-1501). It's not portable (i.e. will not work with other CDI implementations) but might be useful.

According to the CDI specification some built-in contexts (request, session and conversation) must be always active during the service() method of any servlet in the web application. This means context activation and deactivation per every HTTP request and also handling conversation stuff (e.g. associating long running conversation with the request) in the case of conversation context. For some scenarios this represents unnecessary overhead. The first scenario example that comes to my mind is serving resources (CSS, JavaScript, images, audio, etc.). But it may also apply to legacy components which do not make use of CDI services.

Weld allows to define a special activation filter component - HttpContextActivationFilter - so that only matching HTTP requests result in context activation/deactivation. Basically there are two ways to enable/configure this component. First the integrator (e.g. WildFly application server) is allowed to provide an implementation and utilize its own configuration mechanism. Secondly - if the integrator doesn't support this option - a special initialization parameter may be associated with a web application to activate a built-in regular expression-based activation filter.

E.g. to match paths with suffix ".html" and ".xhtml" place the following init param in your web.xml:

    <context-param>
        <param-name>org.jboss.weld.context.mapping</param-name>
        <param-value>(.*\.html|.*\.xhtml)</param-value>
    </context-param>

Param value is a regular expression and is matched againts the request URI without the context path, i.e. /foo for http://localhost:8080/myapp/foo?action=test (try Visual Regex Tester from ocpsoft.org to test your mappings if not sure :-). Note that Weld only supports one activation filter at a time and integrator has always precedence. You should see a warning log if your web.xml mapping definition is ignored.

My quick and dirty tests showed up that using built-in regular expression-based activation filter can save several milliseconds* for each request which does not require CDI services. It's not that much but it counts!

* Resource consumption was not monitored.