September 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] Created: (CDI-124) Clarify how the ObserverMethod interface should be used

by Jozef Hartinger (JIRA)

Clarify how the ObserverMethod interface should be used ------------------------------------------------------- Key: CDI-124 URL: https://issues.jboss.org/browse/CDI-124 Project: CDI Specification Issues Issue Type: Clarification Components: Events Affects Versions: 1.0 Reporter: Jozef Hartinger Fix For: TBD The CDI specification (10.5) says: "For a custom implementation of the ObserverMethod interface defined in Section 11.1.3, "The ObserverMethod interface", the container must call getReception() and getTransactionPhase() to determine if the observer method is a conditional or transactional observer method, and notify() to invoke the method." However, calling ObserverMethod.getReception() is useless. An ObserverMethod implementation can be registered by an portable extension via the AfterBeanDiscovery event. The observer method may or may not be hosted by a CDI bean: a) A portable extension adds a different way of declaring an observer method on a CDI bean (e.g. using a different annotation like @Listens, or allowing a different method signature) b) A portable extension allows CDI observer methods to be registered on non-CDI beans (e.g. on a Spring Bean) In both cases, the container is not able find out if an instance of the hosting component has been created already - it does not know the hosting bean in (a) and it obviously does not know anything about the Spring bean (b). Therefore, if the observer method is conditional (ObserverMethod.getReception() returns IF_EXISTS), the container cannot decide whether it should invoke the observer method since it has no way of finding out whether the underlying instance exists or not. As a result, the container has to invoke ObserverMethod.notify() anyway. That's why I consider ObserverMethod.getReception() useless. To fix the problem, I think that the responsibility of deciding whether to invoke a conditional observer method should be shifted from container to the ObserverMethod implementation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (CDI-157) Enabling/Disabling Extensions

by Pete Muir (JIRA)

Enabling/Disabling Extensions ----------------------------- Key: CDI-157 URL: https://issues.jboss.org/browse/CDI-157 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Pete Muir Fix For: 1.1 (Proposed) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
9
0 / 0

[JBoss JIRA] Created: (CDI-170) Either ditch or fix @New

by Mark Struberg (JIRA)

Either ditch or fix @New ------------------------ Key: CDI-170 URL: https://issues.jboss.org/browse/CDI-170 Project: CDI Specification Issues Issue Type: Bug Components: Concepts, Contexts Affects Versions: 1.0 Reporter: Mark Struberg Fix For: TBD The specification of @New is currently not really usable. It is really only for creating injected but unmanaged and unintercepted instances of a class. But this usecase is weird and imo just not needed. If the class under construction is an 'old' Pojo (without @Inject, etc) then it doesn't need to get managed. And it also doesn't provide any benefit over just using new Pojo(); Also you cannot @New classes which don't have a default ct. I just found no sane scenario where we cannot use a producer method instead. Can we simply deprecate @New? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

8
19
0 / 0

[JBoss JIRA] Created: (CDI-110) Allow proxying of abstract classes (Service Handler)

by George Gastaldi (JIRA)

Allow proxying of abstract classes (Service Handler) ---------------------------------------------------- Key: CDI-110 URL: https://issues.jboss.org/browse/CDI-110 Project: CDI Specification Issues Issue Type: Feature Request Components: Inheritance and Specialization Affects Versions: 1.1 (Proposed) Reporter: George Gastaldi According to mojavelinux: {quote} <mojavelinux> service handler, interceptors and decorators are all complementary <mojavelinux> and cdi is missing the first...which we now realize {quote} CDI 1.1 should provide a way to inject abstract classes by specifying a ServiceHandler (Check http://docs.jboss.org/seam/3/solder/latest/reference/en-US/html/serviceha...) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

10
34
0 / 0

[JBoss JIRA] Created: (CDI-147) Are EJB's not deployed in a bean archive eligible for CDI injection

by Stuart Douglas (JIRA)

Are EJB's not deployed in a bean archive eligible for CDI injection ------------------------------------------------------------------- Key: CDI-147 URL: https://issues.jboss.org/browse/CDI-147 Project: CDI Specification Issues Issue Type: Clarification Reporter: Stuart Douglas If an EJB is deployed in an ejb-jar without a beans.xml, is this EJB eligible for CDI injection of beans deployed in other modules? The spec says: "The container performs dependency injection on all session and message-driven bean instances, even those which are not contextual instances." To me this sounds like the intent was to allow injection into EJB's looked up from JNDI, does this also mean that EJB's in non bean archives should also be injected? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (CDI-156) Clarify that EJB3-style interceptors are applicable to CDI managed beans

by Marius Bogoevici (JIRA)

Clarify that EJB3-style interceptors are applicable to CDI managed beans ------------------------------------------------------------------------ Key: CDI-156 URL: https://issues.jboss.org/browse/CDI-156 Project: CDI Specification Issues Issue Type: Clarification Reporter: Marius Bogoevici -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

4
10
0 / 0

[JBoss JIRA] Created: (CDI-154) How to treat Externalizable?

by Mark Struberg (JIRA)

How to treat Externalizable? ---------------------------- Key: CDI-154 URL: https://issues.jboss.org/browse/CDI-154 Project: CDI Specification Issues Issue Type: Clarification Reporter: Mark Struberg we currently only check for Serializable and completely ignore Externalizable in the spec. Should we fix this? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
6
0 / 0

[JBoss JIRA] Created: (CDI-150) A beans.xml file should explicitly define its beans.xml dependencies

by Geoffrey De Smet (JIRA)

A beans.xml file should explicitly define its beans.xml dependencies -------------------------------------------------------------------- Key: CDI-150 URL: https://issues.jboss.org/browse/CDI-150 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Geoffrey De Smet See the problem described in this comment on CDI-87: https://issues.jboss.org/browse/CDI-87?focusedCommentId=12626218 Solution proposal 1: Every beans.xml gets an id: {code} <beans id="org.jboss.seam.solder"> ... </beans> {code} Then it's possible to depend on other beans.xml files: {code} <beans id="org.jboss.seam.security"> <dependency refid="org.jboss.seam.solder"/> ... </beans> {code} So when guvnor depends on security, it can automatically, transitively inherit solder (without depending on it directly): {code} <beans id="org.drools.guvnor"> <dependency refid="org.jboss.seam.security"/> ... </beans> {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (CDI-169) Remove the 'No type variable in event objects' restriction

by Stuart Douglas (JIRA)

Remove the 'No type variable in event objects' restriction ---------------------------------------------------------- Key: CDI-169 URL: https://issues.jboss.org/browse/CDI-169 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Stuart Douglas CDI 10.1 states: An event object is an instance of a concrete Java class with no type variables. ... An event type may not contain a type variable. Which seems silly considering the container fires events with a type variable at startup. I can't think of any reason why this should be prohibited. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

8
15
0 / 0

[JBoss JIRA] Created: (CDI-103) Support client controlled contexts

by Pete Muir (JIRA)

Support client controlled contexts ---------------------------------- Key: CDI-103 URL: https://issues.jboss.org/browse/CDI-103 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Pete Muir In a client controlled context, the client controls via some identifier (probably an identifier, but we should allow the context to inspect the injection point) which contextual instances it sees for a particular bean type. For example given: {code} @MyScope class Foo { String name; } {code} and a context which uses annotations to differentiate between contextual instance, these two injection points would see different instances: {code} @Inject @Bar Foo barFoo; @Inject @Baz Foo bazFoo; {code} -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2011