[
https://issues.apache.org/jira/browse/FELIX-5131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15092618#comment-15092618
]
Thomas Watson commented on FELIX-5131:
--------------------------------------
I think we should implement as many of the List operations as feasible. I
don't really like the idea of implementing RandomAccess to avoid certain
algorithms from using a list iterator. But I do agree that CopyOnWriteList is
in fact a random access list so I don't see any harm in adding it to the
implements of CopyOnWriteList.
The issue is the CopyOnWriteList object is exposed when calling out to
ResolveContext.insertHostedCapability. The javadoc for that OSGi method does
not state any limitations on the operations that can be supported on that
object. But I am pretty sure any resolver implementation is going to fail
badly if the method does not result in adding/inserting the specified
HostedCapability into the specified List. For example, removing anything from
the list is a good way to bust the resolver impl.
As a result I think we should at least implement all the add methods as well as
a ListIterator that supports add and set operations.
> UnsupportedOperationException when embedding felix in WebSphere
> ---------------------------------------------------------------
>
> Key: FELIX-5131
> URL: https://issues.apache.org/jira/browse/FELIX-5131
> Project: Felix
> Issue Type: Bug
> Components: Framework, Resolver
> Affects Versions: framework-5.2.0, resolver-1.6.0
> Reporter: Thomas Schurins
>
> Hello, we are embedding the OSGi framework in our application (creating the
> framework , managing its export packages, contolling the bundles &c.). This
> works great in a lot of enviroments, but not on WebSphere (using the IBM
> JDK):
> {noformat}
> java.lang.UnsupportedOperationException
> at
> org.apache.felix.resolver.util.CopyOnWriteList.listIterator(CopyOnWriteList.java:218)
> at java.util.Collections.binarySearch(Collections.java:1551)
> at
> org.apache.felix.framework.ResolveContextImpl.insertHostedCapability(ResolveContextImpl.java:103)
> at org.apache.felix.resolver.Candidates.prepare(Candidates.java:934)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:233)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:159)
> at
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:431)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4109)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2111)
> at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1365)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
> at java.lang.Thread.run(Thread.java:790)
> {noformat}
> The problem seems to be that in the IBM JDK, the Collections.binarySearch
> method directly uses the listIterator of the list if it is not a RandomAccess
> list (while the oracle JDK doesn't).
> A solution it to add the interface RandomAccess to the CopyOnWriteList class.
> I've tested this locally and eveything runs fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
