February 2013 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-141) remove overly strict Serialization requirements for @Inject method and ct parameters

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-141?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-141. --------------------------- Resolution: Done This is covered by CDI-228 > remove overly strict Serialization requirements for @Inject method and ct parameters > ------------------------------------------------------------------------------------ > > Key: CDI-141 > URL: https://issues.jboss.org/browse/CDI-141 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans, Resolution > Affects Versions: 1.0 > Reporter: Mark Struberg > Assignee: Mark Struberg > Priority: Minor > Fix For: 1.1.PFD > > > Section 6.6.4 declares that: > > If a producer method declares a passivating scope and: > > .. > > * has a parameter that does not resolve to a passivation capable > > dependency, > > then the container automatically detects the problem and > > treats it as a deployment problem. > Something like > @Produces @SessionScoped @AutoAuthenticated > public User getCurrentUser(MyConfig mc) { > return ... > (MyConfig is not Serializable and gets produced as @ApplicationScoped) would not be allowed. > The same restriction currently applies to parameters of @Inject methods and constructors: > >If a managed bean which declares a passivating scope: > > has a ... , bean constructor parameter or initializer method parameter > > that does not resolve to a passivation capable dependency, ... > This maybe comes from simple @Inject setters which set the given method parameters 1:1 into class members. But for all other cases this restriction is just way too rigid. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-198) Make beans.xml validation consistent with the ProcessModule event

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-198?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-198. --------------------------- Resolution: Out of Date > Make beans.xml validation consistent with the ProcessModule event > ----------------------------------------------------------------- > > Key: CDI-198 > URL: https://issues.jboss.org/browse/CDI-198 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 1.1.EDR > Reporter: Jozef Hartinger > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.PFD > > > The validation of enabled interceptors, alternatives and decorators is currently tightly related to the beans.xml file, e.g.: > {quote}If the same class is listed twice under the <interceptors> element, the container automatically detects the problem and treats it as a deployment problem.{quote} > With CDI-97 in place, which allows extensions to change the enabled alternatives, decorators and interceptors, this is no longer sufficient. IMO, the validation of enabled interceptors and decorators should be the following: > 1.) For each deployment descriptor, the container verifies that it does not contain duplicate interceptors, decorators or alternatives. > 2.) For each BDA, the container fires the ProcessModule event allowing extensions to modify enabled alternatives, interceptors and decorators. > 3.) For each BDA, the container verifies that the resulting collection of enabled alternatives, decorators and interceptors does not contain duplicates. > The step 1.) is not actually necessary but may be convenient. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-198) Make beans.xml validation consistent with the ProcessModule event

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-198?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-198. --------------------------- Assignee: Pete Muir Resolution: Done Out of date given @Priority changes > Make beans.xml validation consistent with the ProcessModule event > ----------------------------------------------------------------- > > Key: CDI-198 > URL: https://issues.jboss.org/browse/CDI-198 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 1.1.EDR > Reporter: Jozef Hartinger > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.PFD > > > The validation of enabled interceptors, alternatives and decorators is currently tightly related to the beans.xml file, e.g.: > {quote}If the same class is listed twice under the <interceptors> element, the container automatically detects the problem and treats it as a deployment problem.{quote} > With CDI-97 in place, which allows extensions to change the enabled alternatives, decorators and interceptors, this is no longer sufficient. IMO, the validation of enabled interceptors and decorators should be the following: > 1.) For each deployment descriptor, the container verifies that it does not contain duplicate interceptors, decorators or alternatives. > 2.) For each BDA, the container fires the ProcessModule event allowing extensions to modify enabled alternatives, interceptors and decorators. > 3.) For each BDA, the container verifies that the resulting collection of enabled alternatives, decorators and interceptors does not contain duplicates. > The step 1.) is not actually necessary but may be convenient. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-198) Make beans.xml validation consistent with the ProcessModule event

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-198?page=com.atlassian.jira.plugin.sy... ] Pete Muir reopened CDI-198: --------------------------- > Make beans.xml validation consistent with the ProcessModule event > ----------------------------------------------------------------- > > Key: CDI-198 > URL: https://issues.jboss.org/browse/CDI-198 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 1.1.EDR > Reporter: Jozef Hartinger > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.PFD > > > The validation of enabled interceptors, alternatives and decorators is currently tightly related to the beans.xml file, e.g.: > {quote}If the same class is listed twice under the <interceptors> element, the container automatically detects the problem and treats it as a deployment problem.{quote} > With CDI-97 in place, which allows extensions to change the enabled alternatives, decorators and interceptors, this is no longer sufficient. IMO, the validation of enabled interceptors and decorators should be the following: > 1.) For each deployment descriptor, the container verifies that it does not contain duplicate interceptors, decorators or alternatives. > 2.) For each BDA, the container fires the ProcessModule event allowing extensions to modify enabled alternatives, interceptors and decorators. > 3.) For each BDA, the container verifies that the resulting collection of enabled alternatives, decorators and interceptors does not contain duplicates. > The step 1.) is not actually necessary but may be convenient. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-303) Clarify declaring selected alternatives for an application

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-303?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-303. --------------------------- Resolution: Out of Date Outdated by usage of @priority > Clarify declaring selected alternatives for an application > ---------------------------------------------------------- > > Key: CDI-303 > URL: https://issues.jboss.org/browse/CDI-303 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 1.1.PFD > > > It's not clear whether an alternative with a default priority but not selected for an application is selected for the bean archive whose beans.xml declares it. > The spec states: > {quote} > An alternative may be given a default priority, but not selected for an application using the <alternatives> element of the beans.xml file of the bean archive. The <alternatives> element contains a list of bean classes and stereotypes, along with a disabled flag and a priority attribute. An alternative is selected for the bean archive if either: > ... > {quote} > Pay attention to the last sentence of the paragraph. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-314) Clarify behaviour if both a stereotype and a bean class is used to select/deselect an alternative bean

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-314?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-314. --------------------------- Resolution: Out of Date Outdated by usage of @Priority > Clarify behaviour if both a stereotype and a bean class is used to select/deselect an alternative bean > ------------------------------------------------------------------------------------------------------ > > Key: CDI-314 > URL: https://issues.jboss.org/browse/CDI-314 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.1.PRD > Reporter: Martin Kouba > Fix For: 1.1.PFD > > > In CDI 1.1 a bean which has {{@Alternative}} stereotype applied may be selected using the bean class. If both a stereotype and a bean class is used to select/deselect an alternative bean, conflicts may occur (in the cotext of CDI-18). E.g.: > {code} > @Stereotype > @Alternative > @Target({ TYPE, METHOD, FIELD }) > @Retention(RUNTIME) > public @interface Mock { > } > @Mock > class Foo { > } > <beans> > <alternatives> > <class priority="1000">org.mycompany.Foo</class> > <stereotype priority="100">org.mycompany.Mock</stereotype> > </alternatives> > </beans> > {code} -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-302) Issues with interceptor and decorator ordering

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-302?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-302. --------------------------- Resolution: Out of Date This was fixed by using @Priority > Issues with interceptor and decorator ordering > ---------------------------------------------- > > Key: CDI-302 > URL: https://issues.jboss.org/browse/CDI-302 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Jozef Hartinger > Fix For: 1.1.PFD > > > 1.) If a library globally enables an alternative/interceptor/decorator it is not possible to disable it in other libraries without repackaging the library / other libraries. > 2.) In the legacy mode (enablement for bean archive), the priority of an alternative/interceptor/decorator is undefined (other than the first one in the list) -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-322) Reflect @AroundConstruct interception type

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-322?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-322. --------------------------- Resolution: Done Added > Reflect @AroundConstruct interception type > ------------------------------------------ > > Key: CDI-322 > URL: https://issues.jboss.org/browse/CDI-322 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java EE integration > Affects Versions: 1.1.PRD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Fix For: 1.1.PFD > > > within javax.enterprise.inject.spi.InterceptionType -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (CDI-304) Clarify Producers for injection into generic types

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-304?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-304. --------------------------- Resolution: Done Fixed, thanks Jozef. > Clarify Producers for injection into generic types > -------------------------------------------------- > > Key: CDI-304 > URL: https://issues.jboss.org/browse/CDI-304 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Affects Versions: 1.1.PRD > Reporter: Mark Struberg > Assignee: Pete Muir > Fix For: 1.1.PFD > > > There is a discussion over in DeltaSpike whether an injection point > {code} > @Inject > private JsfMessage<SomeMessageClass>; > {code} > with a producer method > {code} > @Produces @Dependent > JsfMessage createMessage(InjectionPoint ip) > {code} > 5.2 imo only defines the other way around. Having a raw type at the injection point and a parameterized producer method. > We should define how this is intended to work. > Please note that the producer above works in all existing containers so far but not in Weld2-beta1. > Here is the link to the DS issue: https://issues.apache.org/jira/browse/DELTASPIKE-295 -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (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 resolved CDI-75. -------------------------- Resolution: Done Merged > 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 > Assignee: Pete Muir > Fix For: 1.1.PFD > > -- 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

11 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev February 2013