Re: [DISCUSS] [DELTASPIKE-8] @Veto
@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
Re: [DISCUSS] [DELTASPIKE-8] @Veto
+1 @veto On Thu, Dec 29, 2011 at 10:07 PM, Dan Allen dan.j.al...@gmail.com wrote: On Wed, Dec 28, 2011 at 11:55, Marius Bogoevici marius.bogoev...@gmail.comwrote: 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. I agree. The best suggestion yet, esp since we seem to be at an impasse between @Veto and @Exclude. I think that @NotManaged reads better than @Unmanaged, but I would be happy with either one. -Dan -- 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
Re: [DISCUSS] [DELTASPIKE-8] @Veto
the easiest way in this case is a formal vote about @Veto vs @Exclude vs @Unmanaged/@NotManaged regards, gerhard 2011/12/30 Dan Allen dan.j.al...@gmail.com On Wed, Dec 28, 2011 at 11:55, Marius Bogoevici marius.bogoev...@gmail.comwrote: 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. I agree. The best suggestion yet, esp since we seem to be at an impasse between @Veto and @Exclude. I think that @NotManaged reads better than @Unmanaged, but I would be happy with either one. -Dan -- 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
Re: [DISCUSS] [DELTASPIKE-8] @Veto
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
Re: [DISCUSS] [DELTASPIKE-8] @Veto
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
Re: [DISCUSS] [DELTASPIKE-8] @Veto
+1 for @Veto a.) because it's already established in Seam3 - easier to transit Seam projects b.) because this will also be used in the CDI-1.1 spec itself [1]. Thus users will be familiar with it. LieGrue, strub [1] https://github.com/pmuir/cdi/blob/479e144ccfa0235faf5662355d02a7fe5f6725f6/api/src/main/java/javax/enterprise/inject/Veto.java - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Tuesday, December 27, 2011 12:41 AM Subject: Re: [DISCUSS] [DELTASPIKE-8] @Veto 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
Re: [DISCUSS] [DELTASPIKE-8] @Veto
Altering my vote to @Exclude as it seems more intuitive +1 @Exclude -1 @Veto 1. I would like to see CDI 1.1 adopt the same same if possible. 2. My impression from the user forums is that @Veto in solder has been lightly used outside of module development. The impact of renaming during the conversion to DeltaSpike would have minimal impact to end users and offset by the a more intuitive name going forward. -C On Tue, Dec 27, 2011 at 9:17 AM, Cody Lerum cody.le...@gmail.com wrote: +1 for @Veto Alignment with the CDI spec makes sense. On Tue, Dec 27, 2011 at 7:09 AM, Mark Struberg strub...@yahoo.de wrote: +1 for @Veto a.) because it's already established in Seam3 - easier to transit Seam projects b.) because this will also be used in the CDI-1.1 spec itself [1]. Thus users will be familiar with it. LieGrue, strub [1] https://github.com/pmuir/cdi/blob/479e144ccfa0235faf5662355d02a7fe5f6725f6/api/src/main/java/javax/enterprise/inject/Veto.java - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Tuesday, December 27, 2011 12:41 AM Subject: Re: [DISCUSS] [DELTASPIKE-8] @Veto 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
Re: [DISCUSS] [DELTASPIKE-8] @Veto
+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
Re: [DISCUSS] [DELTASPIKE-8] @Veto
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
Re: [DISCUSS] [DELTASPIKE-8] @Veto
hi john, the basic contract is still the same (the implementation will be the implementation which is currently available in seam3) - just the name is more expressive. regards, gerhard 2011/12/28 John D. Ament john.d.am...@gmail.com 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
Re: [DISCUSS] [DELTASPIKE-8] @Veto
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
Re: [DISCUSS] [DELTASPIKE-8] @Veto
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
Re: [DISCUSS] [DELTASPIKE-8] @Veto
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
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
Re: [DISCUSS] [DELTASPIKE-8] @Veto
+1 for @Veto because Seam3 users are already aware of it. That doesn't mean that I don't like @Skip, but I see no real benefit, and it would be harder for Seam3 users to move migrate. LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Friday, December 23, 2011 9:28 PM Subject: 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
Re: [DISCUSS] [DELTASPIKE-8] @Veto
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
Re: [DISCUSS] [DELTASPIKE-8] @Veto
Sorry the correct abstract class is https://github.com/seam/solder/blob/develop/api/src/main/java/org/jboss/solder/beanManager/BeanManagerAware.javaYou'll have to follow the code around to get all of what it does. On Wed, Dec 14, 2011 at 13:05, Jason Porter lightguard...@gmail.com wrote: As per [1] we're discussing the top features from both CODI (core) and Solder. This issue is for @Veto [2] from Solder. Basic idea: Provide an easy way for application developers to veto beans in their application. Of course users could create their own Extension and veto that way, this does all the boilerplate for them. All the users need to do is annotate the bean(s), or the package in package-info.java and the bean(s) (all in the package if annotated at the package level) will be vetoed. The suggestion is to keep the feature as it currently stands, essentially a copy / paste (package name change) from Solder. Please send +1 +0 -1 for this proposal. If you have *basic* objections please add them to [3] [1] http://markmail.org/message/7yefspfuvtz4jvmp [2] http://docs.jboss.org/seam/3/3.1.0.CR1/reference/en-US/html/solder-programmingmodel.html#d0e338 [3] https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu
Re: [DISCUSS] [DELTASPIKE-8] @Veto
Bah, wrong thread sorry, disregard. On Wed, Dec 14, 2011 at 13:28, Jason Porter lightguard...@gmail.com wrote: Sorry the correct abstract class is https://github.com/seam/solder/blob/develop/api/src/main/java/org/jboss/solder/beanManager/BeanManagerAware.javaYou'll have to follow the code around to get all of what it does. On Wed, Dec 14, 2011 at 13:05, Jason Porter lightguard...@gmail.comwrote: As per [1] we're discussing the top features from both CODI (core) and Solder. This issue is for @Veto [2] from Solder. Basic idea: Provide an easy way for application developers to veto beans in their application. Of course users could create their own Extension and veto that way, this does all the boilerplate for them. All the users need to do is annotate the bean(s), or the package in package-info.java and the bean(s) (all in the package if annotated at the package level) will be vetoed. The suggestion is to keep the feature as it currently stands, essentially a copy / paste (package name change) from Solder. Please send +1 +0 -1 for this proposal. If you have *basic* objections please add them to [3] [1] http://markmail.org/message/7yefspfuvtz4jvmp [2] http://docs.jboss.org/seam/3/3.1.0.CR1/reference/en-US/html/solder-programmingmodel.html#d0e338 [3] https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu
Re: [DISCUSS] [DELTASPIKE-8] @Veto
Suggestions for another name? Or does the list think we should just go with @Typed? On Wed, Dec 14, 2011 at 13:36, Gerhard Petracek gerhard.petra...@gmail.comwrote: we discussed such a feature for codi and didn't add it because of @Typed() @jason: imo @Veto is the wrong name (if there is no real veto) regards, gerhard 2011/12/14 Jason Porter lightguard...@gmail.com Sort of, it doesn't really veto the bean though. You could still inject it by using the concrete type. On Wed, Dec 14, 2011 at 13:24, Mark Struberg strub...@yahoo.de wrote: +1 Of course, the CDI-1.0 way to do this out of the box would be a @Typed() It has a bit a different mechanic, but basically serves the same goal. LieGrue, strub - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Wednesday, December 14, 2011 9:05 PM Subject: [DISCUSS] [DELTASPIKE-8] @Veto As per [1] we're discussing the top features from both CODI (core) and Solder. This issue is for @Veto [2] from Solder. Basic idea: Provide an easy way for application developers to veto beans in their application. Of course users could create their own Extension and veto that way, this does all the boilerplate for them. All the users need to do is annotate the bean(s), or the package in package-info.java and the bean(s) (all in the package if annotated at the package level) will be vetoed. The suggestion is to keep the feature as it currently stands, essentially a copy / paste (package name change) from Solder. Please send +1 +0 -1 for this proposal. If you have *basic* objections please add them to [3] [1] http://markmail.org/message/7yefspfuvtz4jvmp [2] http://docs.jboss.org/seam/3/3.1.0.CR1/reference/en-US/html/solder-programmingmodel.html#d0e338 [3] https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu
Re: [DISCUSS] [DELTASPIKE-8] @Veto
IMHO @Veto is fine - both the name (that corresponds to CDI API) and the way it works in solder. @Ignore as a name seems also acceptable. +0 for @Deactivate - this may be confusing since vetoed (javax.enterprise.inject.spi.ProcessAnnotatedType.veto()) beans are de facto never activated. Anyway this discussion should consider the fact that CDI 1.1 will contain the same functionality - see [1]. Martin [1] https://issues.jboss.org/browse/CDI-50 Dne 14.12.2011 23:23, Gerhard Petracek napsal(a): +1 for @Deactivate +0 for the others regards, gerhard 2011/12/14 Jason Porterlightguard...@gmail.com On IRC I suggested @Deactivate, just to keep all the information here on the list. On Wed, Dec 14, 2011 at 14:31, Gerhard Petracek gerhard.petra...@gmail.comwrote: ok - i thought you mean it differently. however, in our discussion for codi i also didn't like the name (@Veto) a lot because it sounds strange for users who aren't aware of the concept of #veto. the suggestions were: @Ignore @Ignored @NoBean but we couldn't agree on one name and since @Typed() worked for us we didn't continue with it. since @Veto of seam-solder supports packages as well it's a different situation and e.g. @NoBean doesn't fit. - +1 for adding it and +0 for keeping the name regards, gerhard 2011/12/14 Jason Porterlightguard...@gmail.com Yep, that's all @Veto does. At the class level @Typed() works fine for me, perhaps different from a user's point of view, but not a big deal. @Veto will work at a package level though. Do we feel like it's an important feature? On Wed, Dec 14, 2011 at 13:56, Mark Strubergstrub...@yahoo.de wrote: Hmm, I think @Veto is perfectly fine, because all it does is: ProcessAnnotatedType#veto() isn't? LieGrue, strub PS: we decided to not add it to codi because @Typed() does roughly the same and doesn't add any Extension overhead. But actually I don't care much about 5ms more... - Original Message - From: Gerhard Petracekgerhard.petra...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Wednesday, December 14, 2011 9:36 PM Subject: Re: [DISCUSS] [DELTASPIKE-8] @Veto we discussed such a feature for codi and didn't add it because of @Typed() @jason: imo @Veto is the wrong name (if there is no real veto) regards, gerhard 2011/12/14 Jason Porterlightguard...@gmail.com Sort of, it doesn't really veto the bean though. You could still inject it by using the concrete type. On Wed, Dec 14, 2011 at 13:24, Mark Strubergstrub...@yahoo.de wrote: +1 Of course, the CDI-1.0 way to do this out of the box would be a @Typed() It has a bit a different mechanic, but basically serves the same goal. LieGrue, strub - Original Message - From: Jason Porterlightguard...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Wednesday, December 14, 2011 9:05 PM Subject: [DISCUSS] [DELTASPIKE-8] @Veto As per [1] we're discussing the top features from both CODI (core) and Solder. This issue is for @Veto [2] from Solder. Basic idea: Provide an easy way for application developers to veto beans in their application. Of course users could create their own Extension and veto that way, this does all the boilerplate for them. All the users need to do is annotate the bean(s), or the package in package-info.java and the bean(s) (all in the package if annotated at the package level) will be vetoed. The suggestion is to keep the feature as it currently stands, essentially a copy / paste (package name change) from Solder. Please send +1 +0 -1 for this proposal. If you have *basic* objections please add them to [3] [1] http://markmail.org/message/7yefspfuvtz4jvmp [2] http://docs.jboss.org/seam/3/3.1.0.CR1/reference/en-US/html/solder-programmingmodel.html#d0e338 [3] https://cwiki.apache.org/confluence/display/DeltaSpike/SE+Feature+Ranking -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net
