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] [Closed] (FELIX-4727) WrappedResource.getCapabilities ignores the namespace param
Date Mon, 15 Dec 2014 14:18:13 GMT

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

Thomas Watson closed FELIX-4727.

Thanks.  Closing.

> WrappedResource.getCapabilities ignores the namespace param
> -----------------------------------------------------------
>                 Key: FELIX-4727
>                 URL: https://issues.apache.org/jira/browse/FELIX-4727
>             Project: Felix
>          Issue Type: Bug
>          Components: Resolver
>         Environment: All
>            Reporter: Thomas Watson
>            Assignee: Richard S. Hall
>             Fix For: resolver-1.2.0
>         Attachments: Felix-4737.patch
> The overall design of org.apache.felix.resolver.WrappedResource is that it is an internal
type to the ResolverImpl and is not exposed to external code.  The fact that it does not pay
attention to the namespace param is an oversite, but not one that effects the ResolverImpl
since it uses a null param anyway and does its own filtering of the capabilities.
> But there are cases where this type will get exposed to code outside the resolver implementation.
 One example is when ResolverImpl.mergeUses is called and does a ArrayList.contains.  Typically
the types in the list are provided by the ResolveContext implementation.  If a WrappedCapability
is passed to the ArrayList.contains method then it does an equals call across all values in
the list.  If a ResolveContext capability implementation of that equals method calls getResource
on  WrappedCapability then it will be exposed to the WrappedResource.  I know of one case
where this causes issues when the client code is trying to get the osgi.identity capability
of the WrappedResource.  All capabilities are being returned but the first one is not the
expected osgi.identity.
> Here is a stacktrace from Aries:
> Caused by: java.lang.NullPointerException
> 	at org.apache.aries.subsystem.obr.internal.FelixResourceAdapter.equals(FelixResourceAdapter.java:44)
> 	at java.util.ArrayList.indexOf(ArrayList.java:319)
> 	at java.util.ArrayList.contains(ArrayList.java:302)
> 	at org.apache.felix.resolver.ResolverImpl.mergeUses(ResolverImpl.java:955)
> 	at org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:767)
> 	at org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:715)
> 	at org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:715)
> 	at org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:715)
> 	at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:249)
> 	at org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:410)
> 	at org.apache.aries.subsystem.core.internal.SubsystemResource.computeDependencies(SubsystemResource.java:393)
> 	at org.apache.aries.subsystem.core.internal.SubsystemResource.<init>(SubsystemResource.java:101)
> 	at org.apache.aries.subsystem.core.internal.SubsystemResource.<init>(SubsystemResource.java:92)
> 	at org.apache.aries.subsystem.core.internal.InstallAction.createSubsystemResource(InstallAction.java:128)
> 	at org.apache.aries.subsystem.core.internal.InstallAction.run(InstallAction.java:62)

This message was sent by Atlassian JIRA

View raw message