deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [DISCUSS] [DELTASPIKE-8] @Veto
Date Wed, 28 Dec 2011 15:05:25 GMT
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.bogoevici@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.petracek@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.bogoevici@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.korherr@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 <pmuir@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.petracek@gmail.com>:
>>>>>>>>>>  hi arne,
>>>>>>>>>> 
>>>>>>>>>>  would be also ok for me -> +1
>>>>>>>>>> 
>>>>>>>>>>  regards,
>>>>>>>>>>  gerhard
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>  2011/12/23 Arne Limburg 
> <arne.limburg@openknowledge.de>
>>>>>>>>>> 
>>>>>>>>>>>  What about @Exclude?
>>>>>>>>>>> 
>>>>>>>>>>>  Cheers,
>>>>>>>>>>>  Arne
>>>>>>>>>>> 
>>>>>>>>>>>  -----Ursprüngliche Nachricht-----
>>>>>>>>>>>  Von: Gerhard Petracek 
> [mailto:gerhard.petracek@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.allen@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
>>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
> 

Mime
View raw message