February 2011 - cdi-dev - Jboss List Archives

[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

[JBoss JIRA] Created: (CDI-109) Invalid beans should not be injectable into extensions

by John Ament (JIRA)

Invalid beans should not be injectable into extensions ------------------------------------------------------ Key: CDI-109 URL: https://issues.jboss.org/browse/CDI-109 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament Currently, you can inject beans that may not be ready yet into the extension's call back methods. As an example, I can inject something application scoped like this in to an extension, but it should really be throwing a definition exception (or similar): public void handleABD(@Observes AfterBeanDiscovery abd, MyApplicationScopedBean masb) { } Pete had noted that really the only safe thing to inject, other than the observed call back, is the bean manager. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

10
18
0 / 0

[JBoss JIRA] Created: (CDI-108) Align with release of @Inject included in the Java EE 7 platform

by Pete Muir (JIRA)

Align with release of @Inject included in the Java EE 7 platform ---------------------------------------------------------------- Key: CDI-108 URL: https://issues.jboss.org/browse/CDI-108 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Pete Muir There is likely to be an update to JSR-330, @Inject, which we should align with. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
7
0 / 0

[JBoss JIRA] Created: (CDI-107) Provide automatic startup capabilities for beans.

by John Ament (JIRA)

Provide automatic startup capabilities for beans. ------------------------------------------------- Key: CDI-107 URL: https://issues.jboss.org/browse/CDI-107 Project: CDI Specification Issues Issue Type: Feature Request Reporter: John Ament Certain beans (such as @ApplicationScoped or @Singleton) should be able to be instantiated on startup of the application automatically, similar to EJB3.1's @Startup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (CDI-106) Support JMS mappings

by Pete Muir (JIRA)

Support JMS mappings -------------------- Key: CDI-106 URL: https://issues.jboss.org/browse/CDI-106 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Pete Muir -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

5
11
0 / 0

[JBoss JIRA] Created: (CDI-105) Provide a means for portable extensions to access beans.xml files

by Stuart Douglas (JIRA)

Provide a means for portable extensions to access beans.xml files ----------------------------------------------------------------- Key: CDI-105 URL: https://issues.jboss.org/browse/CDI-105 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Stuart Douglas There is currently no portable way for extensions to get access to beans.xml files installed in WEB-INF/lib, as CDI starts up before the ServletContext is availible. This would be useful for extensions that wish to add extra information to beans.xml in a different namespace. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

4
16
0 / 0

[JBoss JIRA] Created: (CDI-104) Support automatic dependency injection for non-managed objects

by Dan Allen (JIRA)

Support automatic dependency injection for non-managed objects -------------------------------------------------------------- Key: CDI-104 URL: https://issues.jboss.org/browse/CDI-104 Project: CDI Specification Issues Issue Type: Feature Request Components: Beans Affects Versions: 1.0 Reporter: Dan Allen Allow objects created using the "new" keyword (or created by some other means) to be injected automatically. Conceptually it would look something like this: @AutoInject public class AccountService { private final Account account; @Inject private PaymentProcessor paymentProcessor; AccountService(Account account) { this.account = account; } public void doPayment(double amount) { paymentProcessor.processPayment(account, amount); } } We could then create the object using new and the fields will still be injected: AccountService a = new AccountService(account); a.doPayment(10); The inverse design would also be an option. An instance of Account could be retrieved from JPA and the AccountService would be injected into it during construction. To implement this feature may require a javaagent, which will modify the bytecode of @AutoInject annotated classes as they are loaded, so that the constructor bytecode looks up the values to inject and sets the injected field values appropriately. (There are other options suggested in the linked thread). The primary use case for this feature is to support rich domain models, though the usefulness of this feature extends beyond this case, so I don't think the feature should be dismissed if you don't agree with the rich domain models design. The feature also brings the "new" keyword back into the picture of modern programming. You can still create objects in the classic way, but benefit from modern programming model patterns (specifically CDI). Spring has a similar feature in it's AOP package: http://static.springsource.org/spring/docs/3.0.x/spring-framework-referen... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
1
0 / 0

CDI 1.1 JSR draft

by Pete Muir

All, I've attached the CDI 1.1 JSR proposal from Red Hat. I appreciate any comments, questions or suggestions for amendment you may have. Please send feedback to me or to cdi-dev(a)lists.jboss.org. Please let me know if you would like to support the JSR, and if you would like to be on the EG, or can recommend someone who should. I don't have access to the 299 EG list, but if someone else does and can forward to it, that would be much appreciated. Jason or Roberto, could you send this to the jsr-316 list for review, would be much appreciated. Regards, Pete

13 years, 10 months

3
2
0 / 0

[JBoss JIRA] Commented: (CDI-84) Non EE modules should be able to trigger creation of a BeanManager

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/CDI-84?page=com.atlassian.jira.plugin.sys... ] Aslak Knutsen commented on CDI-84: ---------------------------------- To my understanding, a BeanArchive packaged in a WAR or EAR's(EE Modules) library folder should not trigger the creation of a BeanManager unless the EE module itself is a BeanArchive. ps: I might be referring to the wrong Spec point here. pss: This might be a dup of CDI-49 depending on the definition of available(create vs visible). Between this and CDI-49, the general point is: Where ever the BeanArchive is located and whether or not you yourself(the caller) is a BeanArchive, you should see a BeanManager with content that follow the normal EE class visibility rules. (of course only if there are any BeanArchives within your visible range) > Non EE modules should be able to trigger creation of a BeanManager > ------------------------------------------------------------------ > > Key: CDI-84 > URL: https://issues.jboss.org/browse/CDI-84 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Aslak Knutsen > Fix For: 1.1 (Proposed) > > > 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. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-21) Support PostConstruct callbacks in Extension class

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-21?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-21: ------------------------- Fix Version/s: TBD (was: 1.1 (Proposed)) > Support PostConstruct callbacks in Extension class > -------------------------------------------------- > > Key: CDI-21 > URL: https://issues.jboss.org/browse/CDI-21 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Sivakumar Thyagarajan > Priority: Minor > Fix For: TBD > > > It is sometimes useful to get to know after a portable extension class has been instantiated, so that the state of the Extension could be initialized [ie not establishing state in the constructor and having it called twice when the Extension is proxied]. Though the 1.0 specification does not require this, it would be useful to support @PostConstruct callback on Extension class in the next version of the specification. > Please see https://jira.jboss.org/browse/WELD-713 for additional information on this issue. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev February 2011