Re: [DISCUSS] [DELTASPIKE-28] ServiceProvider
- 0,5 on supporting Java5 On Wed, Dec 28, 2011 at 9:40 AM, Mark Struberg strub...@yahoo.de wrote: Since we have quite a few vetos against Java5 usage for this new project, I'd say we go with Java6. Java7 is right around the corner, and Java5 is really only legacy now. If projects still need to use java5, they can of course also use Seam3 and CODI until they hava moved their servers. LieGrue, strub - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Friday, December 23, 2011 10:44 AM Subject: Re: [DISCUSS] [DELTASPIKE-28] ServiceProvider If we wanted to try it later that's fine. On Fri, Dec 23, 2011 at 02:41, Mark Struberg strub...@yahoo.de wrote: We could try to use retro-translate to produce java5 compatible artifacts later? LieGrue, strub - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Friday, December 23, 2011 4:45 AM Subject: Re: [DISCUSS] [DELTASPIKE-28] ServiceProvider We have it in Seam, and Weld for that Java 5 support, but I'd prefer to stay on 6+. We *could* do a version compiled for jdk5. But then we get into issues of which branch, making sure it's all Java 5 features, etc. -0.5 On Thu, Dec 22, 2011 at 04:45, José Rodolfo Freitas joserodolfo.frei...@gmail.com wrote: +0 On Thu, Dec 22, 2011 at 9:42 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, this feature won't prevent users from using deltaspike with candi (even if candi only supports java6+). regards, gerhard 2011/12/22 John D. Ament john.d.am...@gmail.com Hi Gerhard, How about resin (CanDI)? John On Thu, Dec 22, 2011 at 6:01 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, the impl. would not be bound to a cdi impl. owb as well as weld (see [1]) support java5. regards, gerhard [1] https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/util/ServiceLoader.java 2011/12/22 John D. Ament john.d.am...@gmail.com -1 Java5 is past EOL at this point. Not suitable for production deployments from my perspective. Java EE 6 (since any code we write for delta spike is against EE6) is for Java SE 6. Even if the implementation is using Java 5 at compilation time, the runtime is 6; and I would hope we would code against spec rather than specific impls. John On Wed, Dec 21, 2011 at 3:41 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi @ all, fyi: please check [1] before you answer. [2] is the implementation used in owb. i suggest to start with it (instead of the version of codi), because the version of codi provides additional mechanisms we might need later on (if we include the corresponding features). the basic concept: ServiceProvider (btw. DefaultLoaderService) is a custom implementation of the ServiceLoader mechanism which allows to use codi with java 1.5 (if the cdi container allows it as well). in case of java6+ the std. ServiceLoader gets used. please send +1, +0 or -1 because... for the basic idea as well as the basic concept. if there are basic objections, please also add them to [3] regards, gerhard [1] http://markmail.org/message/7yefspfuvtz4jvmp [2] https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.1.3/webbeans-impl/src/main/java/org/apache/webbeans/service/DefaultLoaderService.java [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 -- Matthias Wessendorf blog:
[jira] [Resolved] (DELTASPIKE-28) review and discuss ServiceProvider
[ https://issues.apache.org/jira/browse/DELTASPIKE-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-28. Resolution: Later we have to re-visit this topic, if a majority of the community asks for java1.5 support review and discuss ServiceProvider -- Key: DELTASPIKE-28 URL: https://issues.apache.org/jira/browse/DELTASPIKE-28 Project: DeltaSpike Issue Type: Sub-task Reporter: Gerhard Petracek Assignee: Gerhard Petracek -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
//X TODO
Hi! Whenever you spot the following sequence in a class: //X TODO some comment about the 'why' then it means that there is some unfinished stuff lying around... I'd say we now start adding stuff and mark all parts which cause sentiments with such a comment and clean this mess up in a 2nd step later. LieGrue, strub
[jira] [Resolved] (DELTASPIKE-21) ProjectStage
[ https://issues.apache.org/jira/browse/DELTASPIKE-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved DELTASPIKE-21. - Resolution: Fixed Fix Version/s: 0.1-SNAPSHOT Implementation finished ProjectStage Key: DELTASPIKE-21 URL: https://issues.apache.org/jira/browse/DELTASPIKE-21 Project: DeltaSpike Issue Type: New Feature Components: Core Reporter: Gerhard Petracek Assignee: Mark Struberg Fix For: 0.1-SNAPSHOT original feature: https://issues.apache.org/jira/browse/EXTCDI-9 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-20) move util methods to CdiUtils
[ https://issues.apache.org/jira/browse/DELTASPIKE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13176549#comment-13176549 ] Mark Struberg commented on DELTASPIKE-20: - CdiUtils sounds a bit too loose. I'd rather name it ContextualInstanceProvider and let it resolve the BeanManager internally. move util methods to CdiUtils - Key: DELTASPIKE-20 URL: https://issues.apache.org/jira/browse/DELTASPIKE-20 Project: DeltaSpike Issue Type: Sub-task Components: Core Reporter: Gerhard Petracek Assignee: Mark Struberg public T T getContextualReference(ClassT type, boolean optionalBeanAllowed, Annotation... qualifiers) public T T getContextualReference(String name, boolean optionalBeanAllowed, ClassT targetType) public T T getContextualReference(BeanT bean, boolean optionalBeanAllowed, ClassT targetType) public T ListT getContextualReferences(ClassT type, boolean optionalBeanAllowed, Annotation... qualifiers) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] [DELTASPIKE-28] ServiceProvider
-1 for supporting Java5 Let Microsoft deal with the legacy stuff ^^ Regards, Jakob 2011/12/28 Matthias Wessendorf mat...@apache.org: - 0,5 on supporting Java5 On Wed, Dec 28, 2011 at 9:40 AM, Mark Struberg strub...@yahoo.de wrote: Since we have quite a few vetos against Java5 usage for this new project, I'd say we go with Java6. Java7 is right around the corner, and Java5 is really only legacy now. If projects still need to use java5, they can of course also use Seam3 and CODI until they hava moved their servers. LieGrue, strub - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Friday, December 23, 2011 10:44 AM Subject: Re: [DISCUSS] [DELTASPIKE-28] ServiceProvider If we wanted to try it later that's fine. On Fri, Dec 23, 2011 at 02:41, Mark Struberg strub...@yahoo.de wrote: We could try to use retro-translate to produce java5 compatible artifacts later? LieGrue, strub - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Friday, December 23, 2011 4:45 AM Subject: Re: [DISCUSS] [DELTASPIKE-28] ServiceProvider We have it in Seam, and Weld for that Java 5 support, but I'd prefer to stay on 6+. We *could* do a version compiled for jdk5. But then we get into issues of which branch, making sure it's all Java 5 features, etc. -0.5 On Thu, Dec 22, 2011 at 04:45, José Rodolfo Freitas joserodolfo.frei...@gmail.com wrote: +0 On Thu, Dec 22, 2011 at 9:42 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, this feature won't prevent users from using deltaspike with candi (even if candi only supports java6+). regards, gerhard 2011/12/22 John D. Ament john.d.am...@gmail.com Hi Gerhard, How about resin (CanDI)? John On Thu, Dec 22, 2011 at 6:01 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, the impl. would not be bound to a cdi impl. owb as well as weld (see [1]) support java5. regards, gerhard [1] https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/util/ServiceLoader.java 2011/12/22 John D. Ament john.d.am...@gmail.com -1 Java5 is past EOL at this point. Not suitable for production deployments from my perspective. Java EE 6 (since any code we write for delta spike is against EE6) is for Java SE 6. Even if the implementation is using Java 5 at compilation time, the runtime is 6; and I would hope we would code against spec rather than specific impls. John On Wed, Dec 21, 2011 at 3:41 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi @ all, fyi: please check [1] before you answer. [2] is the implementation used in owb. i suggest to start with it (instead of the version of codi), because the version of codi provides additional mechanisms we might need later on (if we include the corresponding features). the basic concept: ServiceProvider (btw. DefaultLoaderService) is a custom implementation of the ServiceLoader mechanism which allows to use codi with java 1.5 (if the cdi container allows it as well). in case of java6+ the std. ServiceLoader gets used. please send +1, +0 or -1 because... for the basic idea as well as the basic concept. if there are basic objections, please also add them to [3] regards, gerhard [1] http://markmail.org/message/7yefspfuvtz4jvmp [2] https://svn.apache.org/repos/asf/openwebbeans/tags/openwebbeans-1.1.3/webbeans-impl/src/main/java/org/apache/webbeans/service/DefaultLoaderService.java [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
Re: [DISCUSS] [DELTASPIKE-28] ServiceProvider
oki, seems the majority is for dropping Java5 support. I've upgraded the parent pom to language target level 1.6 already. Please note that this doesn't mean that we drop JavaEE-5 support! I still like to support CDI containers running on EE-5 if possible. LieGrue, strub - Original Message - From: Jakob Korherr jakob.korh...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Wednesday, December 28, 2011 12:47 PM Subject: Re: [DISCUSS] [DELTASPIKE-28] ServiceProvider -1 for supporting Java5 Let Microsoft deal with the legacy stuff ^^ Regards, Jakob 2011/12/28 Matthias Wessendorf mat...@apache.org: - 0,5 on supporting Java5 On Wed, Dec 28, 2011 at 9:40 AM, Mark Struberg strub...@yahoo.de wrote: Since we have quite a few vetos against Java5 usage for this new project, I'd say we go with Java6. Java7 is right around the corner, and Java5 is really only legacy now. If projects still need to use java5, they can of course also use Seam3 and CODI until they hava moved their servers. LieGrue, strub - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Friday, December 23, 2011 10:44 AM Subject: Re: [DISCUSS] [DELTASPIKE-28] ServiceProvider If we wanted to try it later that's fine. On Fri, Dec 23, 2011 at 02:41, Mark Struberg strub...@yahoo.de wrote: We could try to use retro-translate to produce java5 compatible artifacts later? LieGrue, strub - Original Message - From: Jason Porter lightguard...@gmail.com To: deltaspike-dev@incubator.apache.org Cc: Sent: Friday, December 23, 2011 4:45 AM Subject: Re: [DISCUSS] [DELTASPIKE-28] ServiceProvider We have it in Seam, and Weld for that Java 5 support, but I'd prefer to stay on 6+. We *could* do a version compiled for jdk5. But then we get into issues of which branch, making sure it's all Java 5 features, etc. -0.5 On Thu, Dec 22, 2011 at 04:45, José Rodolfo Freitas joserodolfo.frei...@gmail.com wrote: +0 On Thu, Dec 22, 2011 at 9:42 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, this feature won't prevent users from using deltaspike with candi (even if candi only supports java6+). regards, gerhard 2011/12/22 John D. Ament john.d.am...@gmail.com Hi Gerhard, How about resin (CanDI)? John On Thu, Dec 22, 2011 at 6:01 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi john, the impl. would not be bound to a cdi impl. owb as well as weld (see [1]) support java5. regards, gerhard [1] https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/util/ServiceLoader.java 2011/12/22 John D. Ament john.d.am...@gmail.com -1 Java5 is past EOL at this point. Not suitable for production deployments from my perspective. Java EE 6 (since any code we write for delta spike is against EE6) is for Java SE 6. Even if the implementation is using Java 5 at compilation time, the runtime is 6; and I would hope we would code against spec rather than specific impls. John On Wed, Dec 21, 2011 at 3:41 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi @ all, fyi: please check [1] before you answer. [2] is the implementation used in owb. i suggest to start with it (instead of the version of codi), because the version of codi provides additional mechanisms we might need later on (if we include the corresponding features). the basic concept: ServiceProvider (btw. DefaultLoaderService) is a custom implementation of the ServiceLoader mechanism which allows to use codi with java 1.5 (if the cdi container allows it as well). in case of java6+ the std. ServiceLoader gets used. please send +1, +0 or -1 because... for the basic idea as well as the basic concept. if there are basic objections, please also add them to [3] regards, gerhard [1] http://markmail.org/message/7yefspfuvtz4jvmp [2]
[jira] [Resolved] (DELTASPIKE-20) move util methods to CdiUtils
[ https://issues.apache.org/jira/browse/DELTASPIKE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved DELTASPIKE-20. - Resolution: Fixed Fix Version/s: 0.1-SNAPSHOT resolved as part of the work for DELTASPIKE-17 move util methods to CdiUtils - Key: DELTASPIKE-20 URL: https://issues.apache.org/jira/browse/DELTASPIKE-20 Project: DeltaSpike Issue Type: Sub-task Components: Core Reporter: Gerhard Petracek Assignee: Mark Struberg Fix For: 0.1-SNAPSHOT public T T getContextualReference(ClassT type, boolean optionalBeanAllowed, Annotation... qualifiers) public T T getContextualReference(String name, boolean optionalBeanAllowed, ClassT targetType) public T T getContextualReference(BeanT bean, boolean optionalBeanAllowed, ClassT targetType) public T ListT getContextualReferences(ClassT type, boolean optionalBeanAllowed, Annotation... qualifiers) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
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
[jira] [Resolved] (DELTASPIKE-24) Deactivatable
[ https://issues.apache.org/jira/browse/DELTASPIKE-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved DELTASPIKE-24. Resolution: Fixed Deactivatable - Key: DELTASPIKE-24 URL: https://issues.apache.org/jira/browse/DELTASPIKE-24 Project: DeltaSpike Issue Type: New Feature Components: Core Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 0.1-SNAPSHOT original feature: https://issues.apache.org/jira/browse/EXTCDI-66 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-36) review and discuss ConfiguredValueResolver
[ https://issues.apache.org/jira/browse/DELTASPIKE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13176957#comment-13176957 ] Gerhard Petracek commented on DELTASPIKE-36: https://git-wip-us.apache.org/repos/asf?p=incubator-deltaspike.git;a=commit;h=fb0131106481f0b9a8fdc13b9879a5482219c736 https://git-wip-us.apache.org/repos/asf?p=incubator-deltaspike.git;a=commit;h=81170a8b0e72eb7d3a45ace61b0443503bce9333 ... is a completely new and simple but flexible implementation which illustrates an easier but very pluggable approach which allows different config-sources as well as re-ordering existing config-sources. review and discuss ConfiguredValueResolver -- Key: DELTASPIKE-36 URL: https://issues.apache.org/jira/browse/DELTASPIKE-36 Project: DeltaSpike Issue Type: Sub-task Components: Core Reporter: Gerhard Petracek Assignee: Gerhard Petracek for several features we need a pluggable config-service which has to be independent of cdi because it's needed e.g. during the bootstrapping process of a cdi container. an implementation is aware of a config source like property-files or xml files or jndi values and has to return 1-n configured values for a given key. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (DELTASPIKE-36) review and discuss ConfiguredValueResolver
[ https://issues.apache.org/jira/browse/DELTASPIKE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13176957#comment-13176957 ] Gerhard Petracek edited comment on DELTASPIKE-36 at 12/29/11 2:47 AM: -- https://git-wip-us.apache.org/repos/asf?p=incubator-deltaspike.git;a=commit;h=fb0131106481f0b9a8fdc13b9879a5482219c736 https://git-wip-us.apache.org/repos/asf?p=incubator-deltaspike.git;a=commit;h=81170a8b0e72eb7d3a45ace61b0443503bce9333 ... is a completely new and simple but flexible implementation which illustrates an easier but very pluggable approach which allows different config-sources as well as re-ordering existing config-sources. (it will be discussed as soon as it is ready for a review) was (Author: gpetracek): https://git-wip-us.apache.org/repos/asf?p=incubator-deltaspike.git;a=commit;h=fb0131106481f0b9a8fdc13b9879a5482219c736 https://git-wip-us.apache.org/repos/asf?p=incubator-deltaspike.git;a=commit;h=81170a8b0e72eb7d3a45ace61b0443503bce9333 ... is a completely new and simple but flexible implementation which illustrates an easier but very pluggable approach which allows different config-sources as well as re-ordering existing config-sources. review and discuss ConfiguredValueResolver -- Key: DELTASPIKE-36 URL: https://issues.apache.org/jira/browse/DELTASPIKE-36 Project: DeltaSpike Issue Type: Sub-task Components: Core Reporter: Gerhard Petracek Assignee: Gerhard Petracek for several features we need a pluggable config-service which has to be independent of cdi because it's needed e.g. during the bootstrapping process of a cdi container. an implementation is aware of a config source like property-files or xml files or jndi values and has to return 1-n configured values for a given key. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
