March 2013 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-319) Reword part of the @Vetoed section

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-319?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-319: ----------------------------- Description: I think the current wording of 3.13 "Vetoing types" is misleading now. E.g. @Vetoed on annotation (qualifier, stereotype) has no effect. Also the spec wording should be synced with @Vetoed javadoc. To sum it up: @Vetoed affects classes, interfaces, enums. * class -> no container lifecycle event (PAT), no bean or observer methods defined by the class will be installed * interface, enum -> no container lifecycle event (PAT) I suggest something similar: {quote} Any Java class, interface, enum or package may be prevented from being considered by CDI by adding the @Vetoed annotation. In particular, * any beans or observer methods defined by a class annotated with @Vetoed will not be installed * no container lifecycle events are fired for classes, interfaces or enums annotated with @Vetoed * when @Vetoed placed on package, all classes, interfaces or enums in the package are prevented from being considered by CDI {quote} The rest is ok. was:We should probably change the "3.12 Vetoing types" section title back to "Vetoing beans" and sync the spec wording with *@Vetoed javadoc* (which makes it clear). > Reword part of the @Vetoed section > ---------------------------------- > > Key: CDI-319 > URL: https://issues.jboss.org/browse/CDI-319 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > > I think the current wording of 3.13 "Vetoing types" is misleading now. E.g. @Vetoed on annotation (qualifier, stereotype) has no effect. Also the spec wording should be synced with @Vetoed javadoc. > To sum it up: @Vetoed affects classes, interfaces, enums. > * class -> no container lifecycle event (PAT), no bean or observer methods defined by the class will be installed > * interface, enum -> no container lifecycle event (PAT) > I suggest something similar: > {quote} > Any Java class, interface, enum or package may be prevented from being considered by CDI by adding the @Vetoed annotation. > In particular, > * any beans or observer methods defined by a class annotated with @Vetoed will not be installed > * no container lifecycle events are fired for classes, interfaces or enums annotated with @Vetoed > * when @Vetoed placed on package, all classes, interfaces or enums in the package are prevented from being considered by CDI > {quote} > The rest is ok. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-319) Reword part of the @Vetoed section

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-319?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-319: ----------------------------- Fix Version/s: 1.1.FD > Reword part of the @Vetoed section > ---------------------------------- > > Key: CDI-319 > URL: https://issues.jboss.org/browse/CDI-319 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 1.1.FD > > > I think the current wording of 3.13 "Vetoing types" is misleading now. E.g. @Vetoed on annotation (qualifier, stereotype) has no effect. Also the spec wording should be synced with @Vetoed javadoc. > To sum it up: @Vetoed affects classes, interfaces, enums. > * class -> no container lifecycle event (PAT), no bean or observer methods defined by the class will be installed > * interface, enum -> no container lifecycle event (PAT) > I suggest something similar: > {quote} > Any Java class, interface, enum or package may be prevented from being considered by CDI by adding the @Vetoed annotation. > In particular, > * any beans or observer methods defined by a class annotated with @Vetoed will not be installed > * no container lifecycle events are fired for classes, interfaces or enums annotated with @Vetoed > * when @Vetoed placed on package, all classes, interfaces or enums in the package are prevented from being considered by CDI > {quote} > The rest is ok. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-319) Reword part of the @Vetoed section

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-319?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-319: ----------------------------- Assignee: Pete Muir > Reword part of the @Vetoed section > ---------------------------------- > > Key: CDI-319 > URL: https://issues.jboss.org/browse/CDI-319 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Assignee: Pete Muir > Fix For: 1.1.FD > > > I think the current wording of 3.13 "Vetoing types" is misleading now. E.g. @Vetoed on annotation (qualifier, stereotype) has no effect. Also the spec wording should be synced with @Vetoed javadoc. > To sum it up: @Vetoed affects classes, interfaces, enums. > * class -> no container lifecycle event (PAT), no bean or observer methods defined by the class will be installed > * interface, enum -> no container lifecycle event (PAT) > I suggest something similar: > {quote} > Any Java class, interface, enum or package may be prevented from being considered by CDI by adding the @Vetoed annotation. > In particular, > * any beans or observer methods defined by a class annotated with @Vetoed will not be installed > * no container lifecycle events are fired for classes, interfaces or enums annotated with @Vetoed > * when @Vetoed placed on package, all classes, interfaces or enums in the package are prevented from being considered by CDI > {quote} > The rest is ok. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-319) Reword part of the @Vetoed section

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-319?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-319: ----------------------------- Summary: Reword part of the @Vetoed section (was: @Vetoed placed on package should only affect beans) > Reword part of the @Vetoed section > ---------------------------------- > > Key: CDI-319 > URL: https://issues.jboss.org/browse/CDI-319 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > > We should probably change the "3.12 Vetoing types" section title back to "Vetoing beans" and sync the spec wording with *@Vetoed javadoc* (which makes it clear). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-319) @Vetoed placed on package should only affect beans

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-319?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-319: ----------------------------- Description: We should probably change the "3.12 Vetoing types" section title back to "Vetoing beans" and sync the spec wording with *@Vetoed javadoc* (which makes it clear). (was: We should probably change the "3.12 Vetoing types" section title back to "Vetoing beans" and sync the spec wording with @Vetoed javadoc (which makes it clear).) > @Vetoed placed on package should only affect beans > -------------------------------------------------- > > Key: CDI-319 > URL: https://issues.jboss.org/browse/CDI-319 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > > We should probably change the "3.12 Vetoing types" section title back to "Vetoing beans" and sync the spec wording with *@Vetoed javadoc* (which makes it clear). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-353) BM.createInjectionTarget() used in Unmanaged constructor

by Martin Kouba (JIRA)

Martin Kouba created CDI-353: -------------------------------- Summary: BM.createInjectionTarget() used in Unmanaged constructor Key: CDI-353 URL: https://issues.jboss.org/browse/CDI-353 Project: CDI Specification Issues Issue Type: Bug Reporter: Martin Kouba Assignee: Pete Muir Priority: Minor Fix For: 1.1.FD This method is deprecated now - {{BeanManager.getInjectionTargetFactory()}} should be used instead. There's likely no impact on the functionality for non-contextual instances but looks inconsistent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-352) Clarify whether an interceptor/decorator enabled for a bean archive must be packaged in a bean archive

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-352?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-352: ----------------------------------- Interceptors, Decorators, ProducerMethods, ProducerFields etc all only can get built up _after_ the bean discovery is done. The reason is that enabled/disabled beans can heavily influence the resolution. Doing this _during_ PAT would create stochastic behaviour which depends on the order in which the classes get scanned. Thus you cannot make the classes which need to get scanned depending on any of those mechanisms. For Interceptors it's specially bad as there is CDI-style (@InterceptorBinding) and EJB-style (@Interceptors). All compatibility bets are off once you leave a jar with a beans.xml in it... > Clarify whether an interceptor/decorator enabled for a bean archive must be packaged in a bean archive > ------------------------------------------------------------------------------------------------------ > > Key: CDI-352 > URL: https://issues.jboss.org/browse/CDI-352 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators, Interceptors > Affects Versions: 1.1.PFD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Priority: Blocker > Fix For: 1.1.FD > > > There is a TCK test in which an archive with the beans.xml file enables an interceptor (by listing the interceptor class name in beans.xml). The interceptor class is packaged in another library archive which is not a bean archive. It is not clear from the specification if an interceptor bound using interceptor bindings may only be packaged in a bean archive or whether a CDI implementation should pull the interceptor definition based on the declaration in the beans.xml file even if the interceptor is outside of a bean archive. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-352) Clarify whether an interceptor/decorator enabled for a bean archive must be packaged in a bean archive

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-352: ----------------------------------- Summary: Clarify whether an interceptor/decorator enabled for a bean archive must be packaged in a bean archive Key: CDI-352 URL: https://issues.jboss.org/browse/CDI-352 Project: CDI Specification Issues Issue Type: Clarification Components: Decorators, Interceptors Affects Versions: 1.1.PFD Reporter: Jozef Hartinger Assignee: Pete Muir Priority: Blocker Fix For: 1.1.FD There is a TCK test in which an archive with the beans.xml file enables an interceptor (by listing the interceptor class name in beans.xml). The interceptor class is packaged in another library archive which is not a bean archive. It is not clear from the specification if an interceptor bound using interceptor bindings may only be packaged in a bean archive or whether a CDI implementation should pull the interceptor definition based on the declaration in the beans.xml file even if the interceptor is outside of a bean archive. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-351) Implicit bean archive compatibility issue

by Jozef Hartinger (JIRA)

Jozef Hartinger created CDI-351: ----------------------------------- Summary: Implicit bean archive compatibility issue Key: CDI-351 URL: https://issues.jboss.org/browse/CDI-351 Project: CDI Specification Issues Issue Type: Bug Components: Portable Extensions Affects Versions: 1.1.PFD Reporter: Jozef Hartinger Assignee: Pete Muir Priority: Blocker Fix For: 1.1.FD Assume an existing extension library (CDI 1.0). This library is not deployed as a bean archive (it does not contain beans.xml). Instead, the library contains an extension which registers beans, interceptors, etc. using BeforeBeanDiscovery.addAnnotatedType(). With CDI 1.1 the no-bean-archive assumption no longer holds and since a scope annotation is used somewhere in the extension, this extension is now recognized as an implicit bean archive. That causes the discovered beans to clash with those added programatically. *Note that it is not possible to fix this by adding beans.xml with bean-discovery-mode set to "none". This would fix the problem in CDI 1.1 but the presence of beans.xml would break the extension in a CDI 1.0 container*. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-350) The container must discover each interface and enum with bean defining annotation in an implicit bean archive

by Martin Kouba (JIRA)

Martin Kouba created CDI-350: -------------------------------- Summary: The container must discover each interface and enum with bean defining annotation in an implicit bean archive Key: CDI-350 URL: https://issues.jboss.org/browse/CDI-350 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba Assignee: Pete Muir Fix For: 1.1.FD I wonder whether this makes sense. Currently a bean defining annotation is any scope type, which has an associated context. Interfaces and enums are not supposed to have it defined, are they? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev March 2013