December 2016 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-671) SPI element related to Instance are missing info about their qualifier

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-671?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-671: ---------------------------------- The other approach would be to simulate injection of {{Instance}} (this is what Weld does): ||Injection point||Required type||Required qualifier||{{CDI}} equivalent|| |{{@Inject Instance<Object>}}|Object|(a)Default|CDI.current()| |{{@Inject @Any Instance<Object>}}|Object|(a)Any|CDI.current().select(Any.Literal.INSTANCE)| |{{@Inject Instance<Foo>}}|Foo|(a)Default|CDI.current().select(Foo.class)| |{{@Inject @Any Instance<Foo>}}|Foo|(a)Any|CDI.current().select(Foo.class,Any.Literal.INSTANCE)| In this case, we would have to specify that there are no required qualifiers by default and {{@Default}} is added automatically during resolution if no qualifier selected. > SPI element related to Instance are missing info about their qualifier > ---------------------------------------------------------------------- > > Key: CDI-671 > URL: https://issues.jboss.org/browse/CDI-671 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 2.0.Beta1 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Following elements are related to {{Instance}} interface: > * {{CDI}} class implements {{Instance}} > * {{SeContainer}} extends {{Instance}} > * {{BeanManager.createInstance()}} returns and {{Instance}} object > If these {{Instance}} usage are all {{Instance<Object>}} there's no information regarding their qualifier. > We should state in Javadoc and spec that these Instance behaves like an injected instance with {{@Inject @Any Instance<Object>}} to allow access to all beans instance in the container. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-671) SPI element related to Instance are missing info about their qualifier

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-671?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-671: ------------------------------------- Fix Version/s: 2.0 .Final > SPI element related to Instance are missing info about their qualifier > ---------------------------------------------------------------------- > > Key: CDI-671 > URL: https://issues.jboss.org/browse/CDI-671 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 2.0.Beta1 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 .Final > > > Following elements are related to {{Instance}} interface: > * {{CDI}} class implements {{Instance}} > * {{SeContainer}} extends {{Instance}} > * {{BeanManager.createInstance()}} returns and {{Instance}} object > If these {{Instance}} usage are all {{Instance<Object>}} there's no information regarding their qualifier. > We should state in Javadoc and spec that these Instance behaves like an injected instance with {{@Inject @Any Instance<Object>}} to allow access to all beans instance in the container. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-671) SPI element related to Instance are missing info about their qualifier

by Antoine Sabot-Durand (JIRA)

Antoine Sabot-Durand created CDI-671: ---------------------------------------- Summary: SPI element related to Instance are missing info about their qualifier Key: CDI-671 URL: https://issues.jboss.org/browse/CDI-671 Project: CDI Specification Issues Issue Type: Clarification Components: Javadoc and API Affects Versions: 2.0.Beta1 Reporter: Antoine Sabot-Durand Following elements are related to {{Instance}} interface: * {{CDI}} class implements {{Instance}} * {{SeContainer}} extends {{Instance}} * {{BeanManager.createInstance()}} returns and {{Instance}} object If these {{Instance}} usage are all {{Instance<Object>}} there's no information regarding their qualifier. We should state in Javadoc and spec that these Instance behaves like an injected instance with {{@Inject @Any Instance<Object>}} to allow access to all beans instance in the container. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-670) Clarify InterceptionFactory.ignoreFinalMethods() purpose and functioning

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-670?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand reassigned CDI-670: ---------------------------------------- Assignee: Antoine Sabot-Durand > Clarify InterceptionFactory.ignoreFinalMethods() purpose and functioning > ------------------------------------------------------------------------ > > Key: CDI-670 > URL: https://issues.jboss.org/browse/CDI-670 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Priority: Critical > Fix For: 2.0 .Final > > > It should be clear that {{InterceptionFactory.ignoreFinalMethods()}} only affects the generation of the "proxy" which enables interception. E.g. the following example would FAIL during validation of {{myFoo}} injection point (bootstrap): > {code:java} > @Inject > Foo myFoo; > @Produces > @RequestScoped // -> Requires a client proxy > public Foo produce(InterceptionFactory<Foo> interceptionFactory) { > // Suppose Foo has a final method > return interceptionFactory.ignoreFinalMethods().createInterceptedInstance(new Foo()); > } > {code} > The reason is that the CDI container must treat the producer as a deployment problem (unless {{javax.enterprise.inject.spi.ProcessBeanAttributes.ignoreFinalMethods()}} is used for the producer method). > I understand that it's not very intuitive. On the other hand, these are two different concepts. I.e. the *injection point validation happens during bootstrap* while the {{InterceptionFactory}} *is used at runtime*. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-670) Clarify InterceptionFactory.ignoreFinalMethods() purpose and functioning

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-670?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-670: ----------------------------- Description: It should be clear that {{InterceptionFactory.ignoreFinalMethods()}} only affects the generation of the "proxy" which enables interception. E.g. the following example would FAIL during validation of {{myFoo}} injection point (bootstrap): {code:java} @Inject Foo myFoo; @Produces @RequestScoped // -> Requires a client proxy public Foo produce(InterceptionFactory<Foo> interceptionFactory) { // Suppose Foo has a final method return interceptionFactory.ignoreFinalMethods().createInterceptedInstance(new Foo()); } {code} The reason is that the CDI container must treat the producer as a deployment problem (unless {{javax.enterprise.inject.spi.ProcessBeanAttributes.ignoreFinalMethods()}} is used for the producer method). I understand that it's not very intuitive. On the other hand, these are two different concepts. I.e. the *injection point validation happens during bootstrap* while the {{InterceptionFactory}} *is used at runtime*. was: It should be clear that {{InterceptionFactory.ignoreFinalMethods()}} only affects the generation of the "proxy" which enables interception. E.g. the following example would FAIL during validation of {{myFoo}} injection point (bootstrap): {code:java} @Inject Foo myFoo; @Produces @RequestScoped // -> Requires a client proxy public Foo produce(InterceptionFactory<Foo> interceptionFactory) { // Suppose Foo has a final method return interceptionFactory.ignoreFinalMethods().createInterceptedInstance(new FinalProduct()); } {code} The reason is that the CDI container must treat the producer as a deployment problem (unless {{javax.enterprise.inject.spi.ProcessBeanAttributes.ignoreFinalMethods()}} is used for the producer method). I understand that it's not very intuitive. On the other hand, these are two different concepts. I.e. the *injection point validation happens during bootstrap* while the {{InterceptionFactory}} *is used at runtime*. > Clarify InterceptionFactory.ignoreFinalMethods() purpose and functioning > ------------------------------------------------------------------------ > > Key: CDI-670 > URL: https://issues.jboss.org/browse/CDI-670 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Priority: Critical > Fix For: 2.0 .Final > > > It should be clear that {{InterceptionFactory.ignoreFinalMethods()}} only affects the generation of the "proxy" which enables interception. E.g. the following example would FAIL during validation of {{myFoo}} injection point (bootstrap): > {code:java} > @Inject > Foo myFoo; > @Produces > @RequestScoped // -> Requires a client proxy > public Foo produce(InterceptionFactory<Foo> interceptionFactory) { > // Suppose Foo has a final method > return interceptionFactory.ignoreFinalMethods().createInterceptedInstance(new Foo()); > } > {code} > The reason is that the CDI container must treat the producer as a deployment problem (unless {{javax.enterprise.inject.spi.ProcessBeanAttributes.ignoreFinalMethods()}} is used for the producer method). > I understand that it's not very intuitive. On the other hand, these are two different concepts. I.e. the *injection point validation happens during bootstrap* while the {{InterceptionFactory}} *is used at runtime*. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-670) Clarify InterceptionFactory.ignoreFinalMethods() purpose and functioning

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-670?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-670: ----------------------------- Priority: Critical (was: Major) > Clarify InterceptionFactory.ignoreFinalMethods() purpose and functioning > ------------------------------------------------------------------------ > > Key: CDI-670 > URL: https://issues.jboss.org/browse/CDI-670 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Priority: Critical > Fix For: 2.0 .Final > > > It should be clear that {{InterceptionFactory.ignoreFinalMethods()}} only affects the generation of the "proxy" which enables interception. E.g. the following example would FAIL during validation of {{myFoo}} injection point (bootstrap): > {code:java} > @Inject > Foo myFoo; > @Produces > @RequestScoped // -> Requires a client proxy > public Foo produce(InterceptionFactory<Foo> interceptionFactory) { > // Suppose Foo has a final method > return interceptionFactory.ignoreFinalMethods().createInterceptedInstance(new FinalProduct()); > } > {code} > The reason is that the CDI container must treat the producer as a deployment problem (unless {{javax.enterprise.inject.spi.ProcessBeanAttributes.ignoreFinalMethods()}} is used for the producer method). > I understand that it's not very intuitive. On the other hand, these are two different concepts. I.e. the *injection point validation happens during bootstrap* while the {{InterceptionFactory}} *is used at runtime*. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-670) Clarify InterceptionFactory.ignoreFinalMethods() purpose and functioning

by Martin Kouba (JIRA)

Martin Kouba created CDI-670: -------------------------------- Summary: Clarify InterceptionFactory.ignoreFinalMethods() purpose and functioning Key: CDI-670 URL: https://issues.jboss.org/browse/CDI-670 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba Fix For: 2.0 .Final It should be clear that {{InterceptionFactory.ignoreFinalMethods()}} only affects the generation of the "proxy" which enables interception. E.g. the following example would FAIL during validation of {{myFoo}} injection point (bootstrap): {code:java} @Inject Foo myFoo; @Produces @RequestScoped // -> Requires a client proxy public Foo produce(InterceptionFactory<Foo> interceptionFactory) { // Suppose Foo has a final method return interceptionFactory.ignoreFinalMethods().createInterceptedInstance(new FinalProduct()); } {code} The reason is that the CDI container must treat the producer as a deployment problem (unless {{javax.enterprise.inject.spi.ProcessBeanAttributes.ignoreFinalMethods()}} is used for the producer method). I understand that it's not very intuitive. On the other hand, these are two different concepts. I.e. the *injection point validation happens during bootstrap* while the {{InterceptionFactory}} *is used at runtime*. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-669) Clarify statement wrt exception for Interceptionfactory.createInterceptedInstance

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/CDI-669?page=com.atlassian.jira.plugin.sy... ] Matej Novotny commented on CDI-669: ----------------------------------- Nice catch, we should clarify this. I'd say IllegalStateException is a way to go. > Clarify statement wrt exception for Interceptionfactory.createInterceptedInstance > --------------------------------------------------------------------------------- > > Key: CDI-669 > URL: https://issues.jboss.org/browse/CDI-669 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Tomas Remes > > {{11.7. Apply interceptor programmatically}} states for method createInterceptedInstance(): > | The method can be only called once, subsequent calls will throw an exception. > Which exception? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-669) Clarify statement wrt exception for Interceptionfactory.createInterceptedInstance

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-669?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-669: ---------------------------------- Javadoc states {{IllegalStateException}}. > Clarify statement wrt exception for Interceptionfactory.createInterceptedInstance > --------------------------------------------------------------------------------- > > Key: CDI-669 > URL: https://issues.jboss.org/browse/CDI-669 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Tomas Remes > > {{11.7. Apply interceptor programmatically}} states for method createInterceptedInstance(): > | The method can be only called once, subsequent calls will throw an exception. > Which exception? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-669) Clarify statement wrt exception for Interceptionfactory.createInterceptedInstance

by Tomas Remes (JIRA)

Tomas Remes created CDI-669: ------------------------------- Summary: Clarify statement wrt exception for Interceptionfactory.createInterceptedInstance Key: CDI-669 URL: https://issues.jboss.org/browse/CDI-669 Project: CDI Specification Issues Issue Type: Bug Reporter: Tomas Remes {{11.7. Apply interceptor programmatically}} states for method createInterceptedInstance(): | The method can be only called once, subsequent calls will throw an exception. Which exception? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev December 2016