Veto and Requires

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Veto and Requires

Rick Hightower

"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.


--
Rick Hightower
(415) 968-9037
Profile 


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: Veto and Requires

Pete Muir
Administrator

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: Veto and Requires

Mark Struberg
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 <[hidden email]>
> To: Rick Hightower <[hidden email]>
> Cc: cdi-dev <[hidden email]>
> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: Veto and Requires

Pete Muir
Administrator
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 <[hidden email]>
>> To: Rick Hightower <[hidden email]>
>> Cc: cdi-dev <[hidden email]>
>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: Veto and Requires

Mark Struberg
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 <[hidden email]>
> To: Mark Struberg <[hidden email]>
> Cc: Rick Hightower <[hidden email]>; cdi-dev <[hidden email]>
> 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 <[hidden email]>
>>>  To: Rick Hightower <[hidden email]>
>>>  Cc: cdi-dev <[hidden email]>
>>>  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
>>>  [hidden email]
>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: Veto and Requires

Pete Muir
Administrator
Do we need to explicitly call out this scenario in the spec as something an impl must not do (crash with an NCDFE)?

On 18 Oct 2011, at 15:49, Mark Struberg wrote:

> 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 <[hidden email]>
>> To: Mark Struberg <[hidden email]>
>> Cc: Rick Hightower <[hidden email]>; cdi-dev <[hidden email]>
>> 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 <[hidden email]>
>>>> To: Rick Hightower <[hidden email]>
>>>> Cc: cdi-dev <[hidden email]>
>>>> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev