felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Watson (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FELIX-5166) WrappedResource does not handle namespace correctly
Date Tue, 12 Jan 2016 20:16:39 GMT

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

Thomas Watson updated FELIX-5166:
    Attachment: FELIX-5166.patch

Possible fix

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

View raw message