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