d.weld-api.6.0.CR1.source-code.weld_1_1.xsd Maven / Gradle / Ivy
Go to download
Show more of this group Show more artifacts with this name
Show all versions of weld-api Show documentation
Show all versions of weld-api Show documentation
Weld specifc extensions to the CDI API
The newest version!
Weld defines a number of extensions to beans.xml, in the namespace
http://jboss.org/schema/weld/beans
<scan> provides fine control over the classes loaded by
Weld for scanning by nesting a number of include and exclude
filters. Exclusions cause the class to not be loaded, not have
any container lifecycle events fired for them, and not be deployed
as beans.
In general, the semantics defined by Ant's pattern
sets (http://ant.apache.org/manual/dirtasks.html#patternset)
are followed. If no include filters are defined, all classes are
included. If both include filters and excludes filters are provided,
only class names which match at least one include filter and don't
match any exclude filter are scanned.
An include filter causes a class to be scanned. If no include filters
are specified, then all classes are scanned. If both include filters
and excludes filters are specified, only class names which match at
least one include filter and don't match any exclude filter are
scanned.
A filter may specify match against either the name of a class (or
package) or a regular expression to match.
A filter is active by default, or may specify activation conditions. If
activation conditions are specified, then the filter is active only if
all activation conditions are met. If all conditions are met, then
classes matching either the name or pattern will be filtered.
An exclude filter causes a class to not be scanned. If no exclude
filters are specified, then all classes are scanned. If both include
filters and excludes filters are specified, only class names which
match at least one include filter and don't match any exclude filter
are scanned.
A filter may specify match against either the name of a class (or
package) or a regular expression to match.
A filter is active by default, or may specify activation conditions. If
activation conditions are specified, then the filter is active only if
all activation conditions are met. If all conditions are met, then
classes matching either the name or pattern will be filtered.
The filter applies to classes whose fully qualified name matches this
pattern. Ant-style patterns (see
http://ant.apache.org/manual/dirtasks.html#patterns) are used, such that
'*' matches zero or more characters (in the current package) and '?'
matches one character in the current package. Additionally, '**' matches
this package, and all sub packages.
For example:
com.redhat.J???? will match any class in the com.redhat package,
whose name starts with the letter 'J' and is five characters long.
com.redhat.R* will match any class in the com.redhat package, whose name
starts with the letter 'R'.
com.redhat.* will match any class in the com.redhat package, but not
subpackages.
com.redhat.** will match any class in the com.redhat package, and all
subpackages.
If you wish to use a Java regular expression, then pattern should be used.
Only one of name or pattern should be specified
The filter applies to classes whose fully qualified name matches this
regular expression.
If you wish to use a simple, Ant-style pattern, then name should be used.
Only one of name or pattern should be specified
Activate the filter only activated if a class with the specified name
is available on the application's classpath. If the name starts with
a !, then the filter is active if the class is not available
Activate the filter only if the specified system property is set.
If no value is specified, then it will match the system property
on property name alone. If the property name starts with a !, then
the filter is active if the property is not set. If the property value
starts with a !, then the filter is active if the property values do
not match.