September 2014 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-460) Support repeating qualifiers in CDI SPI

by Antonin Stefanutti (JIRA)

[ https://issues.jboss.org/browse/CDI-460?page=com.atlassian.jira.plugin.sy... ] Antonin Stefanutti updated CDI-460: ----------------------------------- Summary: Support repeating qualifiers in CDI SPI (was: Support repeating qualifiers) > Support repeating qualifiers in CDI SPI > --------------------------------------- > > Key: CDI-460 > URL: https://issues.jboss.org/browse/CDI-460 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 2.0 (discussion) > Reporter: Antonin Stefanutti > > In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations: > {{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}}, > {{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}}, > {{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}. > Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection. > Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repea...], it seems logical to have repeating annotations supported at the CDI SPI level. Tough, that's important to have that support explicitly stated and specified in CDI. > Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification. > That applies as well for {{EventMetadata.getQualifiers}} in _read-only_. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-460) Support repeating qualifiers

by Antonin Stefanutti (JIRA)

[ https://issues.jboss.org/browse/CDI-460?page=com.atlassian.jira.plugin.sy... ] Antonin Stefanutti updated CDI-460: ----------------------------------- Summary: Support repeating qualifiers (was: Support repeatable qualifiers) > Support repeating qualifiers > ---------------------------- > > Key: CDI-460 > URL: https://issues.jboss.org/browse/CDI-460 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 2.0 (discussion) > Reporter: Antonin Stefanutti > > In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations: > {{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}}, > {{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}}, > {{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}. > Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection. > Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repea...], it seems logical to have repeating annotations supported at the CDI SPI level. Tough, that's important to have that support explicitly stated and specified in CDI. > Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification. > That applies as well for {{EventMetadata.getQualifiers}} in _read-only_. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-460) Support repeatable qualifiers

by Antonin Stefanutti (JIRA)

Antonin Stefanutti created CDI-460: -------------------------------------- Summary: Support repeatable qualifiers Key: CDI-460 URL: https://issues.jboss.org/browse/CDI-460 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Affects Versions: 2.0 (discussion) Reporter: Antonin Stefanutti In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations: {{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}}, {{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}}, {{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}. Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection. Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repea...], it seems logical to have repeating annotations supported at the CDI SPI level. Tough, that's important to have that support explicitly stated and specified in CDI. Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification. That applies as well for {{EventMetadata.getQualifiers}} in _read-only_. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition

by Anatole Tresch (JIRA)

[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ] Anatole Tresch commented on CDI-456: ------------------------------------ +1 -- *Anatole Tresch* Java Lead Engineer, JSR Spec Lead Glärnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ <http://javaremarkables.blogspot.ch/>* *Google: atsticksMobile +41-76 344 62 79* > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-456: ------------------------------------------ We all know there are issues with the Java EE module architecture. This has to be fix at Java EE level and CDI spec will have to follow not the other way around. Now, regarding this ticket I think Jozef explained more than once why {{Bean#getBeanClass()}} should behave this way. Yet I understand the need to get the exact type of a given bean instances. So IMO we should split this ticket in 2 : # Clarify the javadoc and spec description of {{Bean#getBeanClass()}} to avoid confusion # Add a new method to {{Bean}} returning the exact type of the bean instances. something like {{Bean#getInstanceClass()}} > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 6 months

2
1
0 / 0

[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-456: ---------------------------------------- [~antoinesabot-durand] globally agree, I think producer (method/field) should also get a specific issue to make explicit that's a container thing (or allow providing new API to user to create some). This can make sense actually to allow to create programmatically producers > fix Bean#getBeanClass() definition > ---------------------------------- > > Key: CDI-456 > URL: https://issues.jboss.org/browse/CDI-456 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > > currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field. > Imo this only causes troubles and doesn't add any benefit. > * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created. > * At the time we create interceptors we ONLY need the type which is to be created; > * At the time we create the normalscoping proxies we ONLY need the type which is to be created; > In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class! > In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 6 months

1
0
0 / 0

Actualisation de l’événement : CDI weekly meeting

by Antoine Sabot-Durand

10 years, 6 months

1
0
0 / 0

Updated Invitation: CDI weekly meeting @ Weekly from 18:00 to 19:00 on Wednesday (ASD Perso)

by antoine＠sabot-durand.net

This event has been changed. Title: CDI weekly meeting View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3B.... View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3B.... View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3B.... (changed) When: Weekly from 18:00 to 19:00 on Wednesday Paris Where: IRC #cdi-dev channel on freenode Calendar: ASD Perso Who: * Antoine Sabot-Durand- organiser * cdi-dev(a)lists.jboss.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3B... Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev(a)lists.jboss.org because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively, you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

10 years, 6 months

1
0
0 / 0

Updated Invitation: CDI weekly meeting @ Weekly from 18:00 to 19:00 on Wednesday (ASD Perso)

by antoine＠sabot-durand.net

This event has been changed. Title: CDI weekly meeting View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3B.... View your event at https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3B.... When: Weekly from 18:00 to 19:00 on Wednesday Paris Where: IRC #cdi-dev channel on freenode Calendar: ASD Perso Who: * Antoine Sabot-Durand- organiser * cdi-dev(a)lists.jboss.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=YmdhdXVtcDdnNjhlM3B... Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev(a)lists.jboss.org because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively, you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

10 years, 6 months

1
0
0 / 0

Actualisation de l’événement : CDI weekly meeting

by Antoine Sabot-Durand

10 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 September 2014