You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Thomas Watson (JIRA)" <ji...@apache.org> on 2016/11/01 00:30:58 UTC
[jira] [Commented] (FELIX-5389) NullPointerException in
Candidates#prepare() method
[ https://issues.apache.org/jira/browse/FELIX-5389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15623901#comment-15623901 ]
Thomas Watson commented on FELIX-5389:
--------------------------------------
I have found an issue with fragment that have multiple hosts. I think the issue only manifests when there are three or more hosts and there is a cycle between the host and fragment. I have not found a solution yet. The problem appears to be related to the shared candidate list held by each hosted fragment. Manipulation of the candidate list is effecting multiple CandidateSelecters when it should not. This causes an inconsistentcy the leads the various NPEs or other runtime erres. I don't thik the extra host capability on the fragment is causing the problem.
> NullPointerException in Candidates#prepare() method
> ---------------------------------------------------
>
> Key: FELIX-5389
> URL: https://issues.apache.org/jira/browse/FELIX-5389
> Project: Felix
> Issue Type: Bug
> Components: Resolver
> Affects Versions: resolver-1.10.0
> Reporter: matteo rulli
>
> Project where the errors appear: https://github.com/mrulli/com.flairbit.eclipsecon.onesix
> ----
> During the resolution of my bundles I get the following stacktrace (to trigger the resolution, just do {{mvn install}} from the {{example.cassandra.itest.bndrun}} folder in the project above):
> {code}
> [ERROR] Failed to execute goal biz.aQute.bnd:bnd-export-maven-plugin:3.4.0-SNAPSHOT:export (default) on project example.cassandra.bndrun: null: MojoExecutionException: NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal biz.aQute.bnd:bnd-export-maven-plugin:3.4.0-SNAPSHOT:export (default) on project example.cassandra.bndrun: null
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException
> at aQute.bnd.maven.export.plugin.ExportMojo.execute(ExportMojo.java:52)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at org.apache.felix.resolver.Candidates.prepare(Candidates.java:946)
> at org.apache.felix.resolver.ResolverImpl.getInitialCandidates(ResolverImpl.java:502)
> at org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:387)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:375)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:329)
> at biz.aQute.resolve.BndResolver.resolve(BndResolver.java:29)
> at biz.aQute.resolve.ResolveProcess.resolveRequired(ResolveProcess.java:75)
> at biz.aQute.resolve.ProjectResolver.resolve(ProjectResolver.java:109)
> at biz.aQute.resolve.ProjectResolver.getRunBundles(ProjectResolver.java:126)
> at aQute.bnd.maven.export.plugin.ExportMojo.resolve(ExportMojo.java:86)
> at aQute.bnd.maven.export.plugin.ExportMojo.export(ExportMojo.java:70)
> at aQute.bnd.maven.export.plugin.ExportMojo.execute(ExportMojo.java:49)
> ... 21 more
> {code}
> I tried to investigate a little bit this and I found that the NPE is generated in the {{prepare()}} method - {{org.apache.felix.resolver.Candidates}} class, within the following snippet:
> {code}
> m_candidateMap.put(r, cands.copy());
> for (Capability cand : cands.getRemainingCandidates())
> {
> Set<Requirement> dependents = m_dependentMap.get(cand);
> dependents.remove(origReq);
> dependents.add(r);
> }
> {code}
> {{org.apache.felix.resolver.Candidates.m_dependentMap.get}} is invoked with key
> {code}
> WrappedCapability: '[slf4j.api version=1.6.1] osgi.wiring.package; org.slf4j.impl'
> m_cap: Provide[osgi.wiring.package]{version=1.6.1, osgi.wiring.package=org.slf4j.impl}{}
> m_host: slf4j.api version=1.6.1
> {code}
> and this nullifies {{dependents}} var. The only WrappedCapabilities within the m_dependentMap key set are the followings:
> {code}
> [slf4j.api version=1.7.7] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j)(version>=1.6.1))
> [slf4j.api version=1.7.5] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j.spi)(version>=1.6.1))
> [slf4j.api version=1.7.5] osgi.wiring.package; (&(osgi.wiring.package=org.apache.log4j))
> [slf4j.api version=1.6.1] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j.impl)(version>=1.6.0))
> [slf4j.api version=1.7.5] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j.helpers)(version>=1.6.1))
> [slf4j.api version=1.7.7] osgi.wiring.package; (&(osgi.wiring.package=org.apache.log4j))
> [slf4j.api version=1.7.7] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j.helpers)(version>=1.6.1))
> [slf4j.api version=1.7.5] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j.impl)(version>=1.6.0))
> [slf4j.api version=1.7.7] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j.spi)(version>=1.6.1))
> [slf4j.api version=1.7.7] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j.impl)(version>=1.6.0))
> [slf4j.api version=1.7.5] osgi.wiring.package; (&(osgi.wiring.package=org.slf4j)(version>=1.6.1))
> {code}
> and none of them match the specified key above, at least as long as the WrappedCapability equals method is concerned.
> In my opinion a meaningful error should be thrown by the resolver instead of throwing NullPointerException. Or maybe it is just enough to skip actions on dependents in case null value is returned?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)