[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, 9 months
[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, 9 months
[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, 9 months
[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, 9 months
[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, 9 months
[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, 9 months
[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, 9 months