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

Pierre De Rop commented on FELIX-4426:
--------------------------------------

Good point, Marcel;

When using a concurrent hashmap, the iterators returned by the map are indeed 
"weakly consistent", meaning that when traversing the elements, you may or may 
not see any concurrent updates made on the map. And, in the case you want to 
inspect the currently available injected services (and their corresponding 
service properties), then you should iterate on the entry set, and not on the 
key set, like this:

{code}
class MyComponent {
    final Map<MyService, Dictionary> services = new ConcurrentHashMap<>();

    void iterateOnAvailableServices() {
          // May or May not see some services added dynamically, or may see a 
service which has just been removed
          for (Map.Entry<MyService, Dictionary> entry : 
this.services.entrySet()) {
              MyService currentService = entry.getKey();
              Dictionary currentServiceProperties = entry.getValue();
              // ...
          }
     }
}
{code}

This is probably what should be documented ?

However ... I'm starting to wonder if this is a good idea to inject the tuple 
of [Service/Properties] in a map ?
May be this is overkill, and as you said, when needing to get access to the 
service properties, you can just define a callback ...

Or alternatively, what can be easily done is to support an 
Iterable<ServiceReference>, and you can then interate on the set, and see the 
service references, and possibly lookup the actual service using the bundle 
context API ?

Something like

{code}
class MyComponent {
    final Iterable<ServiceReference> refs = new CopyOnWriteArrayList<>(); // or 
ConcurrentLinkedQueue which would be faster if many services are injected

    void iterateOnAvailableServices() {
        for (ServiceReference ref : refs) {
            // inspect service properties, and possibly lookup corresponding 
service instance, which could possibly be not available
            // at the time you lookup it using bundleContext.getService(ref);
        }
     }
{code}

What do you think ?

(I can just uncommit the feature which injects the tuble of service/properties 
in a map,  just let me know ?)


> Allow DM to manage collections of services
> ------------------------------------------
>
>                 Key: FELIX-4426
>                 URL: https://issues.apache.org/jira/browse/FELIX-4426
>             Project: Felix
>          Issue Type: New Feature
>          Components: Dependency Manager
>    Affects Versions: dependencymanager-4.0.0
>            Reporter: J.W. Janssen
>            Assignee: Pierre De Rop
>             Fix For: dependencymanager-4.0.0
>
>
> DM has great support for single-cardinality dependencies, allowing you to 
> only declare the dependency as (volatile) field. For multiple-cardinality 
> dependencies, no such support is present, forcing you to always manually 
> implement this using callbacks.
> It would be great if I could declare multiple-cardinality dependencies like:
> {code}
> private volatile List<MyService> m_services;
> {code}
> and let DM manage the list for me.
> Note that you need some additional reflection mojo to obtain the actual 
> collection type. An example of how this can work can be found in a utility 
> class for Swagger in the Amdatu-Web project, see 
> https://bitbucket.org/amdatu/amdatu-web/src/master/org.amdatu.web.rest/src/org/amdatu/web/rest/doc/swagger/SwaggerUtil.java?at=master#cl-304



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to