If you do a word-by-word interpretation of the spec, then even the .* paragraph would
include sub-packages. But that does not make sense from a user perspective!
The spec contradicts itself in this regard. And in this case we should pick the option
which is most likely the one the user wants. This case will really rarely be hit in the
wild though.
Let's look what other established Java mechanism do in this area:
* OSGi: it only knows .* (no .** over there afaik) but while this also covers
sub-packages ,foo.* does _not_ cover foobar.
* Maven: knows .* and .**. foo.* does _not_ cover foobar neither
Feel free to point me to _important_ Java projects where foobar gets covered by foo.**
LieGrue,
strub
On Monday, 3 February 2014, 11:45, Martin Kouba
<mkouba(a)redhat.com> wrote:
> Dne 3.2.2014 11:11, Mark Struberg napsal(a):
>
>
>
> 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.
>
Yes. But it's only an example description which indicates it was not
intended.
IMO the authoritative statement is:
"the package name of the type being discovered starts with the value of
the name attribute with a suffix ".**" of the exclude filter"
>
> ad 2.)
>
> We must clarify whether multiple conditions in a <scan> element are
OR or AND.
I think it's OR because the spec states:
"If the exclude filter definition contains:
* ...condition, OR
then the filter is inactive."
>
> 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
>>>
>>