felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre De Rop (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-4426) Allow DM to manage collections of services
Date Fri, 10 Oct 2014 18:01:33 GMT

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

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();
              // ...

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

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

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

View raw message