February 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] Updated: (CDI-34) Make special note in the spec about beans that are @Named via a stereotype being unselectable with Instance.select()

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-34?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-34: ------------------------- Issue Type: Clarification (was: Feature Request) Fix Version/s: 1.1 (Proposed) (was: TBD) > Make special note in the spec about beans that are @Named via a stereotype being unselectable with Instance.select() > -------------------------------------------------------------------------------------------------------------------- > > Key: CDI-34 > URL: https://issues.jboss.org/browse/CDI-34 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 1.0 > Reporter: Shane Bryzak > Priority: Minor > Fix For: 1.1 (Proposed) > > > For example, say we have the following bean: > public @Model class Foo implements IFoo { } > And we have the following injection point within another bean: > @Inject Instance<Foo> fooInstance; > It is not possible to select Foo via name using the Instance: > // This results in an UnsatisfiedDependencyException > Foo foo = fooInstance.select(new NamedLiteral("foo")).get(); > Instead, Foo must be annotated directly with the @Named annotation itself: > /* > * This Foo can be selected by name > */ > public @Named @RequestScoped Foo implements IFoo { } > This special case might be worthwhile mentioning in the next revision of the spec. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-12) Specifically exclude methods inherited from java.lang.Object from the list of business method invocations

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-12?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-12: ------------------------- Issue Type: Bug (was: Feature Request) Fix Version/s: 1.1 (Proposed) (was: TBD) > Specifically exclude methods inherited from java.lang.Object from the list of business method invocations > --------------------------------------------------------------------------------------------------------- > > Key: CDI-12 > URL: https://issues.jboss.org/browse/CDI-12 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Affects Versions: 1.0 > Reporter: Marius Bogoevici > Priority: Optional > Fix For: 1.1 (Proposed) > > > Without this specific exclusion, there is a theoretical possibility to treat these methods as business method invocations. > - they are defined on the object; > - will be present on the contextual reference; -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-76) JavaDocs regarding adding scopes are weak

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-76?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-76: ------------------------- Fix Version/s: (was: TBD) > JavaDocs regarding adding scopes are weak > ----------------------------------------- > > Key: CDI-76 > URL: https://issues.jboss.org/browse/CDI-76 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API, Portable Extensions > Affects Versions: 1.0 > Reporter: Lincoln Baxter III > Fix For: 1.1 (Proposed) > > > JavaDocs for adding scopes via the eventing API are a bit weak. > public void addScope(@Observes final BeforeBeanDiscovery event) > { > event.addScope(ProjectScoped.class, true, false); > } > Currently it is not clear that using this method is only required when not using the @NormalScoped annotation, and that it will in fact override the annotation if present. Additional docs should probably be placed on both sides of this relationship, to that affect. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-76) JavaDocs regarding adding scopes are weak

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-76?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-76: ------------------------- Issue Type: Clarification (was: Feature Request) Fix Version/s: 1.1 (Proposed) > JavaDocs regarding adding scopes are weak > ----------------------------------------- > > Key: CDI-76 > URL: https://issues.jboss.org/browse/CDI-76 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API, Portable Extensions > Affects Versions: 1.0 > Reporter: Lincoln Baxter III > Fix For: 1.1 (Proposed) > > > JavaDocs for adding scopes via the eventing API are a bit weak. > public void addScope(@Observes final BeforeBeanDiscovery event) > { > event.addScope(ProjectScoped.class, true, false); > } > Currently it is not clear that using this method is only required when not using the @NormalScoped annotation, and that it will in fact override the annotation if present. Additional docs should probably be placed on both sides of this relationship, to that affect. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-46) Clarify in the specification that extensions do not require a beans.xml file

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-46?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-46: ------------------------- Fix Version/s: 1.1 (Proposed) (was: TBD) > Clarify in the specification that extensions do not require a beans.xml file > ---------------------------------------------------------------------------- > > Key: CDI-46 > URL: https://issues.jboss.org/browse/CDI-46 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Packaging and Deployment > Affects Versions: 1.0 > Reporter: Shane Bryzak > Fix For: 1.1 (Proposed) > > -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (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 updated CDI-6: ------------------------ Fix Version/s: 1.1 (Proposed) (was: TBD) > 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 > 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

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-82) Clarify the usage of EJB3 interceptors as managed beans

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-82?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-82: ------------------------- Fix Version/s: 1.1 (Proposed) (was: TBD) > Clarify the usage of EJB3 interceptors as managed beans > ------------------------------------------------------- > > Key: CDI-82 > URL: https://issues.jboss.org/browse/CDI-82 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Interceptors, Java EE integration > Affects Versions: 1.0 > Reporter: Marius Bogoevici > Fix For: 1.1 (Proposed) > > > Background: > http://lists.jboss.org/pipermail/weld-dev/2010-April/002484.html -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-44) Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-44?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-44: ------------------------- Fix Version/s: 1.1 (Proposed) (was: TBD) > Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation > ------------------------------------------------------------------------------------------------------------- > > Key: CDI-44 > URL: https://issues.jboss.org/browse/CDI-44 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 1.1 (Proposed) > > > When implementing interception using proxying the behaour of self invocation is quite well defined, if a method is invoked on the proxy it is intercepted, if it is invoked on the actual bean (usually through self-invocation) it is not. > When implementing interception though sub classing this is much less well definied, and the only way to track if an invocation is intercepted or not is through a thread local flag. At the moment in weld this is reset when a call is made on a client proxy, so if we have an intercepted bean A and a SessionScoped bean B and A invokes B when invokes A the second call to A is intercepted. If however B is pseudo scoped, then the second invocation is not intercepted. The correct behaviour here should be specified by the specification. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-70) Clarify that if an extension provides an Annotated* then it is considered "metadata complete"

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-70?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-70: ------------------------- Issue Type: Clarification (was: Bug) > Clarify that if an extension provides an Annotated* then it is considered "metadata complete" > --------------------------------------------------------------------------------------------- > > Key: CDI-70 > URL: https://issues.jboss.org/browse/CDI-70 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > > I think the correct behavior is to ignore any members that are missing from the AnnotatedType. You should not be directly accessing the reflection API at all. If the parameters for a method or a constructor don't match the underlying class, it should be considered a definition error. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-75) Clarify what happens to a bean which belongs to inactive when it observes an event

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-75?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-75: ------------------------- Issue Type: Clarification (was: Bug) > Clarify what happens to a bean which belongs to inactive when it observes an event > ---------------------------------------------------------------------------------- > > Key: CDI-75 > URL: https://issues.jboss.org/browse/CDI-75 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > 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

14 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev February 2011