[
https://issues.apache.org/jira/browse/FELIX-5389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15625824#comment-15625824
]
Thomas Watson commented on FELIX-5389:
--------------------------------------
I have found an issue with fragments and have a fix and test in
https://github.com/tjwatson/felix/tree/FELIX-5389
The error I see is an out of bounds exception when calling ShadowList.replace
method and not the NPEs reported here. That makes me worry that this is not
the same issue. I'm currently trying to figure out how to test the bnd maven
plugin with my patched resolver.
> 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)
