[
https://issues.apache.org/jira/browse/FELIX-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15302146#comment-15302146
]
Thomas Watson commented on FELIX-5263:
--------------------------------------
This appears to be a bug in the implementation of ResolveContext that bndtools
uses when resolving stuff. I have not spent the time to run the testcase you
provided in the PR, but you mention that you have duplicate resources provided
to the resolver in the scenario. I assume this means it is resolving these
duplicate resources as either mandatory or optional resources. Such duplicate
resources must not be equal to each other as in Object.equals. The only way
duplicate content can be resolved multiple times by the resolver is if each
Resource representing the "same" content are distinctly different from each
other for Object.equals. Otherwise there is no way the resolver could return
the multiple Map<Resource, List<Wire>> entries representing each Resource that
points to the duplicate content.
Someone familiar with the bndtools code needs to confirm how they implement the
equals method in such a scenario. If they are incorrectly returning true when
they shouldn't then this is going to severely confused the resolver. I had to
fix a similar issue in Aries Subsystems impl ARIES-1554.
> java.lang.ArrayIndexOutOfBoundsException: -1
> --------------------------------------------
>
> Key: FELIX-5263
> URL: https://issues.apache.org/jira/browse/FELIX-5263
> Project: Felix
> Issue Type: Bug
> Components: Resolver
> Reporter: Raymond Augé
>
> In a specific scenario where duplicate resources are provided to the resolver
> it produces the error bellow:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: -1
> at
> org.apache.felix.resolver.util.CopyOnWriteList.set(CopyOnWriteList.java:57)
> at org.apache.felix.resolver.Candidates.prepare(Candidates.java:946)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:232)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:179)
> at
> biz.aQute.resolve.ResolverValidator.resolve(ResolverValidator.java:124)
> at
> biz.aQute.resolve.ResolverValidator.validateResources(ResolverValidator.java:81)
> at
> biz.aQute.resolve.ResolverValidator.validate(ResolverValidator.java:75)
> at
> biz.aQute.resolve.ValidatorTest.testDuplicateIndexAgainstLargeTargetPlatform_whyDoesThisFail(ValidatorTest.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> {code}
> Since the reproduction is complex I've provided one as a unit test in a PR to
> the bnd project. https://github.com/bndtools/bnd/pull/1472
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
