October 2014 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-407) Specifiy @Named @Alternatives

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-407?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-407: ---------------------------------- {code} @Specializes @Alternative public class SpecialCustomerANavigationController extends CustomerANavigationController {code} I think this should work provided you don't mix kinds of beans (I mean managed vs session etc.). Indirect specialization - it's described here: [4.3.1. Direct and indirect specialization|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#direct_an...]. > Specifiy @Named @Alternatives > ----------------------------- > > Key: CDI-407 > URL: https://issues.jboss.org/browse/CDI-407 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Inheritance and Specialization > Reporter: Thomas Andraschko > > It's actually a must-have for product development and a common case. > We would like to have multiple implementations in our core and just activate them via alternative. > I talked with struberg and its currently not defined in the specs. > e.g. > @Named public class A > @Named @Alternative public class B extends A > What should acutally happen if B is activated via beans.xml? > IMO B should be available in EL via "a" and "b". -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-407) Specifiy @Named @Alternatives

by Thomas Andraschko (JIRA)

[ https://issues.jboss.org/browse/CDI-407?page=com.atlassian.jira.plugin.sy... ] Thomas Andraschko commented on CDI-407: --------------------------------------- Don't know, maybe @Alternative isn't 100% the right thing for me. I'm actually looking for way to 100% replace the parent bean but via config. I have the following case: public class DefaultNavigationController @Specializes public class CustomerANavigationController extends DefaultNavigationController public class SpecialCustomerANavigationController extends CustomerANavigationController SpecialCustomerANavigationController should be an alternative specialization of CustomerANavigationController, which can be enabled for some tools. Maybe something like this would be great: @Speciales @Alternative public class SpecialCustomerANavigationController extends CustomerANavigationController If the bean is configures in the beans.xml, it should completely replace CustomerANavigationController and DefaultNavigationController. Maybe it's a special case but i have this case multiple times inside our product... > Specifiy @Named @Alternatives > ----------------------------- > > Key: CDI-407 > URL: https://issues.jboss.org/browse/CDI-407 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Inheritance and Specialization > Reporter: Thomas Andraschko > > It's actually a must-have for product development and a common case. > We would like to have multiple implementations in our core and just activate them via alternative. > I talked with struberg and its currently not defined in the specs. > e.g. > @Named public class A > @Named @Alternative public class B extends A > What should acutally happen if B is activated via beans.xml? > IMO B should be available in EL via "a" and "b". -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-407) Specifiy @Named @Alternatives

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-407?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-407: ---------------------------------- [~struberg] Mark, I'm not following the example with interfaces. Could you try to describe it in another way? :-) > Specifiy @Named @Alternatives > ----------------------------- > > Key: CDI-407 > URL: https://issues.jboss.org/browse/CDI-407 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Inheritance and Specialization > Reporter: Thomas Andraschko > > It's actually a must-have for product development and a common case. > We would like to have multiple implementations in our core and just activate them via alternative. > I talked with struberg and its currently not defined in the specs. > e.g. > @Named public class A > @Named @Alternative public class B extends A > What should acutally happen if B is activated via beans.xml? > IMO B should be available in EL via "a" and "b". -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-407) Specifiy @Named @Alternatives

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-407?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-407: ---------------------------------- [~tandraschko] {quote} In this case, is there any reason to still install/configure A as active bean? {quote} I'm not sure. Probably not in this very special scenario. But this is how it is defined right now and changing the behaviour wouldn't be backwards compatible. {quote} @Named("a") is a workaround but feels "ugly" and you always have to synchronize the names. {quote} You can still use String constants to avoid error-prone sync :-) > Specifiy @Named @Alternatives > ----------------------------- > > Key: CDI-407 > URL: https://issues.jboss.org/browse/CDI-407 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Inheritance and Specialization > Reporter: Thomas Andraschko > > It's actually a must-have for product development and a common case. > We would like to have multiple implementations in our core and just activate them via alternative. > I talked with struberg and its currently not defined in the specs. > e.g. > @Named public class A > @Named @Alternative public class B extends A > What should acutally happen if B is activated via beans.xml? > IMO B should be available in EL via "a" and "b". -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-407) Specifiy @Named @Alternatives

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-407?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-407: ----------------------------------- I agree with Martin that the Name must be explicitly given. I think the example which makes most sense is not inheritance but ipmlements {code} @Named public class A implements X @Named("a") @Alternative public class B implements X {code} Not sure which restrictions we have to define to get this properly working though. E.g. having different interfaces (or no extends) would render this illegal imo. But only at runtime as we cannot check those conditions for EL like we do for InjectionPoints. We need to think about it a bit. > Specifiy @Named @Alternatives > ----------------------------- > > Key: CDI-407 > URL: https://issues.jboss.org/browse/CDI-407 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Inheritance and Specialization > Reporter: Thomas Andraschko > > It's actually a must-have for product development and a common case. > We would like to have multiple implementations in our core and just activate them via alternative. > I talked with struberg and its currently not defined in the specs. > e.g. > @Named public class A > @Named @Alternative public class B extends A > What should acutally happen if B is activated via beans.xml? > IMO B should be available in EL via "a" and "b". -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-407) Specifiy @Named @Alternatives

by Thomas Andraschko (JIRA)

[ https://issues.jboss.org/browse/CDI-407?page=com.atlassian.jira.plugin.sy... ] Thomas Andraschko commented on CDI-407: --------------------------------------- Yep, thats what i expected. In this case, is there any reason to still install/configure A as active bean? As there is no qualifier or stereotype available, it would be possible to automatically install B as @Named("a") without explicity giving it a name. Or do i miss something here? @Named("a") is a workaround but feels "ugly" and you always have to synchronize the names. > Specifiy @Named @Alternatives > ----------------------------- > > Key: CDI-407 > URL: https://issues.jboss.org/browse/CDI-407 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Inheritance and Specialization > Reporter: Thomas Andraschko > > It's actually a must-have for product development and a common case. > We would like to have multiple implementations in our core and just activate them via alternative. > I talked with struberg and its currently not defined in the specs. > e.g. > @Named public class A > @Named @Alternative public class B extends A > What should acutally happen if B is activated via beans.xml? > IMO B should be available in EL via "a" and "b". -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-407) Specifiy @Named @Alternatives

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-407?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-407: ---------------------------------- {quote} @Named public class A @Named @Alternative public class B extends A What should acutally happen if B is activated via beans.xml? {quote} I think this is already covered in [4.1. Inheritance of type-level metadata|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#type_level_inhe...], [5.3.1. Ambiguous EL names|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#ambig_names] and other related sections. Note that bean names are not inherited unless specialization is used! Regarding your example: * bean A has a bean name "a" * bean B has a bean name "b" * so the names do not collide and even if you declare B as a selected alternative for a bean archive, EL expressions like #{a.foo} will not be affected, "a" will be resolved to bean A * bean name "b" will only be resolved to bean B if it's selected If we modify the example to: {code:java} @Named("a") public class A @Named("a") @Alternative public class B extends A {code} * both beans have the same bean name * if you declare B as a selected alternative, the name "a" will be resolved to bean B > Specifiy @Named @Alternatives > ----------------------------- > > Key: CDI-407 > URL: https://issues.jboss.org/browse/CDI-407 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Inheritance and Specialization > Reporter: Thomas Andraschko > > It's actually a must-have for product development and a common case. > We would like to have multiple implementations in our core and just activate them via alternative. > I talked with struberg and its currently not defined in the specs. > e.g. > @Named public class A > @Named @Alternative public class B extends A > What should acutally happen if B is activated via beans.xml? > IMO B should be available in EL via "a" and "b". -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-403) why decorator requires interface

by Thomas Andraschko (JIRA)

[ https://issues.jboss.org/browse/CDI-403?page=com.atlassian.jira.plugin.sy... ] Thomas Andraschko edited comment on CDI-403 at 10/17/14 3:40 PM: ----------------------------------------------------------------- We have a big product with many subproducts and customizations for customers. In our core libs, we have many default view controllers beans and JSF cc's/includes.. For some subproducts, we @Specialize the view controllers or even create seperate includes. e.g. core -> ViewAController subprojectA -> SpecializedViewAController Thats work fine with @Specialized/@Alternative. We also have shared libs for each customer. There we would like to decorate e.g. ViewAController. As our controller are currently classes, it would be perfect if it would be possible to apply decorators also on classes. Currently we have to introduce (senseless!) interfaces for our view controllers, which is actually only a workaround for this feature request because we don't gain any other benefit from it. It's really an important issue for product development and it would be great to see it in CDI2/JEE8 was (Author: tandraschko): We have a big product with many subproducts and customizations for customers. In our core libs, we have many default view controllers beans and JSF cc's/includes.. For some subproducts, we @Specialize the view controllers or even create seperate includes. e.g. core -> ViewAController subprojectA -> SpecializedViewAController Thats work fine with @Specialized/@Alternative. We also have shared libs for each customer. There we would like to decorate e.g. ViewAController. As our controller are currently classes, it would be perfect if it would be possible to apply decorators also on classes. Currently we have to introduce (senseless!) interfaces for our view controllers, which is actually only a workaround for this feature request because we don't gain any other benefit from it. > why decorator requires interface > -------------------------------- > > Key: CDI-403 > URL: https://issues.jboss.org/browse/CDI-403 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mathieu Lachance > > As discussed with Jozef Hartinger on the WELD forum thread (see forum reference and CDI-224), > would it be possible to revisit why decorator requires an interface ? > I do not understand the semantic difference between: > 1. a decorator to be an abstract class which implements an interface, which delegate to the same interface. > 2. a decorator to be a concrete class which extends a another class, which delegates to the same class. > Why 1. should be allowed and why 2. should be disallowed ? > As stated in CDI-224, if there is no technical reason of disallowing 2., should it be then considerate as a vendor specific feature to support it whether or not ? > It is kind of sad that only decorators requires an interface while all the others Java EE 6 features do not. > Thanks, -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-403) why decorator requires interface

by Thomas Andraschko (JIRA)

[ https://issues.jboss.org/browse/CDI-403?page=com.atlassian.jira.plugin.sy... ] Thomas Andraschko commented on CDI-403: --------------------------------------- We have a big product with many subproducts and customizations for customers. In our core libs, we have many default view controllers beans and JSF cc's/includes.. For some subproducts, we @Specialize the view controllers or even create seperate includes. e.g. core -> ViewAController subprojectA -> SpecializedViewAController Thats work fine with @Specialized/@Alternative. We also have shared libs for each customer. There we would like to decorate e.g. ViewAController. As our controller are currently classes, it would be perfect if it would be possible to apply decorators also on classes. Currently we have to introduce (senseless!) interfaces for our view controllers, which is actually only a workaround for this feature request because we don't gain any other benefit from it. > why decorator requires interface > -------------------------------- > > Key: CDI-403 > URL: https://issues.jboss.org/browse/CDI-403 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mathieu Lachance > > As discussed with Jozef Hartinger on the WELD forum thread (see forum reference and CDI-224), > would it be possible to revisit why decorator requires an interface ? > I do not understand the semantic difference between: > 1. a decorator to be an abstract class which implements an interface, which delegate to the same interface. > 2. a decorator to be a concrete class which extends a another class, which delegates to the same class. > Why 1. should be allowed and why 2. should be disallowed ? > As stated in CDI-224, if there is no technical reason of disallowing 2., should it be then considerate as a vendor specific feature to support it whether or not ? > It is kind of sad that only decorators requires an interface while all the others Java EE 6 features do not. > Thanks, -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

Today's meeting cancelled

by Antoine Sabot-Durand

Hi all As you know we are in the middle of CDI 2 f2f meeting, so I won't be available for our IRC meeting. Remember next week we'll have a meeting dedicated to event workshop. Antoine Sabot-Durand

10 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev October 2014