@Typed() makes absolutely no sense to me (intuitively), which is why I have
never liked promoting it. While it does work, I consider it to be a hack.
-Dan
On Wed, Dec 28, 2011 at 10:05, Mark Struberg <strub...@yahoo.de> wrote:
> 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
> >>>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >
>
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction
