[
https://issues.apache.org/jira/browse/FELIX-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290132#comment-13290132
]
Thomas Watson commented on FELIX-3522:
--------------------------------------
I have tried to reproduce the ResolutionException using the bundle meta-data
outlined in the testcase with my own ResolverContext implementation and I don't
see how to reproduce it. I think Richard's comment about ResolverContext
returning package capabilities which have been substituted with a package
requirement wire is key. My ResolveContext neglected to filter out substituted
package capabilities, but in my case I always sorted the "api" bundle's
capability first since it was the first bundle installed (with the lowest
bundle id) and the javax.servlet package is exported at the same version from
the two bundles involved in the testcase.
But even when I forced the sort order to reverse the capabilities (so the
substituted one came first) I could not reproduce the ResolutionException you
mention in this issue report. Instead I ran into an interesting issue in the
resolver where it does not detect a class space consistency correctly and
allows a wire to be formed to the substituted export. This is because the
resolver implementation looks for the "root" sources for a package capability,
but in this case it finds none, because the export should have been
substituted. The end result is that we have an empty set of sources X which is
compared to another set of one source Y and the check for consistency just sees
if (X.isSubset(Y) || Y.isSubset(X)) and obviously an empty set is a subset of
all other sets so the check passes. This is not necessarily a resolver bug
since the resolver was given invalid input from ResolveContext.findProviders.
But we should probably check the spec to see if it makes it clear that the
resolve context must filter substituted package exports in
ResolveContext.findProviders. It certainly slipped my mind when I implemented
my ResolveContext.
None of this really explains why Thomas D. is seeing this issue. Thomas would
you have a chance to debug this and help shed some light on the issue?
> Regression related to uses clause with multiple package providers
> -----------------------------------------------------------------
>
> Key: FELIX-3522
> URL: https://issues.apache.org/jira/browse/FELIX-3522
> Project: Felix
> Issue Type: Bug
> Components: Resolver
> Reporter: Thomas Diesler
> Attachments: test.log
>
>
> For this test
> https://github.com/tdiesler/jbosgi-resolver/blob/3.0/felix/src/test/java/org/jboss/test/osgi/resolver/UsesDirectiveResolverTest.java
> I get
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.116 sec <<<
> FAILURE!
> testMultipleProviders(org.jboss.test.osgi.resolver.UsesDirectiveResolverTest)
> Time elapsed: 0.096 sec <<< ERROR!
> org.osgi.service.resolver.ResolutionException: Uses constraint violation.
> Unable to resolve resource war.extender.jar
> [AbstractResource[war.extender.jar:0.0.0]] because it is exposed to package
> 'javax.servlet' from resources javax.servlet.api
> [AbstractResource[javax.servlet.api:0.0.0]] and http.service.provider
> [AbstractResource[http.service.provider:0.0.0]] via two dependency chains.
> Chain 1:
> war.extender.jar [AbstractResource[war.extender.jar:0.0.0]]
> import: null
> |
> export: osgi.wiring.package=javax.servlet
> javax.servlet.api [AbstractResource[javax.servlet.api:0.0.0]]
> Chain 2:
> war.extender.jar [AbstractResource[war.extender.jar:0.0.0]]
> import: null
> |
> export: osgi.wiring.package=org.ops4j.pax.web.service; uses:=javax.servlet
> export: osgi.wiring.package=javax.servlet
> http.service.provider [AbstractResource[http.service.provider:0.0.0]]
> at
> org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1134)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
> at
> org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:57)
> at
> org.jboss.test.osgi.resolver.UsesDirectiveResolverTest.testMultipleProviders(UsesDirectiveResolverTest.java:158)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
