September 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] Commented: (CDI-6) Clarify InjectionTarget method parameters

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-6?page=com.atlassian.jira.plugin.syst... ] Pete Muir commented on CDI-6: ----------------------------- Update the spec to indicate that the instance passed must be capable of having reflection performed on it, in order to allow additional injections to occur. Effectively this requires an impl to use subclassing for interception and decoration. > Clarify InjectionTarget method parameters > ----------------------------------------- > > Key: CDI-6 > URL: https://issues.jboss.org/browse/CDI-6 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Jozef Hartinger > Assignee: Marius Bogoevici > Priority: Minor > Fix For: 1.1 (Proposed) > > > For the inject() method, the spec says: "inject() performs dependency injection upon the given object". It is not clear to me what does the "given object" refer two. if the CDI implementation uses proxies to implement interceptors and decorators, I can see two candidates for "the given object": > - the product of the produce() method including interceptors and decorators -> a proxy > - the target instance -> the object created by calling a constructor (no interception/decoration) > Arguments for the first option > - Let's have and extension that adds additional dependency injection capabilities by providing a custom InjectionTarget implementation and wrapping default InjectionTarget instances with custom ones. The custom InjectionTarget implementation does the additional DI in the inject() method and delegates to the default InjectionTarget instance to finish the injection. This implementation needs a direct access to the target instance (it cannot access field values through a proxy) > - Interceptor-like behavior - similarity to interceptors, where the InvocationContext.getTarget() returns the (non-intercepted) target instance > Arguments for the second option > - the contract of the produce() method says: "produce() calls the constructor annotated @Inject if it exists, or the constructor with no parameters otherwise, as defined in Section 5.5.1, "Injection using the bean constructor", and returns the resulting instance. If the class has inter- ceptors, produce() is responsible for building the interceptors and decorators of the instance." which means it returns an intercepted/decorated instance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
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-119) Standard way to obtain a BeanManager regardless of environment

by Cloves Almeida (JIRA)

Standard way to obtain a BeanManager regardless of environment -------------------------------------------------------------- Key: CDI-119 URL: https://issues.jboss.org/browse/CDI-119 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Cloves Almeida Priority: Minor As an alternative to #CDI-117: There should be a standard way to obtain a BeanManager instance regardless of environment. I propose a BeanManagerFactory that would implement the following resolution: 1) if in a JEE environment, use the JNDI resolution already proposed on spec 2) if in a non-JEE servlet container, use the servlet context attribute as proposed in #CDI-117 3) else, fallback on a "singleton" BeanManager For extensability, one could override the resolution mechanism by providing his own BeanManagerResolver. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (CDI-116) Add programmatic API to manipulate XML metadata

by Pete Muir (JIRA)

Add programmatic API to manipulate XML metadata ----------------------------------------------- Key: CDI-116 URL: https://issues.jboss.org/browse/CDI-116 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, 3 months

1
5
0 / 0

[JBoss JIRA] Updated: (CDI-26) Bootstrap API for CDI

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-26?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-26: ------------------------- Summary: Bootstrap API for CDI (was: Embedded Mode) > Bootstrap API for CDI > --------------------- > > Key: CDI-26 > URL: https://issues.jboss.org/browse/CDI-26 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > > Weld and other CDI impls allow an embedded mode. > See http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#... for example -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-26) Embedded Mode

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-26?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-26: ------------------------------ I've spun out CDI-160 to split up the spec. > Embedded Mode > ------------- > > Key: CDI-26 > URL: https://issues.jboss.org/browse/CDI-26 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > > Weld and other CDI impls allow an embedded mode. > See http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#... for example -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Closed: (CDI-48) Global Interceptor/Decorator ordering

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-48?page=com.atlassian.jira.plugin.sys... ] Pete Muir closed CDI-48. ------------------------ Assignee: Pete Muir Fix Version/s: (was: 1.1 (Proposed)) Resolution: Duplicate Issue > Global Interceptor/Decorator ordering > ------------------------------------- > > Key: CDI-48 > URL: https://issues.jboss.org/browse/CDI-48 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators, Interceptors, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > > Currently interceptor/decorator ordering is specified on a per bean archive level. In the majority of cases the correct ordering is the same for every BDA in the application, so this violates DRY and opens the door to nasty bugs due to different ordering per module if beans.xml files get out of sync. > We should look at allowing the user to define interceptor and decorator ordering once per app and have this applied to all modules in the deployment. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-4) Need a way to provide ordering for Event observers, interceptors, decorators and alternatives

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ] Pete Muir updated CDI-4: ------------------------ Summary: Need a way to provide ordering for Event observers, interceptors, decorators and alternatives (was: Need a way to provide ordering for Event observers (@Observes)) Fix Version/s: 1.1 (Proposed) (was: TBD) I'm merging CDI-48 into this issue, whatever solution we arrive at must be the same across all scenarios. Furthermore, it's important to offer both SPI support for this, so alternative approaches to ordering can be created by the community, as well as API support, as this is a core concern. > Need a way to provide ordering for Event observers, interceptors, decorators and alternatives > --------------------------------------------------------------------------------------------- > > Key: CDI-4 > URL: https://issues.jboss.org/browse/CDI-4 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.0 > Environment: All > Reporter: Lincoln Baxter III > Assignee: Pete Muir > Fix For: 1.1 (Proposed) > > > There needs to be a way to specify some kind of ordering for Event observers. > Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Assigned: (CDI-4) Need a way to provide ordering for Event observers (@Observes)

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ] Pete Muir reassigned CDI-4: --------------------------- Assignee: Pete Muir (was: Mike Brock) > Need a way to provide ordering for Event observers (@Observes) > -------------------------------------------------------------- > > Key: CDI-4 > URL: https://issues.jboss.org/browse/CDI-4 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events, Portable Extensions > Affects Versions: 1.0 > Environment: All > Reporter: Lincoln Baxter III > Assignee: Pete Muir > Fix For: TBD > > > There needs to be a way to specify some kind of ordering for Event observers. > Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-18) Global enablement of interceptors, decorators and alternatives

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-18: ------------------------------ With the ordering problem solved, global enablement is possible. We would need to consider exactly how global enablement should be enacted, especially given that: * it would be backwards incompatible to put it in WEB-INF/beans.xml for a war * that there is nowhere obvious to put it in an EAR Any thoughts? > Global enablement of interceptors, decorators and alternatives > -------------------------------------------------------------- > > Key: CDI-18 > URL: https://issues.jboss.org/browse/CDI-18 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Decorators, Interceptors, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Mark Struberg > Priority: Critical > Fix For: 1.1 (Proposed) > > > Currently the spec defines that <interceptors>, <decorators> and <alternatives> affect only the Bean Archives where they are configured in (via beans.xml). > Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder! > This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the <alternatives> sections in their beans.xml. > Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2011