August 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-52) Make it clearer that an InjectionPoint injected into a disposer method refers to the producer method bean and not to the declaring bean

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-52?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-52: ------------------------------ Here is the original thread. http://weld-development-discussions.46994.n3.nabble.com/Please-check-that... > Make it clearer that an InjectionPoint injected into a disposer method refers to the producer method bean and not to the declaring bean > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-52 > URL: https://issues.jboss.org/browse/CDI-52 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Critical > Fix For: 1.1.EDR2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-204) Clarify ProcessInjectionPoint type parameters

by Jozef Hartinger (Created) (JIRA)

Clarify ProcessInjectionPoint type parameters --------------------------------------------- Key: CDI-204 URL: https://issues.jboss.org/browse/CDI-204 Project: CDI Specification Issues Issue Type: Clarification Components: Portable Extensions Affects Versions: 1.1.EDR1 Reporter: Jozef Hartinger Priority: Minor Fix For: 1.1 (Proposed) {quote} The container must fire an event for every injection point of every Java EE component class supporting injection that may be instantiated by the container at runtime. The event object must be of type javax.enterprise.inject.spi.ProcessInjectionPoint<T,X> where T is the bean class of the bean that declares the injection point, and X is the declared type of the injection point. {quote} The first paragraph implies that this event may be fired for injection points not necesarilly defined on a bean. In that case, the value of the T type parameter is unclear. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

2
4
0 / 0

[JBoss JIRA] (CDI-92) Allow injection of Bean object for a bean

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-92?page=com.atlassian.jira.plugin.sys... ] Pete Muir resolved CDI-92. -------------------------- Fix Version/s: 1.1.EDR2 Resolution: Done Merged changes. > Allow injection of Bean object for a bean > ----------------------------------------- > > Key: CDI-92 > URL: https://issues.jboss.org/browse/CDI-92 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR2, 1.1.EDR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-246) CDI#current() should return CDI<Object> instead of CDI<T>

by Martin Kouba (JIRA)

Martin Kouba created CDI-246: -------------------------------- Summary: CDI#current() should return CDI<Object> instead of CDI<T> Key: CDI-246 URL: https://issues.jboss.org/browse/CDI-246 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.1.EDR1 Reporter: Martin Kouba The reason is that it might be impossible to implement a parameterized method call like {{CDI.<Foo>current().get()}}. If {{CDI.current()}} would return {{CDI<Object>}} it would be obvious that one has to use {{CDI.current().select(Foo.class).get()}} for lookup of bean instances. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

2
5
0 / 0

[JBoss JIRA] (CDI-136) Assumption all @Stateful beans should be passivation capable

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-136?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-136. --------------------------- Resolution: Done Merged > Assumption all @Stateful beans should be passivation capable > ------------------------------------------------------------ > > Key: CDI-136 > URL: https://issues.jboss.org/browse/CDI-136 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans, Java EE integration > Affects Versions: 1.0, 1.1.EDR1 > Reporter: David Blevins > Assignee: Pete Muir > Fix For: 1.1.EDR2 > > > Stateful session beans in transactions can't be passivated and shouldn't have passivation requirements either, like request scope. > Stateful beans can be any scope. They are the Bertie Bott's Every Flavor Beans of EJB. It's too big of a brush to say that passivation is always required. That's the part we need to fix. > Stateful session beans that do passivate are pretty rare. They should be assumed to be @NormalScope unless otherwise specified. > The user should be able to say if they want passivation validation on their stateful bean and dependencies. > We should at a minimum change the related language of the spec to be "For every bean which declares a passivating scope, and for every stateful session bean ***that requires passivation***, " and discuss how to determine that an SFSB requires passivation. > From the EJB perspective this has always been a container detail, but we could have a rule in CDI that states the checks are not enforced unless the bean class explicitly implements java.io.Serializable. Alternatively we could make a generic @PassivationScoped annotation for other architectures that have flexible scopes and support passivation concepts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-231) Clarify if Alternatives are filtered in BeanManager#getBeans() or #resolve()

by Mark Struberg (JIRA)

Mark Struberg created CDI-231: --------------------------------- Summary: Clarify if Alternatives are filtered in BeanManager#getBeans() or #resolve() Key: CDI-231 URL: https://issues.jboss.org/browse/CDI-231 Project: CDI Specification Issues Issue Type: Clarification Components: Resolution Affects Versions: 1.1.EDR1, 1.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 1.1 (Proposed) The spec and javadoc are not really clear if the @Alternative filter defined in "5.2.1. Unsatisfied and ambiguous dependencies" is already performed in BeanManager#getBeans() or only later in BeanManager#resolve(). Back in 2009 I did a blind test with an old Weld version which only returned @Alternatives in getBeans() and all other beans got filtered out. This seems to have changed now (since quite some time). Can we make this more clear what should happen in getBeans() and what should happen in resolve()? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

4
8
0 / 0

[JBoss JIRA] (CDI-240) Add javadoc comment for ProcessSessionBean type parameter

by Martin Kouba (JIRA)

Martin Kouba created CDI-240: -------------------------------- Summary: Add javadoc comment for ProcessSessionBean type parameter Key: CDI-240 URL: https://issues.jboss.org/browse/CDI-240 Project: CDI Specification Issues Issue Type: Bug Components: Javadoc and API Reporter: Martin Kouba Priority: Minor Also add clarification why ProcessSessionBean type declaration is {{ProcessSessionBean<X> extends ProcessManagedBean<Object>}} and not {{ProcessSessionBean<X> extends ProcessManagedBean<X>}}. See also: http://lists.jboss.org/pipermail/cdi-dev/2012-July/001914.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

2
4
0 / 0

Support DI within BV constant validators

by Pete Muir

Hi Emmanuel, Gunnar, Gunnar filed https://issues.jboss.org/browse/CDI-241 however I don't think we should reference this in the CDI spec. Instead, Bean Validation should declare which of it's classes should be "Java EE component classes", which then makes them eligible for injection by CDI. These types are also referenced by the Java EE spec IIRC. ccing Linda and Bill, as this relates to how we define what receives CDI injections going forward, as I'm not sure they want to continue with this method. Pete

12 years, 4 months

5
12
0 / 0

[JBoss JIRA] (CDI-43) Allow Extensions to specify the annotations that they are interested in

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-43?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-43: ------------------------------ Jozef, I agree that if we implement this as a filter, then doing it at observer method level makes more sense. > Allow Extensions to specify the annotations that they are interested in > ----------------------------------------------------------------------- > > Key: CDI-43 > URL: https://issues.jboss.org/browse/CDI-43 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 1.1 (Proposed) > > > Currently portable extensions that wish to look for a specific annotation have to look through all availible classes in the ProcessAnnotatatedType event, which is quite inefficient. It would be good if extensions could do something like: > public void processAnnotatedType(@Observes @RequireAnnotations({(a)Unwraps.class}) ProcessAnnotatedType pat) > This could allow the container to take advantage of annotation indexing to improve boot time performance, as well as reducing uneeded processing in the observer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-43) Allow Extensions to specify the annotations that they are interested in

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-43?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-43: ------------------------------ {quote} I think that should should also apply to ProcessBean, ProcessProducer etc. In this case the even is only delivered if the declaring class (i.e. Bean.getBeanClass() ) meets these requirements. {quote} Can you elaborate on why? Also, if we specify this as a filter, I'm concerned that operating on the bean class is inconsistent, as a user would properly expect it to take into account modified type information from AnnotatedType. > Allow Extensions to specify the annotations that they are interested in > ----------------------------------------------------------------------- > > Key: CDI-43 > URL: https://issues.jboss.org/browse/CDI-43 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 1.1 (Proposed) > > > Currently portable extensions that wish to look for a specific annotation have to look through all availible classes in the ProcessAnnotatatedType event, which is quite inefficient. It would be good if extensions could do something like: > public void processAnnotatedType(@Observes @RequireAnnotations({(a)Unwraps.class}) ProcessAnnotatedType pat) > This could allow the container to take advantage of annotation indexing to improve boot time performance, as well as reducing uneeded processing in the observer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev August 2012