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: ------------------------------- Merged > 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, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-139) Support for unmanaged instances

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-139?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-139. --------------------------- Resolution: Done Merged > Support for unmanaged instances > ------------------------------- > > Key: CDI-139 > URL: https://issues.jboss.org/browse/CDI-139 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Joshua Davis > Assignee: Pete Muir > Fix For: 1.1.PFD > > > Allow the creation of unmanaged instances. The CDI context will not keep track of these instances and the application will be responsible for cleaning them up. This is a fairly typical usage of other DI frameworks such as Guice and PicoContainer. > Currently, if an ApplicationScoped object injects an {{Instance<T>}} interface, CDI will manage all instances returned by the {{get()}} method as dependents of the application scoped object. Those instances will be kept in memory by the CDI implementation and will only be GC'd when the application scoped object is destroyed (at the end of the application). This may look like a memory leak to the user (see WELD-920). > From P. Muir on WELD-920 > {quote} > We can describe instances which are attached (as the CDI 1.0 spec requires) as "managed" instances, and those which the user takes responsibility for cleaning up themselves as "unmanaged" instances. In CDI 1.1 I would like to add support for unmanaged instances (the impl will just hand these over and forget about them) and also to allow the app to request an unmanaged instance is cleaned up. Please can someone file a CDI issue for this? > Weld could certainly be more friendly and more proactively discard instances. Ideas: > 1) Analyse the dependent instance graph, and if there are no @PreDestroy/@Disposer callbacks on in the graph, do not store the dependent instance for cleanup (this would be a good general optimization > (2) Add a config option to allow instances created from Instance to be held only as long as the app holds a reference, and if the app doesn't hold a reference for it's lifetime, then Weld would not do any cleanup (Weld would hold a weak ref). > {quote} -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-227) BeanManager#resolve() is underspecified for corner cases

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-227?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-227. --------------------------- Resolution: Done Merged > BeanManager#resolve() is underspecified for corner cases > -------------------------------------------------------- > > Key: CDI-227 > URL: https://issues.jboss.org/browse/CDI-227 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java SE Integration, Packaging and Deployment > Affects Versions: 1.0, 1.1.EDR > Reporter: Guy Veraghtert > Assignee: Pete Muir > Labels: patch > Fix For: 1.1.PFD > > > The CDI api's are mainly used to develop (portable) extensions. In practice, we see that those so called _portable_ extensions are not portable at all due to underspecified api's. > For example BeanManager.resolve(set) doesn't specify how to deal with an empty set or null. This leads to incompatible implementations and unportable extensions. See for example https://issues.apache.org/jira/browse/OWB-625 (Unfortunately Websphere 8 includes openwebbeans < 1.1.3, making Seam3 not out-of-the-box usable). Currently most implementations (weld, owb and candi) return null for an empty set. OWB returns null when null is passed, others will throw an exception. > To create extensions that are truly portable, we should specify all corner cases (what about BeanManager.getBean((String)null)?). In theory developers should not depend on undefined behavior, but in practice we all do (Seam3 is full of examples). > Ideally, we should go over the complete public API and specify what should happen with these corner cases: null-values, empty collections, ... > Just adding that an IllegalArgumentException should be thrown in case of null for example would suffice. > These things are very easy to incorporate in the TCK and would contribute a lot to the success of portable extensions -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-305) Reflect the new EJB passivation-capable flag in CDI

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-305?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-305. --------------------------- Resolution: Done Merged > Reflect the new EJB passivation-capable flag in CDI > --------------------------------------------------- > > Key: CDI-305 > URL: https://issues.jboss.org/browse/CDI-305 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Affects Versions: 1.1.PRD > Reporter: Pete Muir > Fix For: 1.1.PFD > > > EJB 3.2 adds the ability to disable passivation of SFSB by either using @Stateful(passivationCapable=false) or setting it in the DD. > We should update the CDI spec to cover this. -- 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, 2 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 resolved CDI-315. --------------------------- Assignee: Pete Muir Resolution: Done Merged > 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 > Assignee: Pete Muir > 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, 2 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 resolved CDI-294. --------------------------- Resolution: Done Merged > 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, 2 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 resolved CDI-78. -------------------------- Resolution: Done Merged > 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, 2 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: ------------------------------ Merged > 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, 2 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 resolved CDI-52. -------------------------- Resolution: Done > 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, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-271) Provide a way to inject Event metadata into an observer method

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-271?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-271: ------------------------------- Please review https://github.com/jboss/cdi/pull/176 which I think covers all cases :-D > Provide a way to inject Event metadata into an observer method > -------------------------------------------------------------- > > Key: CDI-271 > URL: https://issues.jboss.org/browse/CDI-271 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Reporter: Arne Limburg > Assignee: Arne Limburg > Fix For: 1.1.PFD > > > Currently there is no way for observer methods to access the qualifiers of the fired event (i.e. to access @Nonbinding members). > Consider the following example: > {code} > @Inject @MyQualifier > Event<MyObject> event; > public void fireEvent(MyObject object, MyTypeValue type) { > event.select(new MyTypeAnnotationLiteral(type)).fire(object); > } > {code} > Currently no observer can receive the value of MyTypeValue. I suggest to introduce an interface AnnotatedEvent that extends Annotated and contains this information. It then could be injected via the InjectionPoint like this: > {code} > public void observeEvent(@Observes @MyType MyObject object, InjectionPoint ip) { > MyType annotation = ip.getAnnotated().getAnnotation(MyType.class); > MyTypeValue value = annotation.value(); > ... > } > {code} -- 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, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev February 2013