[jira] [Commented] (ARIES-2027) CDI of java.util.Set and order of org.ietf.jgss.Oid

["Romain Manni-Bucau (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ARIES-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244462#comment-17244462 ] 

Romain Manni-Bucau commented on ARIES-2027:
-------------------------------------------

Why we shouldnt allow it? Because it is forbidden by CDI spec (more exactly collection type injection is the bean type and while you dont produce it it does not exist).

CDI has Instance support though which would look like this or programmatic lookup of beans using Instance or BeanManager so it already exists, you just checked the wrong API I think. Osgi cdi has BeanServiceObjects too.

In other words, I would be to enhance dynamic service support rather than misusing types regarding cdi spec.

 

Did you try official api?

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