August 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-224) Support Decoration of no interface beans

by Aslak Knutsen (JIRA)

Aslak Knutsen created CDI-224: --------------------------------- Summary: Support Decoration of no interface beans Key: CDI-224 URL: https://issues.jboss.org/browse/CDI-224 Project: CDI Specification Issues Issue Type: Feature Request Components: Decorators Affects Versions: 1.0 Reporter: Aslak Knutsen According to CDI 1.0 Spec: "Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean." "The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for java.io.Serializable. The decorator bean class and its superclasses are not decorated types of the decorator." Both CDI and EJB support No interface beans, but for some reason Decorators only work on methods from a Interface. While Interceptors on the other hand work fine with Classes. I can see no technical reason to why Decorators should only work on Interfaces since all Proxies etc should already be in place. {code} import javax.decorator.Decorator; import javax.decorator.Delegate; import javax.enterprise.inject.Any; import javax.inject.Inject; import junit.framework.Assert; import org.jboss.arquillian.container.test.api.Deployment; import org.jboss.arquillian.junit.Arquillian; import org.jboss.shrinkwrap.api.ShrinkWrap; import org.jboss.shrinkwrap.api.spec.WebArchive; import org.jboss.shrinkwrap.impl.BeansXml; import org.junit.Test; import org.junit.runner.RunWith; @RunWith(Arquillian.class) public class DecoratesClassTestCase { @Deployment public static WebArchive create() { return ShrinkWrap.create(WebArchive.class) .addAsWebInfResource( new BeansXml().decorators(BusinessDecorator.class), "beans.xml"); } @Test public void shouldBeAbleToDecorate(BusinessObject business) throws Exception { Assert.assertEquals("Decorated Test", business.send("Test")); } @Decorator public static abstract class BusinessDecorator extends BusinessObject { @Inject @Delegate @Any private BusinessObject delegate; public String send(String msg) { return "Decorated " + delegate.send(msg); } } public static class BusinessObject { public String send(String msg) { return msg; } } } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa 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] (CDI-221) Throw definition error if the set of decorated types of a decorator is empty

by Marko Lukša (JIRA)

Marko Lukša created CDI-221: ------------------------------- Summary: Throw definition error if the set of decorated types of a decorator is empty Key: CDI-221 URL: https://issues.jboss.org/browse/CDI-221 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Marko Lukša I propose the following addition to section 8.1: "If the set of decorated types of a decorator is empty, the container automatically detects the problem and treats it as a definition error." This would be helpful in cases where the developer is not aware that a decorator and decorated bean must share the same interface, and thinks that a decorator can be defined simply by extending the decorated class (as in the following example). {code} public class MyBean { public Object foo() {...} } @Decorator public class MyDecorator extends MyBean { @Inject @Delegate MyBean delegate; public Object foo() {...} } {code} Even though the spec does explicitly state that "superclasses are not decorated types of the decorator", throwing an error would probably save some people's debugging time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
4
0 / 0

[JBoss JIRA] (CDI-207) Specify @Destroyed event payload type for a timed-out conversation

by Jozef Hartinger (Created) (JIRA)

Specify @Destroyed event payload type for a timed-out conversation ------------------------------------------------------------------ Key: CDI-207 URL: https://issues.jboss.org/browse/CDI-207 Project: CDI Specification Issues Issue Type: Clarification Components: Contexts Affects Versions: 1.1.EDR1 Reporter: Jozef Hartinger Fix For: 1.1 (Proposed) {quote}An event with the ServletRequestEvent as the payload and with qualifier @Initialized(ConversationContext.class) is fired when the conversation context is initialized and an event with qualifier @Destroyed(ConversationContext.class) when the conversation context is destroyed.{quote} ServletRequestEvent is not available when a conversation is destroyed due to time-out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
7
0 / 0

[JBoss JIRA] (CDI-219) Support Request Scope for EJB @Singleton @PostConstruct methods

by Guido Bonazza (JIRA)

Guido Bonazza created CDI-219: --------------------------------- Summary: Support Request Scope for EJB @Singleton @PostConstruct methods Key: CDI-219 URL: https://issues.jboss.org/browse/CDI-219 Project: CDI Specification Issues Issue Type: Feature Request Components: Contexts, Java EE integration Affects Versions: 1.0 Reporter: Guido Bonazza A Request context should be available in @PostConstruct methods of EJB Singletons. This is a completion of section 6.7.1 of the CDI 1.0 spec, which covers @Asynchronous and @Timeout EJB methods. Probably the container should ensure that a new context is always created for the @PostConstruct invocation, to be coherent with section 4.8.3 of the EJB 3.1 spec, which specifies the transactional behavior of @Singleton @PostConstruct. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

5
21
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] (CDI-236) Injection point of type Instance/Event must have a type parameter

by Martin Kouba (JIRA)

Martin Kouba created CDI-236: -------------------------------- Summary: Injection point of type Instance/Event must have a type parameter Key: CDI-236 URL: https://issues.jboss.org/browse/CDI-236 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba Priority: Minor IMHO this is not implied. One could think *{{@Inject Instance instance}}* is equivalent to *{{@Inject Instance<Object> instance}}*. Note that RI (Weld) does not allow this at the moment and treats *{{@Inject Instance instance}}* or *{{@Inject Event event}}* as a definition error. In any case the spec should clarify this so that we could write valid TCK tests for this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

2
6
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, 4 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, 4 months

4
10
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev August 2012