ad 1.)
Well, I do not entirely agree with the foobar also being excluded. The spec says:
"<exclude name="com.acme.ejb.**">"
"The fourth exclude filter will exclude all classes in the com.acme.ejb package, and
any subpackages if the system property exclude-ejbs is set (with any value)."
Clearly com.acme.ejbrother is neither com.acme.ejb nor a sub-package.
From a user view I'd say it makes no sense to also exclude
ejbrother.
ad 2.)
We must clarify whether multiple conditions in a <scan> element are OR or AND.
LieGrue,
strub
On Monday, 3 February 2014, 10:49, Martin Kouba
<mkouba(a)redhat.com> wrote:
> Hi Mark,
Dne 31.1.2014 21:07, Mark Struberg napsal(a):
>
>
> Hi!
>
> A few questions regarding exclude rules
>
> 1.) does .* mean only the package, but no sub-packages. Whereas .** also
includes sub-packages?
> Marek brought up another interesting note: com.foo.** would according to
the wording also exclude com.foobar... Is that intended?
>
Yes, types from "com.foobar" would be excluded as well. I'm not
sure it
was intended but we should not change the behaviour due to backwards
compatibility...
>
> 2.) Are multiple children allowed in an exclude rule in beans.xml?
Yep, check also the schema file (beans_1_1.xsd).
> There is a funny example in the spec:
>
> <exclude name="com.acme.ejb.**">
>
> <if-class-available
name="javax.enterprise.inject.Model"/>
>
> <if-system-property name="exclude-ejbs"/>
> </exclude>
>
>
> But I could not find the explanation what should happen. The
if-class-available is nowhere stated. Or did I overlook it?
>
"if-class-available" is described above the example and in xsd. The
filter is active only if the classloader for the bean archive CAN
load a class for that name. So the filter will not be active if the
"Model" class can't be loaded or if the system property
"exclude-ejbs"
is not set.
In any case the description of the example is not complete and we should
add a TCK test for this as well (AFAIK
org.jboss.cdi.tck.tests.deployment.exclude.ExcludeFiltersTest is not
testing multiple child elements).
> txs and LieGrue,
> strub
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>