You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by "Peter Rader (Jira)" <ji...@apache.org> on 2020/12/05 11:19:00 UTC
[jira] [Updated] (ARIES-2027) CDI of java.util.Set and order of
org.ietf.jgss.Oid
[ https://issues.apache.org/jira/browse/ARIES-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Rader updated ARIES-2027:
-------------------------------
Description:
TL;DR
CDI in Aries allowes only one-bean-injection. CDI in Aries should allow flexible-bean-amount-injection using java.util.Set.
Long:
Since karaf show the [example of CDI using Aries|https://github.com/apache/karaf/blob/29d02c282acb370cca18535ad9a6bbbb0823b1de/examples/karaf-cdi-example/karaf-cdi-example-consumer/src/main/java/org/apache/karaf/examples/cdi/consumer/MyConsumerBean.java#L31] there is a feature missing that is implemented in other CDI containers like SpringCDI: The possibility of inject multiple beans into one field.
Currently the field in the example is written like this:
{code:java}
@Reference
@Inject
private MyServiceBean service;
{code}
Unfortunately the MyServiceBean is a concretation and a dependency. Since the dependency-inversion-principle (DIP) points out: "Entities must depend on abstractions, not on concretions.". This example is concrete-dependency because:
# We are strict to use only-one implementation of a bean.
# It is not possible to have no implementation (optional) of the bean.
h3. Why we should not allow other collection-types than Set?
We have other candidates for collection types.
# Arrays
They are impractical because we can not use the keyword final as the access-modifiers of the instances because final on a array is only finalizing the size of the array. You could modify the array using java-code what is error prone.
# java.util.List
They are impractical because a List might contain the same instance multiple times what allowes a unexpected ambiguity. Since the CDI-Container is the only authority who creates the instances, we can eliminate this unexpected ambiguity.
# javax.swing.TreeNode
Its not part of the core-jdk, it might require Compact-Profiles.
By the way: Latter a Springs Ordered-pendant is requested to order the set-elements, but using org.ietf.jgss.Oid instead of a number.
was:
TL;DR
CDI in Aries allowes only one-bean-injection. CDI in Aries should allow flexible-bean-amount-injection using java.util.Set.
Long:
Since karaf show the [example of CDI using Aries|https://github.com/apache/karaf/blob/29d02c282acb370cca18535ad9a6bbbb0823b1de/examples/karaf-cdi-example/karaf-cdi-example-consumer/src/main/java/org/apache/karaf/examples/cdi/consumer/MyConsumerBean.java#L31] there is a feature missing that is implemented in other CDI containers like SpringCDI: The possibility of inject multiple beans into one field.
Currently the field in the example is written like this:
{code:java}
@Reference
@Inject
private MyServiceBean service;
{code}
Unfortunately the MyServiceBean is a concretation and a dependency. Since the dependency-inversion-principle (DIP) points out: "Entities must depend on abstractions, not on concretions.". This example is concrete-dependency because:
# We are strict to use only-one implementation of a bean.
# It is not possible to have no implementation (optional) of the bean.
h3. Why we should not allow other collection-types?
We have other candidates for collection types.
# Arrays
They are impractical because we can not use the keyword final as the access-modifiers of the instances because final on a array is only finalizing the size of the array. You could modify the array using java-code what is error prone.
# java.util.List
They are impractical because a List might contain the same instance multiple times what allowes a unexpected ambiguity. Since the CDI-Container is the only authority who creates the instances, we can eliminate this unexpected ambiguity.
# javax.swing.TreeNode
Its not part of the core-jdk, it might require Compact-Profiles.
By the way: Latter a Springs Ordered-pendant is requested to order the set-elements, but using org.ietf.jgss.Oid instead of a number.
> CDI of java.util.Set and order of org.ietf.jgss.Oid
> ---------------------------------------------------
>
> Key: ARIES-2027
> URL: https://issues.apache.org/jira/browse/ARIES-2027
> Project: Aries
> Issue Type: New Feature
> Components: CDI
> Affects Versions: cdi-1.1.3
> Reporter: Peter Rader
> Priority: Major
>
> TL;DR
> CDI in Aries allowes only one-bean-injection. CDI in Aries should allow flexible-bean-amount-injection using java.util.Set.
>
> Long:
> Since karaf show the [example of CDI using Aries|https://github.com/apache/karaf/blob/29d02c282acb370cca18535ad9a6bbbb0823b1de/examples/karaf-cdi-example/karaf-cdi-example-consumer/src/main/java/org/apache/karaf/examples/cdi/consumer/MyConsumerBean.java#L31] there is a feature missing that is implemented in other CDI containers like SpringCDI: The possibility of inject multiple beans into one field.
> Currently the field in the example is written like this:
> {code:java}
> @Reference
> @Inject
> private MyServiceBean service;
> {code}
> Unfortunately the MyServiceBean is a concretation and a dependency. Since the dependency-inversion-principle (DIP) points out: "Entities must depend on abstractions, not on concretions.". This example is concrete-dependency because:
> # We are strict to use only-one implementation of a bean.
> # It is not possible to have no implementation (optional) of the bean.
> h3. Why we should not allow other collection-types than Set?
> We have other candidates for collection types.
> # Arrays
> They are impractical because we can not use the keyword final as the access-modifiers of the instances because final on a array is only finalizing the size of the array. You could modify the array using java-code what is error prone.
> # java.util.List
> They are impractical because a List might contain the same instance multiple times what allowes a unexpected ambiguity. Since the CDI-Container is the only authority who creates the instances, we can eliminate this unexpected ambiguity.
> # javax.swing.TreeNode
> Its not part of the core-jdk, it might require Compact-Profiles.
> By the way: Latter a Springs Ordered-pendant is requested to order the set-elements, but using org.ietf.jgss.Oid instead of a number.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)