Actually this is the most common case _why_ one likes to veto a bean. Because if you create a producer method for a MyBean, then you'll get an AmbiguousResolutionException otherwise.
The spec conform easy way would be to simply use @Typed() public class MyBean {} to disable the bean. Imo we should just spread the word about @Typed() instead of introducing a new annotation. I did just like @Veto for making it easier for Seam3 users to move over to DeltaSpike. If we change the name, then I see no reason to implement such a thing ourself at all! LieGrue, strub ----- Original Message ----- > From: Marius Bogoevici <marius.bogoev...@gmail.com> > To: deltaspike-dev@incubator.apache.org > Cc: > Sent: Wednesday, December 28, 2011 3:56 PM > Subject: Re: [DISCUSS] [DELTASPIKE-8] @Veto > > John, > > The specification has the notion of a class being a managed bean, as laid out > in > chapter 3 of the spec. > > Using @Unmanaged would complement the content of section 3.1.1: "Which Java > classes are managed beans?", by adding another case when a class is not a > managed bean. Sure, producers can be used for creating beans of this type, > but > that is a different mechanism altogether. > > > > On 2011-12-27, at 7:34 PM, John D. Ament wrote: > >> Unmanaged sounds a little confusing. this simply represents the default >> implementation of the bean, correct? so an app developer can create a >> manual producer... right? >> >> On Tue, Dec 27, 2011 at 7:24 PM, Gerhard Petracek < >> gerhard.petra...@gmail.com> wrote: >> >>> +1 for @Unmanaged >>> (+1 for @Exclude if it's the only alternative we can agree on) >>> >>> regards, >>> gerhard >>> >>> >>> >>> 2011/12/28 Marius Bogoevici <marius.bogoev...@gmail.com> >>> >>>> As if we didn't have enough alternatives, here's another > one that popped >>>> up while discussing with Gerhard the relative merits of @Veto and >>> @Exclude: >>>> >>>> @Unmanaged >>>> >>>> I think that this solves a few problems that we currently have: >>>> >>>> a) @Veto is technically accurate, but not intuitive (and requires > an >>>> understanding of class processing, which is not a user concern) >>>> b) @Exclude is intuitive when considered in the context of scanning > but >>>> it's a bit unclear on a larger scale - 'what exactly is > this class >>> excluded >>>> from?' - the >>>> c) the annotation must be applicable to packages >>>> >>>> IMO, @Unmanaged describes best what happens to the class: it will > *not* >>>> generate a managed bean automatically. It is very similar to > @NoBean >>> early >>>> suggested by Gerhard, but works on packages too, and it describes a >>> quality >>>> of the annotated item, in the same way as @Transient stands for > "not >>>> serialized". >>>> >>>> On 2011-12-27, at 5:43 PM, Marius Bogoevici wrote: >>>> >>>>> +1 @Veto >>>>> >>>>> -1 @Exclude >>>>> >>>>> @Veto has a very narrow meaning, and hints to >>>> ProcessAnnotatedType.veto(), which is precisely what happens to > such >>>> annotated types. I have mixed feelings about @Exclude - I'd > rather not >>>> introduce a new term, especially one that does not immediately make > you >>>> think of CDI processing. >>>>> >>>>> >>>>> On 2011-12-26, at 6:41 PM, Gerhard Petracek wrote: >>>>> >>>>>> it looks like @Exclude is the alternative which would work > for several >>>> of >>>>>> us. >>>>>> -> we have to choose between @Exclude and @Vote >>>>>> >>>>>> +1 for @Exclude >>>>>> >>>>>> regards, >>>>>> gerhard >>>>>> >>>>>> >>>>>> >>>>>> 2011/12/26 Jakob Korherr <jakob.korh...@gmail.com> >>>>>> >>>>>>> +1 to @Veto and @Exclude >>>>>>> >>>>>>> Also I agree with Pete's comments about the other > suggestions. >>>>>>> >>>>>>> Regards, >>>>>>> Jakob >>>>>>> >>>>>>> 2011/12/24 Pete Muir <pm...@redhat.com>: >>>>>>>> We chose @Veto originally, as it didn't deviate > from the spec's >>> veto() >>>>>>> method, so should be less of a learning curve. I > don't like >>>> @Deactivate as >>>>>>> it makes it sound like you have to activate other > beans. @Ignore is >>> too >>>>>>> overloaded a term for me to be comfortable with it >>> (@IgnoreWarnings). I >>>>>>> like @Exclude as it's closest to what makes most > intuitive sense. >>>>>>>> >>>>>>>> On 24 Dec 2011, at 09:33, Christian Kaltepoth > wrote: >>>>>>>> >>>>>>>>> Perhaps we should build a list of all > suggestions and then start a >>>>>>>>> vote which one to use. >>>>>>>>> >>>>>>>>> I think these are the names that were > suggested: >>>>>>>>> >>>>>>>>> @Veto >>>>>>>>> @Skip >>>>>>>>> @Exclude >>>>>>>>> @Deactivate >>>>>>>>> @Ignore >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2011/12/23 Gerhard Petracek > <gerhard.petra...@gmail.com>: >>>>>>>>>> hi arne, >>>>>>>>>> >>>>>>>>>> would be also ok for me -> +1 >>>>>>>>>> >>>>>>>>>> regards, >>>>>>>>>> gerhard >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2011/12/23 Arne Limburg > <arne.limb...@openknowledge.de> >>>>>>>>>> >>>>>>>>>>> What about @Exclude? >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Arne >>>>>>>>>>> >>>>>>>>>>> -----Ursprüngliche Nachricht----- >>>>>>>>>>> Von: Gerhard Petracek > [mailto:gerhard.petra...@gmail.com] >>>>>>>>>>> Gesendet: Freitag, 23. Dezember 2011 > 21:28 >>>>>>>>>>> An: deltaspike-dev@incubator.apache.org >>>>>>>>>>> Betreff: Re: [DISCUSS] [DELTASPIKE-8] > @Veto >>>>>>>>>>> >>>>>>>>>>> +0.5 for @Skip >>>>>>>>>>> as mentioned in the original thread > @Veto is accurate from a >>>> technical >>>>>>>>>>> perspective, but it sounds strange for > users who aren't aware of >>>> the >>>>>>>>>>> mechanism behind. >>>>>>>>>>> >>>>>>>>>>> if we are talking only about @Veto vs > @Skip and not about the >>> other >>>>>>>>>>> alternatives: +1 for @Skip >>>>>>>>>>> >>>>>>>>>>> regards, >>>>>>>>>>> gerhard >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2011/12/23 Dan Allen > <dan.j.al...@gmail.com> >>>>>>>>>>> >>>>>>>>>>>> Veto is rationally the most > appropriate since it directly >>>> translates >>>>>>>>>>>> to calling > ProcessAnnotatedType#veto() >>>>>>>>>>>> >>>>>>>>>>>> However, I'd like to offer one > other alternative: >>>>>>>>>>>> >>>>>>>>>>>> @Skip >>>>>>>>>>>> >>>>>>>>>>>> While veto describes what the > extension is doing internally, >>> skip >>>> is >>>>>>>>>>>> how the developer perceives the > result of the action. The class >>> is >>>>>>>>>>>> "skipped over" during the > scanning process. This is similar to >>> the >>>>>>>>>>>> suggestion @Ignore, and I think > both would get the point across >>>>>>> equally >>>>>>>>>>> well. >>>>>>>>>>>> >>>>>>>>>>>> -Dan >>>>>>>>>>>> >>>>>>>>>>>> p.s. Apologizes for dropping the > rest of the thread. I wasn't >>>>>>>>>>>> receiving messages when this thread > started. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Dan Allen >>>>>>>>>>>> Principal Software Engineer, Red > Hat | Author of Seam in Action >>>>>>>>>>>> Registered Linux User #231597 >>>>>>>>>>>> >>>>>>>>>>>> > http://www.google.com/profiles/dan.j.allen#about >>>>>>>>>>>> http://mojavelinux.com >>>>>>>>>>>> http://mojavelinux.com/seaminaction >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Christian Kaltepoth >>>>>>>>> Blog: http://chkal.blogspot.com/ >>>>>>>>> Twitter: http://twitter.com/chkal >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Jakob Korherr >>>>>>> >>>>>>> blog: http://www.jakobk.com >>>>>>> twitter: http://twitter.com/jakobkorherr >>>>>>> work: http://www.irian.at >>>>>>> >>>>> >>>> >>>> >>> >