March 2013 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-356) Constructor-level interceptor bindings not considered

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-356?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-356. --------------------------- Resolution: Done This was fixed in the latest draft of the interceptors spec. > Constructor-level interceptor bindings not considered > ----------------------------------------------------- > > Key: CDI-356 > URL: https://issues.jboss.org/browse/CDI-356 > Project: CDI Specification Issues > Issue Type: Tracker > Components: Interceptors > Affects Versions: 1.1.PFD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Priority: Blocker > Fix For: 1.1.FD > > > For example: > {quote} > If an interceptor for lifecycle callbacks declares an interceptor binding type that not defined @Target(TYPE), the container > automatically detects the problem and treats it as a definition error. > {quote} > An interceptor that declares an @AroundConstruct interceptor method is an interceptor for a lifecycle callback yet it makes sense to define the binding as @Target(CONSTRUCTOR). -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-356) Constructor-level interceptor bindings not considered

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-356?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-356: -------------------------- Issue Type: Tracker (was: Bug) > Constructor-level interceptor bindings not considered > ----------------------------------------------------- > > Key: CDI-356 > URL: https://issues.jboss.org/browse/CDI-356 > Project: CDI Specification Issues > Issue Type: Tracker > Components: Interceptors > Affects Versions: 1.1.PFD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Priority: Blocker > Fix For: 1.1.FD > > > For example: > {quote} > If an interceptor for lifecycle callbacks declares an interceptor binding type that not defined @Target(TYPE), the container > automatically detects the problem and treats it as a definition error. > {quote} > An interceptor that declares an @AroundConstruct interceptor method is an interceptor for a lifecycle callback yet it makes sense to define the binding as @Target(CONSTRUCTOR). -- 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, 1 month

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)

[ https://issues.jboss.org/browse/CDI-352?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-352: ------------------------------------- no, InterceptorClassNotInBeanArchiveTest does not reference any assertions > 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, 1 month

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 Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-352?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-352: ------------------------------- [~jharting] do you know which section the tck test is based on? > 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, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-348) Clarify which beans "have" bean defining annotations

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-348?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-348: ------------------------------- The same rules apply as before about what scope a bean has. This is just about whether a class with a scope on a stereotype has a bean defining annotation, or not (it doesn't). > Clarify which beans "have" bean defining annotations > ---------------------------------------------------- > > Key: CDI-348 > URL: https://issues.jboss.org/browse/CDI-348 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Affects Versions: 1.1.PFD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Priority: Blocker > Fix For: 1.1.FD > > > {quote}Any bean which has scope type is said to have a bean defining annotation.{quote} > The spec makes this vague statement and provides two examples which only cover the two simplest cases. What remains unclear is: > - if a bean class inherits a scope annotation definition from a superclass, should it be discovered in an implicit bean archive? > - if a bean inherits a scope from a stereotype, should it be discovered in an implicit bean archive? > - if a producer method / field has a scope annotation but the declaring bean is not a bean with bean defining annotation, whould the producer be discovered? -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-348) Clarify which beans "have" bean defining annotations

by Joseph Snyder (JIRA)

[ https://issues.jboss.org/browse/CDI-348?page=com.atlassian.jira.plugin.sy... ] Joseph Snyder commented on CDI-348: ----------------------------------- Please clarify "inherits a scope from a stereotype". Does this mean that if there's a scope defined as part of the stereotype that it is not applied to the bean that is annotated with the stereotype? > Clarify which beans "have" bean defining annotations > ---------------------------------------------------- > > Key: CDI-348 > URL: https://issues.jboss.org/browse/CDI-348 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Affects Versions: 1.1.PFD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Priority: Blocker > Fix For: 1.1.FD > > > {quote}Any bean which has scope type is said to have a bean defining annotation.{quote} > The spec makes this vague statement and provides two examples which only cover the two simplest cases. What remains unclear is: > - if a bean class inherits a scope annotation definition from a superclass, should it be discovered in an implicit bean archive? > - if a bean inherits a scope from a stereotype, should it be discovered in an implicit bean archive? > - if a producer method / field has a scope annotation but the declaring bean is not a bean with bean defining annotation, whould the producer be discovered? -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-344) bean-discovery-mode should be specified

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-344?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-344. --------------------------- Resolution: Done Please review the latest changeset, available from the Commits tab. > bean-discovery-mode should be specified > --------------------------------------- > > Key: CDI-344 > URL: https://issues.jboss.org/browse/CDI-344 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.PFD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Fix For: 1.1.FD > > > It seems that the only complete source of information about the *bean-discovery-mode* attribute is the schema file. The specification should better explain the attribute, list and explain allowed values. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-344) bean-discovery-mode should be specified

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-344?page=com.atlassian.jira.plugin.sy... ] Pete Muir reopened CDI-344: --------------------------- > bean-discovery-mode should be specified > --------------------------------------- > > Key: CDI-344 > URL: https://issues.jboss.org/browse/CDI-344 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.PFD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Fix For: 1.1.FD > > > It seems that the only complete source of information about the *bean-discovery-mode* attribute is the schema file. The specification should better explain the attribute, list and explain allowed values. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-344) bean-discovery-mode should be specified

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-344?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-344: ---------------------------------- First, I think the wording is misleading because bean archives have no version. Only beans.xml files may have a version. {quote} A bean archive with no version has a default bean discovery mode of all. {quote} OK - CDI 1.0 beans.xml with bean-discovery-mode of any value should always result in bean discovery mode of all. But the sentence: {quote} A bean archive with version 1.1 (or later) has a default bean discovery mode of annotated. {quote} does not make sense in the context of the sentence written below: {quote} If beans.xml file with version 1.1 is used, the bean-discovery-mode attribute is required. {quote} (default value is always overwritten by user) What if we say: *explicit archives have always bean discovery mode of all* and *implicit archives have always bean discovery mode of annotated*? > bean-discovery-mode should be specified > --------------------------------------- > > Key: CDI-344 > URL: https://issues.jboss.org/browse/CDI-344 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.PFD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Fix For: 1.1.FD > > > It seems that the only complete source of information about the *bean-discovery-mode* attribute is the schema file. The specification should better explain the attribute, list and explain allowed values. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-346) Unclear relation between bean discovery and @WithAnnotations

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-346?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-346. --------------------------- Resolution: Done Yeah, I think this was a step too far, I've backed out this bit of the feature :-) > Unclear relation between bean discovery and @WithAnnotations > ------------------------------------------------------------ > > Key: CDI-346 > URL: https://issues.jboss.org/browse/CDI-346 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.PFD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Fix For: 1.1.FD > > > {quote} > First the container must discover types. The container discovers: > • each Java class, interface or enum deployed in an explicit bean archive, and > • each Java class interface, or enum with a bean defining annotation in an implicit bean archive. > • each session bean > that is not excluded from discovery. > Then, container must create an AnnotatedType representing the type and fire an event of type ProcessAnnotatedType, > as defined in Section 11.5.6, for: > • every type discovered > • each Java class, interface or enum that must be delivered to a ProcessAnnotatedType observer, where the event parameter > is annotated with @WithAnnotations. > {quote} > Having a class > a) in an implicit bean archive > b) outside of bean archive > that does not define a bean defining annotation and the class must be delivered to a @WithAnnotation PAT observer method. > Should this class result in a bean definition (assuming it fulfils bean requirements)? > Would not it be easier to add the category of classes that must be delivered to @WithAnnotations PAT observer to the implicit bean archive definition? -- 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, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev March 2013