From a user view I'd say it makes no sense to also exclude ejbrother.

On Monday, 3 February 2014, 10:49, Martin Kouba <mkouba(a)redhat.com&gt; 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 &gt;  cdi-dev(a)lists.jboss.org >  https://lists.jboss.org/mailman/listinfo/cdi-dev >

On Monday, 3 February 2014, 11:45, Martin Kouba <mkouba(a)redhat.com&gt; 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&gt; 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 >>> >>

+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(a)yahoo.de&gt;: > 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&gt; 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&gt; 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 >>>>> >>>> >> > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev