February 2013 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-200) ProcessBeanAttributes needs clarification

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-200?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-200: ------------------------------- Please review https://github.com/jboss/cdi/pull/170 > ProcessBeanAttributes needs clarification > ----------------------------------------- > > Key: CDI-200 > URL: https://issues.jboss.org/browse/CDI-200 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.1.EDR > Reporter: Jozef Hartinger > Assignee: Pete Muir > Labels: visibility > Fix For: 1.1.PFD > > > The specification should clarify the following cases: > (1) whether the ProcessBeanAttributes event should be fired for Beans registered using AfterBeanDiscovery.addBean() - if yes, it is necessary to clarify what would the value returned by PBA.getAnnotated() be. > (2) whether the ProcessBeanAttributes event should be fired for built-in beans (my interpretation is that this is not required) > (3) The attributes represented by a BeanAttributes object are not completely independent. It is necessary to clarify how the set BeanAttributes object is treated. I can see two options: > (a) the container takes the final values of a BeanAttributes object and uses them > (b) the container itself updates certain attributes to match CDI rules for example > ** if an extension adds a @Named qualifier to the set of qualifiers, this change is automatically reflected within the name attribute > ** if an extension adds a stereotype, which is (transitively) annotated with @Named, the default name is implied and reflected within the name attribute > ** if an extension adds a stereotype, which is (transitively) annotated with @Alternative, this fact is reflected within the isAlternative attribute > ** if an extension adds a stereotype, which is (transitively) annotated with a scope annotation, this fact is reflected within the scope attribute > In theory, conflicts may occur where for example an extension may set different values for the @Named qualifier and for the name attribute. With the latter approach, an extension loses part of the control. On the other hand, this approach may be more convenient. > Another area that needs clarification is specialization. Suppose having beans A and B where B specializes A. According to the specification, the result of specialization should be visible at the time the ProcessBeanAttributes event is fired for B (the qualifiers and name of B are updated with values of A). The scenarios that need clarification are: > (4) In the ProcessBeanAttributes phase, a qualifier is added to A (making B no longer a valid substite of A). Should the container detect this as a definition error or rather apply specialization (update the set of qualifiers of B) once again? The same applies for name. > (5) Similarly, the set of qualifiers of B may be reduced by an extension, causing the same problem. -- 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-294) Clarify that a Java EE component definition never results in a managed bean being created

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-294?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-294: ------------------------------- https://github.com/jboss/cdi/pull/169 - Please review this, it shouldn't change the way CDI works at all! > Clarify that a Java EE component definition never results in a managed bean being created > ----------------------------------------------------------------------------------------- > > Key: CDI-294 > URL: https://issues.jboss.org/browse/CDI-294 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Java EE integration > Affects Versions: 1.0 > Reporter: Jozef Hartinger > Assignee: Pete Muir > Fix For: 1.1.PFD > > > Having e.g. a Servlet that matches managed bean requirements, there is nothing in the spec saying that the container should not take the servlet class and make a managed bean out of it. This results in ProcessInjectionTarget being fired twice. Furthermore, it does not actually make any sense to have Java EE component definitions (e.g. Servlets) to act as managed beans. -- 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-291) Clarify interceptor/decorator resolution rules

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-291?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-291: -------------------------- Fix Version/s: TBD (was: 1.1.PFD) Defer accessibility issues. > Clarify interceptor/decorator resolution rules > ---------------------------------------------- > > Key: CDI-291 > URL: https://issues.jboss.org/browse/CDI-291 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators, Interceptors > Affects Versions: 1.0 > Reporter: Jozef Hartinger > Assignee: Pete Muir > Fix For: TBD > > > Currently the spec only says: > {quote} > A decorator is bound to a bean if: > * The bean is assignable to the delegate injection point according to the rules defined in Section 5.2, "Typesafe resolu- > tion" (using Section 8.3.1, "Assignability of raw and parameterized types for delegate injection points"). > * The decorator is enabled in the bean archive containing the bean. > {quote} > AND > {quote} > An interceptor is bound to a method if: > * The method has all the interceptor bindings of the interceptor. A method has an interceptor binding of an interceptor if > it has an interceptor binding with (a) the same type and (b) the same annotation member value for each member which > is not annotated @javax.enterprise.util.Nonbinding. > * The interceptor intercepts the given kind of lifecycle callback or business method. > * The interceptor is enabled in the bean archive containing the bean. > {quote} > What remains unspecified is: > * In a scenario where a module A enables interceptor X in its beans.xml, does X have to be accessible from A. That effectively means that an EJB jar could (or could not) legally use an interceptor/decorator packaged in a web application. > * Even if X is accessible, does it have to be packaged in a bean archive or is it enough for it to be packaged in a library that does not contain beans.xml but is accessible from A? This means that a CDI implementation would need to additionally scan those classes as they would not be scanned by normal bean archive discovery. -- 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-315) Allow BeanManager methods, such as getBeans in AfterDeploymentValidation observers

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-315?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-315: ------------------------------- Pull at https://github.com/jboss/cdi/pull/168 > Allow BeanManager methods, such as getBeans in AfterDeploymentValidation observers > ---------------------------------------------------------------------------------- > > Key: CDI-315 > URL: https://issues.jboss.org/browse/CDI-315 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Marek Schmidt > Fix For: 1.1.PFD > > > CDI-274 which disallows some BeanManager methods during application initialization is too strict. > Mark's original suggestion for CDI-274 contained a very important part "...before the AfterDeploymentValidation phase". AfterDeploymentValidation observers would be quite useless if we can't use BeanManager.getBeans in them IMHO, and I think there is no reason to disallow BeanManager methods in AfterDeploymentValidation, so we should allow them there... > So maybe something like: > "IllegalStateException if called during application initialization before the AfterDeploymentValidation phase" -- 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-52) Make it clearer that an InjectionPoint injected into a disposer method refers to the producer method bean and not to the declaring bean

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-52?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-52: ------------------------------ https://github.com/jboss/cdi/pull/167 > Make it clearer that an InjectionPoint injected into a disposer method refers to the producer method bean and not to the declaring bean > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-52 > URL: https://issues.jboss.org/browse/CDI-52 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Critical > Fix For: 1.1.PFD > > -- 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-78) Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-78?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-78: ------------------------------ I will back out this change, it's wrong. https://github.com/jboss/cdi/pull/167 > Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator > ------------------------------------------------------------------------------------------------------------------------ > > Key: CDI-78 > URL: https://issues.jboss.org/browse/CDI-78 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.PFD > > > The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false. -- 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-238) Clarify enablement of a specialized bean

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-238?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger closed CDI-238. ------------------------------- Assignee: Jozef Hartinger Fix Version/s: (was: 1.1.PFD) Resolution: Cannot Reproduce Bug This is actually clear in the spec. > Clarify enablement of a specialized bean > ---------------------------------------- > > Key: CDI-238 > URL: https://issues.jboss.org/browse/CDI-238 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 1.1.EDR > Reporter: Jozef Hartinger > Assignee: Jozef Hartinger > > Assume the following class > {code:JAVA} > public class X > {code} > and deployment structure: > {code} > +-application.ear > +-web1.war > +-web2.war > +-lib/ > +-shared.jar > +-X.class > {code} > In addition, we assume the standard accessibility layout, where web archives are isolated and both web archives have access to the shared library archive. Note that the beans.xml file, which is present in web1.war, web2.war and shared.jar is omitted in deployment structure diagrams. > The X bean is available for injection in both web1 and web2 applications. > Furthermore, let's assume that web1 introduces the following bean for its own purpose: > {code:JAVA} > @Specializes > public class Y extends X > {code} > {code} > +-application.ear > +-web1.war > +-WEB-INF/ > +-classes/ > +-Y.class > +-web2.war > +-lib/ > +-shared.jar > +-X.class > {code} > Now assume the following injection point: > {code:JAVA} > @Inject > X bean; > {code} > If the injection point belongs to a bean bundled within web1.war, it should be injected with an instance of Y. > If the injection point belongs to a bean bundled within shared.jar, it should be injected with an instance of X (and not Y). > If the injection point belongs to a bean bundled within web2.war, it should intuitively be injected with X (because Y is not accessible). However, the specification says that: > {quote} > A bean is said to be enabled if it is not specialized by any other enabled bean, as defined in Section 4.3, “Specialization”... > {quote} > which X in this case is. As a result, the X bean is not enabled and the injection point would be unsatisfied if deployed within web2.war. This seems to be very counterintuitive. The fact whether a given bean can/cannot be injected due to specialization should be decided per module and not on the global enabled/disabled level. > The proposed fix is to make a bean available for injection in a given module > - if the bean is not specialized by another enabled bean or > - the bean is specialized by another enabled bean and the specializing bean is not available for injection in the given module. > It should also be clarified if container lifecycle events that are only fired for enabled beans (such ProcessBean and ProcessBeanAttributes) should or should not be fired for beans which are specialized in a certain module but are not in another module. -- 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-306) Clarify that MDBs don't need to support injected constructors

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-306?page=com.atlassian.jira.plugin.sy... ] Pete Muir closed CDI-306. ------------------------- Assignee: Pete Muir Resolution: Rejected MDBs do support injected constructors in Java EE 7. > Clarify that MDBs don't need to support injected constructors > ------------------------------------------------------------- > > Key: CDI-306 > URL: https://issues.jboss.org/browse/CDI-306 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java EE integration > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.PFD > > -- 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-239) Define Extension notification rules for shared libraries

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-239?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-239: -------------------------- Fix Version/s: TBD (was: 1.1.PFD) Deferring visibility issues. > Define Extension notification rules for shared libraries > -------------------------------------------------------- > > Key: CDI-239 > URL: https://issues.jboss.org/browse/CDI-239 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.1.EDR > Reporter: Mark Struberg > Fix For: TBD > > > Consider an EAR file with a shared xy.JAR file in the EARs ./lib folder with an > @EnterpriseApplicationScoped class X > and a > @RequestScoped class Y > The EAR also contains 2 web applications WebAppA and WebAppB. > WebAppA has ExtensionA in it's WEB-INF/classes and WebAppB has ExtensionB in it's classes both with a public void met(@Observes ProcessAnnotatedType pat) and each modifying the AnnotatedType. > What should happen here? Will there be 2 Bean<T> for X and 2 for Y? (one Bean for each WebApp)? or will X and Y not trigger a ProcessAnnotatedType for the extensions defined in the webapps (but only for Extensions defined in the shared ear lib)? -- 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-84) Non EE modules should be able to inject/lookup in JNDI a BeanManager

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-84?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-84: ------------------------- Fix Version/s: TBD (was: 1.1.PFD) Deferring > Non EE modules should be able to inject/lookup in JNDI a BeanManager > -------------------------------------------------------------------- > > Key: CDI-84 > URL: https://issues.jboss.org/browse/CDI-84 > Project: CDI Specification Issues > Issue Type: Tracker > Components: Java EE integration, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Aslak Knutsen > Labels: visibility > Fix For: TBD > > > EE.5.19 > A bean manager is only available in modules in which CDI has been enabled. > Where EE modules are defined to be; ejb-jar, rar, client jar and war. > This is a missmatch between the EE spec and the CDI spec. According to the CDI spec, any archive with a beans.xml is defined as a BeanArchive and should be included in a BeanManager, EE define it to be only EE modules should trigger BeanManager creation. > Opening this up to follow the CDI spec will let any library use the BeanManager to introspect other BeanArchives without having to involve the owning EE module in the loop. -- 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 February 2013