[
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)
