On 2011-12-28, at 10:05 AM, Mark Struberg 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.
Well, I would say that domain entities may be an even more common use case, but
I see where you're coming from.
>
> The spec conform easy way would be to simply use
>
> @Typed()
> public class MyBean {}
While this usage is allowed by the spec, I'm not particularly fond of it. The
net result is to create a managed bean which is neither usable, nor (at least
in my case) easy on the eyes. It's more like a hack or a gotcha.
>
> 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!
If anything, I think that @Typed should be more restrictive and require at
least one type (cannot find a justification for creating a bean with no actual
types, even if optimization would skip over it). However, that is a discussion
for a different place :).
@Veto or any of its aliases, serves a different purpose: it precludes the class
from being treated as a managed bean altogether. Plus, @Typed is absolutely
awkward to use on a package.
I like @Veto over @Exclude, but I got converted to the the "avoiding the
technicalities" doctrine, so I suggested @Unmanaged (or even @NotManaged, or
anything that refers to "class as a managed bean" in the spirit of 3.1.1).
Overall, I think that @Unmanaged is a better fit, for the reasons I explained
previously. I think that renaming is not such a big issue, in the light of a
DeltaSpike migration.
>
> 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
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
