September 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] Commented: (CDI-87) Declarative control over classes including in bean archive scanning

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/CDI-87?page=com.atlassian.jira.plugin.sys... ] Geoffrey De Smet commented on CDI-87: ------------------------------------- @Pete Tnx, please ignore my comment then, I agree that <include> <exclude> are very useful when restricted to the defining module. I opened CDI-150 a while ago related to my use cases. > Declarative control over classes including in bean archive scanning > ------------------------------------------------------------------- > > Key: CDI-87 > URL: https://issues.jboss.org/browse/CDI-87 > 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 introduced a XML syntax for this -- 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

Enabling extensions

by Pete Muir

Seam team, and others on the CDI EG, Looking for feedback on an issue Marius and I discussed in CDI 1.0. This is potentially an issue - we weren't sure if people had seen it in the real world, hopefully you may have seen feedback in the forums or at conferences. This relates closely to the interceptor/decorator/alternative enabling discussion. Typically an extension class is packaged in a jar, along with a META-INF/services/javax.enterprise.inject.spi.Extension file which enables it. However, this means that an application, or another extension, has no way of disabling extensions. Is this a problem, really? Or just theoretically.

13 years, 3 months

3
3
0 / 0

[JBoss JIRA] Commented: (CDI-87) Declarative control over classes including in bean archive scanning

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-87?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-87: ------------------------------ Geoffrey, I wanted to say that we will spin your stuff out into a different issue. I will get to that. Don't fear, we're taking your use cases onboard ;-) Probably with your issue fixed, we would likely be restricting inclusion/exclusion to classes in the defining module. > Declarative control over classes including in bean archive scanning > ------------------------------------------------------------------- > > Key: CDI-87 > URL: https://issues.jboss.org/browse/CDI-87 > 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 introduced a XML syntax for this -- 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-87) Declarative control over classes including in bean archive scanning

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/CDI-87?page=com.atlassian.jira.plugin.sys... ] Geoffrey De Smet commented on CDI-87: ------------------------------------- I don't think general <includes> and <excludes> alone are a good idea. *They break reuse and transitive reuse:* If myProject's beans.xml <includes> seam-security's beans.xml then it will crash, because seam-security's beans.xml 1.0 depends on seam-international's beans.xml (but seam-security's beans.xml 1.1 might not). The point is, myProject doesn't care about seam-international: it uses a certain version of seam-security and anything that that version of seam-security needs, should be automatically transitively be included too. Also, not using <includes> is not on option either, as myProject wants control over the beans.xml's that get activated (not just everything that happens to be in the classpath). > Declarative control over classes including in bean archive scanning > ------------------------------------------------------------------- > > Key: CDI-87 > URL: https://issues.jboss.org/browse/CDI-87 > 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 introduced a XML syntax for this -- 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-87) Declarative control over classes including in bean archive scanning

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-87?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-87: ------------------------------ h1. Proposal Standardize the format from Weld http://docs.jboss.org/weld/reference/latest/en-US/html/configure.html#d0e... h1. Notes * The Weld format also has an {{<include>}} element * The Weld format closely matches Mark's proposal (uses attributes more strongly) and provides for both ant-style, package based globbing of names (com.acme.**) and regex. It also includes the idea of a filter to allow you to exclude based on a system property being present or classes being available. * Unless I get any negative feedback this will become a patch soon. > Declarative control over classes including in bean archive scanning > ------------------------------------------------------------------- > > Key: CDI-87 > URL: https://issues.jboss.org/browse/CDI-87 > 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 introduced a XML syntax for this -- 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-6) Clarify InjectionTarget method parameters

by Marius Bogoevici (JIRA)

[ https://issues.jboss.org/browse/CDI-6?page=com.atlassian.jira.plugin.syst... ] Marius Bogoevici commented on CDI-6: ------------------------------------ Must refer to the "target instance" (which represents the unwrapped, unintercepted and undecorated object") > 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-155) specify Instance<T>#destroy()

by Mark Struberg (JIRA)

specify Instance<T>#destroy() ----------------------------- Key: CDI-155 URL: https://issues.jboss.org/browse/CDI-155 Project: CDI Specification Issues Issue Type: Bug Components: Beans Affects Versions: 1.0 Reporter: Mark Struberg Priority: Critical Fix For: 1.1 (Proposed) In CDI-14, Pete mentioned that > We would need to extend Instance<> with a void destroy(T instance); method. Ouch, very true. This is desperately needed for destroying @Dependent and other not-normalscoped beans which got created via Instance<T>#get(). This currently creates memory leaks because we have no way to dispose the CreationalContext<T> used for creating this very bean. And since the CreationalContext<T> also holds references to all Interceptors, Decorators and subsequently injected beans, those won't be released neither. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
1
0 / 0

[JBoss JIRA] Commented: (CDI-14) Add instance() method to BeanManager

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-14?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-14: ------------------------------ Craig, the issue for EntityListener injection is CDI-144 :-) > Add instance() method to BeanManager > ------------------------------------ > > Key: CDI-14 > URL: https://issues.jboss.org/browse/CDI-14 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1 (Confirmed) > > > Currently obtaining a contextual reference is quite a complex operation, adding a method like: > Instance<Object> instance(); > would make it much easier. -- 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-14) Add instance() method to BeanManager

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-14?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-14: ---------------------------------- I created CDI-155 for the Instance<T>#destroy() issue to prevent mem leaks with @Dependent beans. > Add instance() method to BeanManager > ------------------------------------ > > Key: CDI-14 > URL: https://issues.jboss.org/browse/CDI-14 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1 (Confirmed) > > > Currently obtaining a contextual reference is quite a complex operation, adding a method like: > Instance<Object> instance(); > would make it much easier. -- 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] Issue Comment Edited: (CDI-51) Support static injection

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-51?page=com.atlassian.jira.plugin.sys... ] Mark Struberg edited comment on CDI-51 at 9/9/11 4:12 AM: ---------------------------------------------------------- any news on that? This would also change a few serializable/passivationCapable definitions like e.g 6.6.4 was (Author: struberg): any news on that? > 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. 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