2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev August 2016

cdi-dev@lists.jboss.org

14 participants
90 discussions

Start a nNew thread

[JBoss JIRA] (CDI-621) removeAll method can lead to ambiguities

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-621?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-621: ---------------------------------------- what about ignoreAnnotations() or ignoreReflection() (a bit like ignoreXmlConfiguration() in bean validation Configuration<?>) > removeAll method can lead to ambiguities > ---------------------------------------- > > Key: CDI-621 > URL: https://issues.jboss.org/browse/CDI-621 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > > The method removeAll is ambiguous. This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe. The removeAll method presupposes that annotations are the only thing to configure. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-621) removeAll method can lead to ambiguities

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-621?page=com.atlassian.jira.plugin.sy... ] John Ament commented on CDI-621: -------------------------------- Its not clear from looking at the method name that only the annotations are removed. It might be better to call it something like {{clearAnnotations}} or similar. As mentioned, the other two are not an issue, since they're explicitly taking annotation parameters when doing their remove. Again, this is all from my POV. > removeAll method can lead to ambiguities > ---------------------------------------- > > Key: CDI-621 > URL: https://issues.jboss.org/browse/CDI-621 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > > The method removeAll is ambiguous. This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe. The removeAll method presupposes that annotations are the only thing to configure. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-620) Not clear what the id for an annotated type is.

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-620?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-620: ------------------------------------------ Yes we should change parameter order. > Not clear what the id for an annotated type is. > ----------------------------------------------- > > Key: CDI-620 > URL: https://issues.jboss.org/browse/CDI-620 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The docs for AfterTypeDiscovery.addAnnotatedType(String, Class) do not state what the id is. > In addition, it's odd that the addAnnotatedType(AnnotatedType, String) is in that order, and this method is in this order. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-620) Not clear what the id for an annotated type is.

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-620?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-620: ------------------------------------- Labels: F2F2016 (was: ) > Not clear what the id for an annotated type is. > ----------------------------------------------- > > Key: CDI-620 > URL: https://issues.jboss.org/browse/CDI-620 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The docs for AfterTypeDiscovery.addAnnotatedType(String, Class) do not state what the id is. > In addition, it's odd that the addAnnotatedType(AnnotatedType, String) is in that order, and this method is in this order. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-620) Not clear what the id for an annotated type is.

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-620?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-620: ------------------------------------- Fix Version/s: 2.0 (proposed) (was: 2.0 (discussion)) > Not clear what the id for an annotated type is. > ----------------------------------------------- > > Key: CDI-620 > URL: https://issues.jboss.org/browse/CDI-620 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > The docs for AfterTypeDiscovery.addAnnotatedType(String, Class) do not state what the id is. > In addition, it's odd that the addAnnotatedType(AnnotatedType, String) is in that order, and this method is in this order. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-621) removeAll method can lead to ambiguities

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-621?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-621: ------------------------------------------ [~meetoblivion] as Martin and Matej already said, your ambiguity is... ambiguous ;). Could you detail please. > removeAll method can lead to ambiguities > ---------------------------------------- > > Key: CDI-621 > URL: https://issues.jboss.org/browse/CDI-621 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > > The method removeAll is ambiguous. This problem doesn't exist for remove(Annotation) or remove(Class) since they're type safe. The removeAll method presupposes that annotations are the only thing to configure. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-471: ------------------------------------- Fix Version/s: 2.0 (discussion) > Support repeating qualifiers in typesafe resolution mechanism > ------------------------------------------------------------- > > Key: CDI-471 > URL: https://issues.jboss.org/browse/CDI-471 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Reporter: Antonin Stefanutti > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repea...], it would be valuable to percolate that support into the CDI typesafe resolution mechanism. > For example, one could write: > {code} > @Qualifier > @Repeatable(ContextNames.class) > public interface @ContextName { > String value; > } > public @interface ContextNames { > ContextName[] value(); > } > {code} > And then: > {code} > @ContextName("ctx1") > class CamelContext1 { > } > @ContextName("ctx2") > class CamelContext2 { > } > @Uri("") > @Produces > @ContextName("ctx1") > @ContextName("ctx2") > static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance<CamelContext> instance) { > } > {code} > That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies. > Support of the annotation container / list for backward compatibility could be provided as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-623) Specify what happens when calling addObserverMethod or addBean alone

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-623?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-623: ------------------------------------------ [~manovotn], [~mkouba], I think we are mixing 2 illegal state here: * A defined bean that is illegal. This ticket shouldn't change nothing about this * A bean to build thru a configurator that was not defined (which has no defined type set or code to create instances). Second case is our matter here. Now,I agree that it may be difficult to specify the minimum required to have a configurator ready to create a defined bean. Anyway implementation will have to do this. Calling {{BeforeBeanDiscovery.addAnnotatedType()}} without using the returned configurator should trigger an exception at the end of BBD invocation. > Specify what happens when calling addObserverMethod or addBean alone > -------------------------------------------------------------------- > > Key: CDI-623 > URL: https://issues.jboss.org/browse/CDI-623 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > AfterBeanDiscovery exposes methods addObserverMethod and addBean. Both essentially leave dangling configurations that are not usable. > I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-623) Specify what happens when calling addObserverMethod or addBean alone

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-623?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand edited comment on CDI-623 at 8/31/16 4:43 AM: ------------------------------------------------------------------- I guess that [~meetoblivion] is talking of the case were a configurator is requested and the user doesn't do anything with it. That's good point, since the "build" method of these builder is hidden we still have to specify what is the minimum info we have to add to these configurators to be able to build them. So we need: # specify what is the minimum configuration user has to put in a {{BeanConfigurator}} and {{ObserverMethodConfigurator}} to make them viable. Probably the same for other configurators # what should be the behaviour of the container in case of a non viable Configurator (abd.add*()) was called and nothing (or non mimimum requirement) was done with the returned configurator. ISE seems to be the best choice here was (Author: antoinesabot-durand): I guess that [~meetoblivion] is talking of the case were a configurator is requested and the user doesn't do anything with it. That's good point, since the "build" method of these builder is hidden we still have to specify what is the minimum info we have to add to these configurators to be able to build them. So we need: # specify what is the minimum configuration user has to put in a {{BeanConfigurator}} and {{ObserverMethodConfigurator}} to make them viable. Propbaly the same for toher configurator # what shoudl be the behaviour ot eh container in case of a non viable Configurator (abd.add*()) was called and nothing (or non mimimum requirement) was done with the returned configurator. ISE seems to be the best choice here > Specify what happens when calling addObserverMethod or addBean alone > -------------------------------------------------------------------- > > Key: CDI-623 > URL: https://issues.jboss.org/browse/CDI-623 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > AfterBeanDiscovery exposes methods addObserverMethod and addBean. Both essentially leave dangling configurations that are not usable. > I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-623) Specify what happens when calling addObserverMethod or addBean alone

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/CDI-623?page=com.atlassian.jira.plugin.sy... ] Matej Novotny commented on CDI-623: ----------------------------------- I am fine with saying that obtaining a configurator without doing actual work doesn't make sense and we should throw an exception (ISE most likely). However I am not convinced we should describe the minimum info as that can get pretty complex especially if combined with {{read}} methods. (Which sort of leads to https://issues.jboss.org/browse/CDI-614) > Specify what happens when calling addObserverMethod or addBean alone > -------------------------------------------------------------------- > > Key: CDI-623 > URL: https://issues.jboss.org/browse/CDI-623 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > AfterBeanDiscovery exposes methods addObserverMethod and addBean. Both essentially leave dangling configurations that are not usable. > I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

← Newer
1
2
3
4
5
6
7
8
9
Older →