[cdi-dev] exclude rules questions

[Romain Manni-Bucau]

+1 we should stay as much as possible to java world and not regex one
which always makes things hard to follow...and here it would be pretty
useless
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-02-03 Mark Struberg <struberg at yahoo.de>:
> 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 at 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 at 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 at lists.jboss.org
>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>
>>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev