July 2016 - cdi-dev - Jboss List Archives

by Antoine Sabot-Durand

Hi all, So we have this planned meeting in one hour to discuss John PR: https://github.com/cdi-spec/cdi/pull/296 Who will join it ? Antoine

8 years, 6 months

3
2
0 / 0

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

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/CDI-621?page=com.atlassian.jira.plugin.sy... ] Matej Novotny commented on CDI-621: ----------------------------------- I am also unsure of what the ambiguity is in this case. Do you mean you would rather rename the method to something like {{removeAllAnnotations}}? In that case you might say that all the methods are ambiguous... > 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, 6 months

1
0
0 / 0

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

by John Ament (JIRA)

John Ament created CDI-623: ------------------------------ Summary: 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 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, 6 months

1
0
0 / 0

Canceling today's meeting

by Antoine Sabot-Durand

Hi All, I won't be able tot attend today's meeting but you continue reviewing the main PR for EDR2: https://github.com/cdi-spec/cdi/pull/290 https://github.com/cdi-spec/cdi/pull/296 Antoine

8 years, 6 months

2
8
0 / 0

CDI F2F finale date : Sept 6-7

by Antoine Sabot-Durand

Hi all, Just closed the Doodle and choose the best date (with Java One in mind). So the f2f will take place Tuesday 6th and Wednesday 7th in Red Hat office in Brno (Czech Republic) If you didn't participate to the Doodle but wish to attend, please make me know. I'll post more information on the location and the program shortly. Antoine

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-622) External post-configuration of a bean

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-622?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-622: ---------------------------------- Why not use events/observers and {{@PostConstruct}}? The framework developer may even use some special "configuration holder" as a payload so that the final instance does not leak. > External post-configuration of a bean > ------------------------------------- > > Key: CDI-622 > URL: https://issues.jboss.org/browse/CDI-622 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > > The use case here is that a framework has provided the application developer with some bean, X. While the framework can provide internal post construction support for this bean, the application developer has some need to set additional attributes on the bean prior to the bean being injected into its final target. > The application developer currently has no way to do this. To accomplish this feat, the framework developer must put the burden on the application developer to do both configuration and bootstrapping of this bean. This is a bit of a pain point to be honest. > One idea I had was to introduce a {{@Configures}} annotation that could be used, similar to observers. These methods (plural) could be called (based on priority) during the post construct phase and may exist in any managed bean. > {code} > @Configures > public void setupWebServer(WebServer webserver, Configuration configuration) { > webserver.setPort(configuration.getWebServerPort()); > } > {code} > In this case, webserver is the bean being configured, configuration is some other bean that retains the configuration data. This should support normal qualifiers, and perhaps provide an injection point for the underlying {{InjectionTarget}} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

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

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-621?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-621: ---------------------------------- [~meetoblivion] I assume you're talking about {{AnnotatedTypeConfigurator.removeAll()}} and similar methods. If so, then I don't see any ambiguity since the annotations ARE the only thing to configure there (e.g. the set of methods is immutable). > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-622) External post-configuration of a bean

by John Ament (JIRA)

John Ament created CDI-622: ------------------------------ Summary: External post-configuration of a bean Key: CDI-622 URL: https://issues.jboss.org/browse/CDI-622 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament The use case here is that a framework has provided the application developer with some bean, X. While the framework can provide internal post construction support for this bean, the application developer has some need to set additional attributes on the bean prior to the bean being injected into its final target. The application developer currently has no way to do this. To accomplish this feat, the framework developer must put the burden on the application developer to do both configuration and bootstrapping of this bean. This is a bit of a pain point to be honest. One idea I had was to introduce a {{@Configures}} annotation that could be used, similar to observers. These methods (plural) could be called (based on priority) during the post construct phase and may exist in any managed bean. {code} @Configures public void setupWebServer(WebServer webserver, Configuration configuration) { webserver.setPort(configuration.getWebServerPort()); } {code} In this case, webserver is the bean being configured, configuration is some other bean that retains the configuration data. This should support normal qualifiers, and perhaps provide an injection point for the underlying {{InjectionTarget}} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

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

by arjan tijms (JIRA)

[ https://issues.jboss.org/browse/CDI-620?page=com.atlassian.jira.plugin.sy... ] arjan tijms commented on CDI-620: --------------------------------- +1 for this issue. In Soteria we were a bit confused too about what to provide here. Implementation detail; Weld accepts a null for the ID, while OWB throws an exception. {{BeforeBeanDiscovery#addAnnotatedType}} has a similar problem, although the javadoc at least mention the id there it's still not overly clear what "The id of the annotated type" should be. > 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 > > 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, 6 months

1
0
0 / 0

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

by John Ament (JIRA)

John Ament created CDI-621: ------------------------------ Summary: 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, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev July 2016