September 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] (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 reassigned CDI-6: --------------------------- Assignee: Pete Muir (was: Marius Bogoevici) > 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: Pete Muir > 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-261) 2.5.2 uses the phrase "bean implementation" which is not well defined

by Pete Muir (JIRA)

Pete Muir created CDI-261: ----------------------------- Summary: 2.5.2 uses the phrase "bean implementation" which is not well defined Key: CDI-261 URL: https://issues.jboss.org/browse/CDI-261 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.0 Reporter: Pete Muir Fix For: 1.1.PRD {quote} The default name for a bean depends upon the bean implementation. {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

13 years, 4 months

1
2
0 / 0

[JBoss JIRA] (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: ------------------------------ The proposal includes an event to sort the list, they are not exclusive options. > 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

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

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Romain Manni-Bucau commented on CDI-18: --------------------------------------- I know ordinal is often used in techincal stacks (linux keenel, owb...) but it is so far from business...another solution should be found. The cleaner is an event to sort the list IMO or an annotation to define the interceptorbindingS in order > 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-29) Method of accessing contexts regardless of active state

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-29?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-29: ------------------------- Fix Version/s: TBD (was: 1.1 (Proposed)) Slipping context management issues > Method of accessing contexts regardless of active state > ------------------------------------------------------- > > Key: CDI-29 > URL: https://issues.jboss.org/browse/CDI-29 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Nicklas Karlsson > Fix For: TBD > > > It would be practical to have a way of accessing contexts from the BeanManager regardless of their active state. Currently, contexts cannot be activated (e.g. Conversation) in a portable way because there is no way of getting the inactive context in order to activate it. -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-51) Support static injection

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-51?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-51: ------------------------------ Do we want to do this? What are the use cases? > Support static injection > ------------------------ > > Key: CDI-51 > URL: https://issues.jboss.org/browse/CDI-51 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (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: ------------------------------ Maybe we define that you can use one style or the other? > 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
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

13 years, 4 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

13 years, 4 months

8
15
0 / 0

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

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger commented on CDI-18: ------------------------------------ This may be tricky to specify in a backwards-compatible fashion. In a legacy application with let's say 2 modules each having a set of enabled interceptors whose order is specified the old way (the order of <interceptor> elements in beans.xml - no magic numbers), would the legacy ordering still work and would those interceptors be still enabled for a certain module only? What if these two ways of enabling stuff meet in a single application? > 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2012