"Any class or package may be prevented from providing bean definitions based on the availability of other classes by adding the @Requires annotation on the class or package." @Requires({Customer.class, Supplier.class}) public class Order { ... } Spring has something similar called @Required with some different behavior. But now that I think on it... it is different enough.... I'd prefer explicit names for these annotations. @ExcludeFromCDI and @ ExcludeFromCDIIfMissing. I know those are horrible names too. Not a big fan of @Veto and @Requires.

How about @ExcludeAsSource, and it has an optional attribute called requires that takes an array of class types?

I really really hate @Veto and @Requires. I guess I should search the mail list and see if I missed this conversation.

Hi! Nope, CODI has none of those methods, because @Veto can already be done via @Typed(), even in CDI-1.0. The mechanics of ProcessAnnotatedType#veto() and @Typed() are a bit different, but they lead to the same result. Rick, you need @Veto or @Typed() if you e.g. have a producer method for a class in a BDA. Otherwise you will get an AmbiguousResolutionException (because both the class and the producer methods are Bean<YourClass>). @Requires is really needed in the CDI-1.1 spec. Because the Seam3 @Optional Extension is not really portable as it assumes that NoClassDefFoundErrors and ClassNotFoundExceptions will get swallowed while the BeanManager performs the Classpath scanning. This has to be specified in CDI-1.1 LieGrue, strub ----- Original Message ----- > From: Pete Muir <pmuir(a)redhat.com&gt; > To: Rick Hightower <richardhightower(a)gmail.com&gt; > Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; > Sent: Tuesday, October 18, 2011 3:25 PM > Subject: Re: [cdi-dev] Veto and Requires > > > On 18 Oct 2011, at 06:59, Rick Hightower wrote: > >> "Any class or package may be prevented from providing bean definitions > based on the availability of other classes by adding the @Requires annotation on > the class or package." >> >> >> @Requires({Customer.class, Supplier.class}) public class Order { ... >> >> } >> >> >> >> >> Spring has something similar called @Required with some different behavior. > But now that I think on it... it is different enough.... >> >> I'd prefer explicit names for these annotations. @ExcludeFromCDI and @ > ExcludeFromCDIIfMissing. >> >> I know those are horrible names too. Not a big fan of @Veto and > @Requires. > > Hmm. Those names are not particularly consistent with the language style or > meaning used in CDI (for example, we never talk about CDI that way in the spec). > > @Veto is consistent with the .veto() method in the SPI, which is why it was > chosen. > > @Requires we agonised over for a long time, but couldn't come up with > anything better. If anyone has a better idea, please speak :-) > >> How about @ExcludeAsSource, and it has an optional attribute called > requires that takes an array of class types? > > I'm not sure this makes any sense, you aren't "excluded it as > source" (the class definition is still available), but vetoing the use of > the class as a bean. @Excludes could work (and is consistent with the CDI > style), possibly with an attribute called unlessAvailable (or something like > that). > >> >> I really really hate @Veto and @Requires. I guess I should search the mail > list and see if I missed this conversation. > > This was originally discussed on the seam or weld mailing lists, we had a long > discussion there. > > I think CODI has something similar, but can't find the naming right now. > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev >

I'm fine with both @Veto and @Requires. I'm more interested in the exact wording of @Requires, because this could _heavily_ influence how classes must be parsed. Take as example the following class: @Requires("javax.persistence.EntityManager") @Dependent public class EmProducer { private @PersistenceContext EntityManager entityManager; ... } If a CDI container uses just plain Class.getAnnotations() for the classpath scanning, then it would not even be able to check the @Requires annotation, because it will just crash with a NoClassDefFoundError upfront ;) Otoh if you get the annotation via manual byte code parsing of the jar, then it would probably work. But this is highly restricting the impls, and we really need to be careful that all containers actually can implement it... LieGrue, strub ----- Original Message ----- > From: Pete Muir <pmuir(a)redhat.com&gt; > To: Mark Struberg <struberg(a)yahoo.de&gt; > Cc: Rick Hightower <richardhightower(a)gmail.com>; cdi-dev <cdi-dev(a)lists.jboss.org&gt; > Sent: Tuesday, October 18, 2011 4:41 PM > Subject: Re: [cdi-dev] Veto and Requires > > Yeah, @Veto makes this use of @Typed "first class". > > Any thoughts on the naming Mark? > > On 18 Oct 2011, at 15:37, Mark Struberg wrote: > >> Hi! >> >> Nope, CODI has none of those methods, because >> >> @Veto can already be done via @Typed(), even in CDI-1.0. The mechanics of > ProcessAnnotatedType#veto() and @Typed() are a bit different, but they lead to > the same result. >> Rick, you need @Veto or @Typed() if you e.g. have a producer method for a > class in a BDA. Otherwise you will get an AmbiguousResolutionException (because > both the class and the producer methods are Bean<YourClass>). >> >> >> @Requires is really needed in the CDI-1.1 spec. Because the Seam3 @Optional > Extension is not really portable as it assumes that NoClassDefFoundErrors and > ClassNotFoundExceptions will get swallowed while the BeanManager performs the > Classpath scanning. This has to be specified in CDI-1.1 >> >> >> LieGrue, >> strub >> >> >> >> >> ----- Original Message ----- >>> From: Pete Muir <pmuir(a)redhat.com&gt; >>> To: Rick Hightower <richardhightower(a)gmail.com&gt; >>> Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; >>> Sent: Tuesday, October 18, 2011 3:25 PM >>> Subject: Re: [cdi-dev] Veto and Requires >>> >>> >>> On 18 Oct 2011, at 06:59, Rick Hightower wrote: >>> >>>> "Any class or package may be prevented from providing bean > definitions >>> based on the availability of other classes by adding the @Requires > annotation on >>> the class or package." >>>> >>>> >>>> @Requires({Customer.class, Supplier.class}) public class Order { > ... >>>> >>>> } >>>> >>>> >>>> >>>> >>>> Spring has something similar called @Required with some different > behavior. >>> But now that I think on it... it is different enough.... >>>> >>>> I'd prefer explicit names for these annotations. > @ExcludeFromCDI and @ >>> ExcludeFromCDIIfMissing. >>>> >>>> I know those are horrible names too. Not a big fan of @Veto and >>> @Requires. >>> >>> Hmm. Those names are not particularly consistent with the language > style or >>> meaning used in CDI (for example, we never talk about CDI that way in > the spec). >>> >>> @Veto is consistent with the .veto() method in the SPI, which is why it > was >>> chosen. >>> >>> @Requires we agonised over for a long time, but couldn't come up > with >>> anything better. If anyone has a better idea, please speak :-) >>> >>>> How about @ExcludeAsSource, and it has an optional attribute called > >>> requires that takes an array of class types? >>> >>> I'm not sure this makes any sense, you aren't "excluded it > as >>> source" (the class definition is still available), but vetoing the > use of >>> the class as a bean. @Excludes could work (and is consistent with the > CDI >>> style), possibly with an attribute called unlessAvailable (or something > like >>> that). >>> >>>> >>>> I really really hate @Veto and @Requires. I guess I should search > the mail >>> list and see if I missed this conversation. >>> >>> This was originally discussed on the seam or weld mailing lists, we had > a long >>> discussion there. >>> >>> I think CODI has something similar, but can't find the naming right > now. >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >