June 2015 - cdi-dev - Jboss List Archives

[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 updated CDI-456: ------------------------------------- Fix Version/s: 2.0 (discussion) > 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 > Fix For: 2.0 (discussion) > > > 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.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-477) Update outdated package-info.java in javax.enterprise.inject package

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-477?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-477: ------------------------------------- Fix Version/s: 2.0 (discussion) > Update outdated package-info.java in javax.enterprise.inject package > -------------------------------------------------------------------- > > Key: CDI-477 > URL: https://issues.jboss.org/browse/CDI-477 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > Update or remove this javadoc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-498) Revise "6.7.5. The Conversation interface" - dots are not valid in EL name

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-498?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-498: ------------------------------------- Fix Version/s: 2.0 (discussion) > Revise "6.7.5. The Conversation interface" - dots are not valid in EL name > -------------------------------------------------------------------------- > > Key: CDI-498 > URL: https://issues.jboss.org/browse/CDI-498 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Tomas Remes > Fix For: 2.0 (discussion) > > > Seems that following part contradicts the EL spec: > {quote}The container provides a built-in bean with bean type Conversation , scope @RequestScoped , > and qualifier @Default , named javax.enterprise.context.conversation .{quote} > The EL name "javax.enterprise.context.conversation" is not valid. > Discussion available at http://transcripts.jboss.org/channel/irc.freenode.org/%23cdi-dev/2015/%23... > and > http://lists.jboss.org/pipermail/cdi-dev/2015-January/thread.html - topic "where is defined javax.enterprise.context.conversation.id?" -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-510) Update JCP license

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-510?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand resolved CDI-510. -------------------------------------- Assignee: Antoine Sabot-Durand Fix Version/s: 2.0-EDR1 Resolution: Done > Update JCP license > ------------------ > > Key: CDI-510 > URL: https://issues.jboss.org/browse/CDI-510 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR1 > > > Update the JCP license file to reflect CDI 2.0, JSR 365 (instead of JSR 346) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-531) CDI JavaDocs link to Extension Architecture broken

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-531?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand resolved CDI-531. -------------------------------------- Assignee: Antoine Sabot-Durand Fix Version/s: 2.0-EDR1 Resolution: Done Correct link was in Jar specification : https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#sealing > CDI JavaDocs link to Extension Architecture broken > -------------------------------------------------- > > Key: CDI-531 > URL: https://issues.jboss.org/browse/CDI-531 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Joseph Snyder > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR1 > > > It appears that the Java SE team have moved their "Extension Architecture" documentation. This invalidates the link in the CDI JavaDocs we publish as follows: > In the file: > cdi-api-1.2-sources\javax\enterprise\inject\Vetoed.java > Is a link in the meta data for JavaDoc: > <a href="http://download.java.net/jdk8/docs/technotes/guides/extensions/spec.html#..."> > Which returns <404>, file not found. > I suspect this is now moved to: > https://docs.oracle.com/javase/8/docs/technotes/guides/extensions/spec.html > But I can't be sure because there's no Anchor titled "sealing" in that moved document. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-490: ------------------------------------- Fix Version/s: 2.0 (discussion) > Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml > ------------------------------------------------------------------------------------------------ > > Key: CDI-490 > URL: https://issues.jboss.org/browse/CDI-490 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators, Interceptors > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because: > {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final > list of interceptors for the application, as defined in Section 11.5.2, “AfterTypeDiscovery event”.{quote} > it matches both parts of the statement. > As for ordering, the following statement defines invocation order: > {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote} > Since InterceptorA is enabled by both @Priority and beans.xml, the following applies: > "Interceptors enabled using @Priority" = \{ InterceptorA \} > "interceptors enabled using beans.xml" = \{ InterceptorA \} > We can perform substitution in the statement and we get: > *\{ InterceptorA \} are called before \{ InterceptorA \}* > which does not seem right. > The specification should explicitly address this scenario. There are several options (some of them are better, some are worse): > 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml > 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence) > 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence) > 4) Forbid an interceptor to be enabled by both @Priority and beans.xml -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-500) Clarify @Intercepted Bean metadata injection for EE components

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-500?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-500: ------------------------------------- Fix Version/s: 2.0 (discussion) > Clarify @Intercepted Bean metadata injection for EE components > -------------------------------------------------------------- > > Key: CDI-500 > URL: https://issues.jboss.org/browse/CDI-500 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > It's not clear what should happen when an interceptor with {{@Intercepted Bean}} metadata is associated with an EE component. > See the CDI spec, "5.5.8. Bean metadata": > {quote} > Additionally, the container must provide beans allowing interceptors and decorators to obtain information about the beans they intercept and decorate: > * a bean with scope @Dependent, qualifier @Intercepted and type Bean which can be injected into any interceptor instance, and > * ... > {quote} > However, most EE components must also support the use of CDI interceptors. See also the Java EE 7 spec, "EE.5.2.5 Annotations and Injection": > {quote} > The component classes listed in Table EE.5-1 with support level "Standard" > all support Java EE resource injection, as well as PostConstruct and PreDestroy callbacks. In addition, if CDI is enabled—which it is by default—these classes also support CDI injection, as described in Section EE.5.24, "Support for Dependency Injection", and the use of interceptors. > {quote} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-502) Clarify "contains" meaning in "Legal bean types" specification.

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-502?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand reassigned CDI-502: ---------------------------------------- Assignee: Antoine Sabot-Durand > Clarify "contains" meaning in "Legal bean types" specification. > --------------------------------------------------------------- > > Key: CDI-502 > URL: https://issues.jboss.org/browse/CDI-502 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Inheritance and Specialization > Reporter: Tomasz Krakowiak > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > CDI 1.1, section 2.2.1. Legal bean types says: > {quote} > A parameterized type that contains a wildcard type parameter is not a legal bean type. > {quote} > Does it means direct containment or deep/recursive containment? > I understand this is clearly illegal: > {code} > @Produces > List<?> produceList(){ > //... > } > {code} > But, are those two bean definitions legal: > {code} > @Produces > List<Optional<?>> produceList(){ > //... > } > {code} > {code} > // Bean types: MyList, List<Optional<?>>, Object > // or > // Bean types: MyList, Object > @Dependent > MyList extends List<Optional<?>> { > //... > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-502) Clarify "contains" meaning in "Legal bean types" specification.

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-502?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-502: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: 2.0-EDR1) > Clarify "contains" meaning in "Legal bean types" specification. > --------------------------------------------------------------- > > Key: CDI-502 > URL: https://issues.jboss.org/browse/CDI-502 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Inheritance and Specialization > Reporter: Tomasz Krakowiak > Fix For: 2.0 (discussion) > > > CDI 1.1, section 2.2.1. Legal bean types says: > {quote} > A parameterized type that contains a wildcard type parameter is not a legal bean type. > {quote} > Does it means direct containment or deep/recursive containment? > I understand this is clearly illegal: > {code} > @Produces > List<?> produceList(){ > //... > } > {code} > But, are those two bean definitions legal: > {code} > @Produces > List<Optional<?>> produceList(){ > //... > } > {code} > {code} > // Bean types: MyList, List<Optional<?>>, Object > // or > // Bean types: MyList, Object > @Dependent > MyList extends List<Optional<?>> { > //... > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-502) Clarify "contains" meaning in "Legal bean types" specification.

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-502?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-502: ------------------------------------- Fix Version/s: 2.0-EDR1 > Clarify "contains" meaning in "Legal bean types" specification. > --------------------------------------------------------------- > > Key: CDI-502 > URL: https://issues.jboss.org/browse/CDI-502 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Inheritance and Specialization > Reporter: Tomasz Krakowiak > Fix For: 2.0 (discussion) > > > CDI 1.1, section 2.2.1. Legal bean types says: > {quote} > A parameterized type that contains a wildcard type parameter is not a legal bean type. > {quote} > Does it means direct containment or deep/recursive containment? > I understand this is clearly illegal: > {code} > @Produces > List<?> produceList(){ > //... > } > {code} > But, are those two bean definitions legal: > {code} > @Produces > List<Optional<?>> produceList(){ > //... > } > {code} > {code} > // Bean types: MyList, List<Optional<?>>, Object > // or > // Bean types: MyList, Object > @Dependent > MyList extends List<Optional<?>> { > //... > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev June 2015