You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Pierre De Rop (JIRA)" <ji...@apache.org> on 2019/02/05 18:22:00 UTC

[jira] [Commented] (FELIX-5998) NPE in Resolver checkPackageSpaceConsistency

    [ https://issues.apache.org/jira/browse/FELIX-5998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16761080#comment-16761080 ] 

Pierre De Rop commented on FELIX-5998:
--------------------------------------

Hello Thomas,

I came across the same exception again, and I'd like to have your opinion . So this time I have been able to reproduce the problem more easily and I have added some traces in the resolver; so I observed the following scenario:

So, at some point, the ResolverImpl.checkPackageSpaceConsistency is called:
{code:java}
private ResolutionError checkPackageSpaceConsistency(
   ResolveSession session,
   Resource resource,
   Candidates allCandidates,
   boolean dynamic,
   Map<Resource, Packages> resourcePkgMap,
   Map<Resource, Object> resultCache)
{
{code}
And the second "resource" parameter is set to a "com.alcatel.as.utils" resource found from an OBR , using a ResolveContext implementation (notice that the "com.alcatel.as.utils" resource bundle has some fragments).

So sometimes (rarely), the following code in the checkPackageSpaceConsistency method does not find the "com.alcatel.as.utils" resource from the resourcePkgMap map:
{code:java}
Packages pkgs = resourcePkgMap.get(resource);
{code}
So, the above method call returns null, and pkgs is null, this is why I'm having the NPE initally reported in this Jira issue.

Now, I have dumped the following infos about the resource parameter:
{code:java}
resource.toString ()           returns "com.alcatel.as.utils;2.5.1.RELEASE;osgi.bundle"
resource.hashCode()            returns 1244348781
resource.getClass().getNames() returns "org.apache.felix.resolver.WrappedResource"{code}
So, the hascode of the resource parameter is  1244348781. Now, I have dumped content of all the resourcePkgMap keys, for each one I have called the key toString() and key hashcode v methods using this code (when the resource is not found from the resourcePkgMap):
{code:java}
for (Map.Entry<Resource, Packages> entries : resourcePkgMap.entrySet()) {
     System.out.println("hash of " + entries.getKey() + "=" + entries.getKey().hashCode());
}
{code}
And interestingly, I see the the "com.alcatel.as.utils" resource is present, but with a different hashcode, this is why the resource is not found:
{code:java}
hash of com.alcatel.as.utils;2.5.1.RELEASE;osgi.bundle=342519251
{code}
So, we see that the second "resource" parameter has 1244348781, but in the resourcePkgMap, the same resource is present but with another Resource instance, with another 342519251 hashcode. This is why the resource is not found from the resourcePkgMap.

Now, I don't know if the following patch is making sense (or not ?), but I tried to add the following equals/hashcode methods in the WrappedResource.java from the Resolver, and suprisingly, the patch seems to have resolved the issue (I have run a test all night long, without reproducing any NPE):

 
{code:java}
package org.apache.felix.resolver;

import java.util.*;

class WrappedResource implements Resource
{
...
    @Override
    public boolean equals(Object o)
    {
    	if (o instanceof WrappedResource) {
    		return m_host.equals(((WrappedResource) o).m_host);
    	} else if (o instanceof Resource) {
    		return m_host.equals(o);
    	} else {
    		return false;
    	}
    }
    
    @Override
    public int hashCode()
    {
    	return m_host.hashCode();
    }
{code}
So, do you think that adding some equals/hashcode methods in the WrappedResource is making sense (notice the the WrappedCapability class is defining some equals/hashcode methods.; not the WrappedResource class) ?

Otherwise, I would then need to investigate the ResolveContext implementation I'm using ?

thanks for your help.

> NPE in Resolver checkPackageSpaceConsistency
> --------------------------------------------
>
>                 Key: FELIX-5998
>                 URL: https://issues.apache.org/jira/browse/FELIX-5998
>             Project: Felix
>          Issue Type: Task
>          Components: Resolver
>    Affects Versions: resolver-2.0.0
>            Reporter: Pierre De Rop
>            Priority: Major
>
> I'm using a custom ResolveContext implementation that I've written in order to calculate the dependencies of some applications which bundles are all centralized in an OBR. Now, using the Felix framework 6.0.1 (and the Resolver 2.0.0 that is provided by the framework), I sometimes get an NPE in the ResolverImpl.checkPackageSpaceConsistency, line 1319). 
> My OBR is not yet fully "curated" (I still have some " Candidate permutation failed due to a conflict between imports" logs when enabling felix.log.level=4). So I'm cleaning the OBR gradually, but now, sometimes  I see this NPE while resolving :
> {code:java}
> java.lang.NullPointerException
> at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1319)
> at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1500)
> at org.apache.felix.resolver.ResolverImpl.checkConsistency(ResolverImpl.java:622)
> at org.apache.felix.resolver.ResolverImpl.findValidCandidates(ResolverImpl.java:575)
> at org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:438)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:421)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:414)
> at com.nokia.as.microfeatures.bundlerepository.impl.BundleRepositoryImpl.findResolution(BundleRepositoryImpl.java:257)
> {code}
> The bad thing is that I'm not able to reproduce the NPE when I enable felix.log.level=4, and the NPE is difficult to reproduce.
> Could someone please give me a clue about what could produce this NPE ? Are there some traces which could be added in order to figure out what is the problem ? Then is there a fix which should be done in order to avoid this null pointer ?
> If I fully cleanup my OBR, maybe I won't have anymore the NPE, but I just wanted to report it here.
> thank you.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)