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 <[email protected]>
> To: [email protected]
> 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 <
>> [email protected]> wrote:
>>
>>> +1 for @Unmanaged
>>> (+1 for @Exclude if it's the only alternative we can agree on)
>>>
>>> regards,
>>> gerhard
>>>
>>>
>>>
>>> 2011/12/28 Marius Bogoevici <[email protected]>
>>>
>>>> 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 <[email protected]>
>>>>>>
>>>>>>> +1 to @Veto and @Exclude
>>>>>>>
>>>>>>> Also I agree with Pete's comments about the other
> suggestions.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Jakob
>>>>>>>
>>>>>>> 2011/12/24 Pete Muir <[email protected]>:
>>>>>>>> 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
> <[email protected]>:
>>>>>>>>>> hi arne,
>>>>>>>>>>
>>>>>>>>>> would be also ok for me -> +1
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>> gerhard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2011/12/23 Arne Limburg
> <[email protected]>
>>>>>>>>>>
>>>>>>>>>>> What about @Exclude?
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Arne
>>>>>>>>>>>
>>>>>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>>>>>> Von: Gerhard Petracek
> [mailto:[email protected]]
>>>>>>>>>>> Gesendet: Freitag, 23. Dezember 2011
> 21:28
>>>>>>>>>>> An: [email protected]
>>>>>>>>>>> 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
> <[email protected]>
>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>
>>>>>
>>>>
>>>>
>>>
>
