Return-Path: X-Original-To: apmail-felix-dev-archive@www.apache.org Delivered-To: apmail-felix-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0ADFD17B88 for ; Fri, 10 Oct 2014 12:32:34 +0000 (UTC) Received: (qmail 99545 invoked by uid 500); 10 Oct 2014 12:32:33 -0000 Delivered-To: apmail-felix-dev-archive@felix.apache.org Received: (qmail 99465 invoked by uid 500); 10 Oct 2014 12:32:33 -0000 Mailing-List: contact dev-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@felix.apache.org Delivered-To: mailing list dev@felix.apache.org Received: (qmail 99447 invoked by uid 99); 10 Oct 2014 12:32:33 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Oct 2014 12:32:33 +0000 Date: Fri, 10 Oct 2014 12:32:33 +0000 (UTC) From: "Marcel Offermans (JIRA)" To: dev@felix.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (FELIX-4426) Allow DM to manage collections of services MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/FELIX-4426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14166720#comment-14166720 ] Marcel Offermans commented on FELIX-4426: ----------------------------------------- I'm not sure if it will affect us, but the contract for a ConcurrentHashMap is rather vague when it comes to iterating over the collection while updating it: Yes, the good news is that it will not throw an exception. No, it is not guaranteed that you will see updates in the iterator. The iterator reflects "the state of the hash table at some point at or since the creation of the iterator/enumeration". Will this be a problem? It depends. There is no "CopyOnWriteHashMap" which would have a more determinate behaviour (namely guaranteeing that your collection and therefore the iterator won't change after you've got hold of a reference) but at the cost of more expensive modifications. We should think this through, though, to advise our users when to use this, and when not to (you can always use callbacks and a list implementation of choice if you need more control). > 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 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)