Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Thu, 13 Oct 2016 06:40:21 +0000 (UTC)
From: "Carsten Ziegeler (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: <JIRA.12929584.1452629334000.813809.1476340821347@Atlassian.JIRA>
In-Reply-To: <JIRA.12929584.1452629334000@Atlassian.JIRA>
References: <JIRA.12929584.1452629334000@Atlassian.JIRA> <JIRA.12929584.1452629334469@arcas>
Subject: [jira] [Closed] (FELIX-5166) WrappedResource does not handle
 namespace correctly
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 13 Oct 2016 06:40:23 -0000


     [ https://issues.apache.org/jira/browse/FELIX-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carsten Ziegeler closed FELIX-5166.
-----------------------------------

> WrappedResource does not handle namespace correctly
> ---------------------------------------------------
>
>                 Key: FELIX-5166
>                 URL: https://issues.apache.org/jira/browse/FELIX-5166
>             Project: Felix
>          Issue Type: Bug
>          Components: Resolver
>    Affects Versions: resolver-1.8.0
>            Reporter: Thomas Watson
>            Assignee: Thomas Watson
>             Fix For: resolver-1.10.0
>
>         Attachments: FELIX-5166.patch
>
>
> This is similar to FELIX-4727.  There are several issues with how namespace is handled in getCapabilities and getRequirements for the org.apache.felix.resolver.WrappedResource class
> In getCapabilities the namespace is correctly used to ask the host and fragment resources for the named capabilities.  But then that list is saved into the m_cachedCapabilities field.  If you first ask for the 'foo' namespace it will save all the 'foo' capabilities to m_cachedCapabilities, then if you ask for the 'bar' capabilities it will simply return the m_cachedCapabilities from before with 'foo' capabilities.
> In getRequirements the namespace is completely ignored.  I think there are several reasons to stop lazily crating these caches.  It leads to strange bugs like the ones above, but also there is no synchronization here and the var is not volatile so I think there could be some issues with multi-threading.  Now that the resolver is multi-threaded I think we should stop creating these lists of capabilities and requirements lazily.  Instead I think we should make them final and create them in the constructor. 


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