July 2013 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-85) Clarify use of "to" and "from" when refering to assignments in section 5.2.3

by Arne Limburg (JIRA)

[ https://issues.jboss.org/browse/CDI-85?page=com.atlassian.jira.plugin.sys... ] Arne Limburg commented on CDI-85: --------------------------------- Thanks > Clarify use of "to" and "from" when refering to assignments in section 5.2.3 > ---------------------------------------------------------------------------- > > Key: CDI-85 > URL: https://issues.jboss.org/browse/CDI-85 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.EDR > > -- 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

1
0
0 / 0

[JBoss JIRA] (CDI-85) Clarify use of "to" and "from" when refering to assignments in section 5.2.3

by Marko Lukša (JIRA)

[ https://issues.jboss.org/browse/CDI-85?page=com.atlassian.jira.plugin.sys... ] Marko Lukša commented on CDI-85: -------------------------------- The pull request is at https://github.com/cdi-spec/cdi/pull/34 > Clarify use of "to" and "from" when refering to assignments in section 5.2.3 > ---------------------------------------------------------------------------- > > Key: CDI-85 > URL: https://issues.jboss.org/browse/CDI-85 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.EDR > > -- 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

1
0
0 / 0

[JBoss JIRA] (CDI-85) Clarify use of "to" and "from" when refering to assignments in section 5.2.3

by Arne Limburg (JIRA)

[ https://issues.jboss.org/browse/CDI-85?page=com.atlassian.jira.plugin.sys... ] Arne Limburg commented on CDI-85: --------------------------------- What happened to this issue? The pull request is not available any more and the wording in the spec still seems to be wrong. > Clarify use of "to" and "from" when refering to assignments in section 5.2.3 > ---------------------------------------------------------------------------- > > Key: CDI-85 > URL: https://issues.jboss.org/browse/CDI-85 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.EDR > > -- 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

1
0
0 / 0

CDI and generics

by Arne Limburg

Hi all, At the OpenWebBeans list we are currently discussing handling of generics in CDI. I found a test in the CDI 1.1 TCK, which imho has a bug. The test is org.jboss.cdi.tck.tests.inheritance.generics.MemberLevelInheritanceTest and the (simplified) deployment scenario is the following: public class Baz<T> { } public class Qux extends Baz<String> { } @Vetoed public class Bar<T1, T2> { @Inject private Baz<T1> baz; @Inject private Baz<List<T2>> t2BazList; } @RequestScoped public class Foo extends Bar<String, Qux> { } public class Producer { @Produces @Amazing public String produceString() { return "ok"; } @Produces public String[] produceStringArray() { return new String[0]; } @Produces public Baz<Baz<Qux>> produceBazBazQux() { return new Baz(); } } The class Bar has some more injection points, but that does not matter. Due to the TCK this deployment should work, but I don't know how. Question: Is Baz a Bean (I suppose so) and may it be injected into Bean Foo, more precisely into the second injection point of class Bar? - If yes, it also should be injected into the first injection point, right? This would lead to an AmbiguousResolutionException since Qux may also be injected into the first injection point. - If no, the deployment should fail with a UnsatisfiedResolutionException since there is no Bean that can be injected into that injection point. Is this a bug in the TCK and if not, how is this supposed to work? Cheers, Arne

11 years

5
14
0 / 0

CDI Embedded Mode

by Vaibhav Kulkarni

Hi, Can anyone please let me know if the Embedded mode is supported in newly released CDI 1.1? Could you also be point me to documentation on how to use it please? Thanks, Vaibhav

11 years

4
5
0 / 0

[JBoss JIRA] (CDI-388) Session bean specialization example is not valid

by Martin Kouba (JIRA)

Martin Kouba created CDI-388: -------------------------------- Summary: Session bean specialization example is not valid Key: CDI-388 URL: https://issues.jboss.org/browse/CDI-388 Project: CDI Specification Issues Issue Type: Bug Reporter: Martin Kouba {code} @Stateless public class LoginActionBean implements LoginAction { ... } @Stateless @Mock @Specializes public class MockLoginActionBean extends LoginActionBean { ... } {code} {{LoginAction}} is a local interface (whether it's annotated with {{@Local}} or not) therefore the bean types of {{LoginActionBean}} are {{LoginAction}}, {{Object}}. On the other hand {{MockLoginActionBean}} does not have a local interface (client views exposed by a particular session bean are not inherited by a subclass; see also the EJB spec 4.9.2.1 Session Bean Superclasses). Therefore the bean types of {{MockLoginActionBean}} are {{MockLoginActionBean}}, {{LoginActionBean}} and {{Object}} (3.2.2 Bean types of a session bean: "the unrestricted set of bean types contains the bean class and all superclasses"). The spec also states (4.3.1 Direct and indirect specialization): {quote} Furthermore, X must have all the bean types of Y. If X does not have some bean type of Y, the container automatically detects the problem and treats it as a definition error. {quote} So I believe the aforementioned example should result in a definition exception. To make it valid the {{MockLoginActionBean}} should also implement {{LoginAction}}. -- 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

1
0
0 / 0

cdi 1.1 api on java.net repository

by Joseph Bergmark

Are there any plans to push the CDI 1.1 APIs to the java.net maven repository? Sincerely, Joe Bergmark

11 years

4
5
0 / 0

[JBoss JIRA] (CDI-387) Incorrect rule regarding assignability of parameterized types when both bean type parameter and required type parameter are type variables

by Marko Lukša (JIRA)

Marko Lukša created CDI-387: ------------------------------- Summary: Incorrect rule regarding assignability of parameterized types when both bean type parameter and required type parameter are type variables Key: CDI-387 URL: https://issues.jboss.org/browse/CDI-387 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.1.PFD Reporter: Marko Lukša Say we have the following required type: {code} Dao<X extends Medium> {code} and classes: {code} class Small {...} class Medium extends Small {...} class Big extends Medium {...} {code} According to the last bullet of section 5.2.4., bean type {{Dao<X extends Small>}} is assignable to the required type {{Dao<X extends Medium>}}, since the required type parameter and bean type parameter are both type variables and the upper bound of the required type parameter ({{Medium}}) is assignable to the upper bound of the bean type parameter ({{Small}}). On the other hand, according to the same rules, bean type {{Dao<X extends Big>}} is not assignable to required type {{Dao<X extends Medium>}}. It should be the other way around. Bullet 5 should be corrected in the same way bullet 4 was corrected in CDI-85. The upper bound of the required type parameter should be assignable *from* the upper bound of the bean type parameter. -- 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

1
0
0 / 0

[JBoss JIRA] (CDI-386) Two examples in section 5.2.4 contradict the rules of the same section

by Marko Lukša (JIRA)

Marko Lukša created CDI-386: ------------------------------- Summary: Two examples in section 5.2.4 contradict the rules of the same section Key: CDI-386 URL: https://issues.jboss.org/browse/CDI-386 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.1.PFD Reporter: Marko Lukša The examples in section 5.2.4 state that bean {{Dao<T extends Persistent>}} is eligible for injection into both {{Dao<Order>}} and {{Dao<User>}}, but according to the rules stated in the same section this isn't true. Also note that the spec doesn't state explicitly that {{Order extends Persistent}} and {{User extends Persistent}}. -- 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

1
0
0 / 0

Question about section 4.2

by John D. Ament

Hi all In section 4.2 of the CDI spec (both 1.0 and 1.1) there are references to injection around generic types. I was wondering if someone could clarify this case? I have an interface: public interface Handler<? extends Foo> { ... } and then I have two implementations public class FarlowHandler implements Handler<Farlow> { .. } public class BagelHandler implements Handler<Bagel> { ... } Is it expected that I should be able to inject references to these by doing: @Inject private Handler<Farlow> fHandler; @Inject private Handler<Bagel> bHandler; ? Is there any expected difference when using EJBs? John

11 years

4
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev July 2013