[JBoss OSGi Development] - Remaining resolver issues
I have now removed the dependencies on the Resolver API and use PackageAdmin instead. Have a look at AbstractImportExportTest. There are currently three variations of this test case.
The goal would be to remove all external resolver implementations and have none installed in the MC Framework. This however is currently not possible because of some non-trivial issues that are fixed by the Resolver approach.
The most important one is covered by
| exports A, B
| imports A
| exports A,
| imports A, B
This only resolves when BundleC resolves using a self import for package A.
If the MC resolver could actually reason over the full set of installed modules, the choice where it gets package A from would be arbitrary. Currently it however works such that it irrevocably uses the first match and cannot try another attempt if resolution is not sucessful.
| Tests in error:
The following list defines the preferences, if multiple choices are possible,
in order of decreasing priority:
â¢ A resolved exporter must be preferred over an unresolved exporter.
â¢ An exporter with a higher version is preferred over an exporter with a lower version.
â¢ An exporter with a lower bundle ID is preferred over a bundle with a higher ID.
There is test coverage for this, which also fails with NoExternalResolver.
A related issue is this code in PackageAdminImpl
| int resolved = 1;
| while (resolved > 0)
| resolved = 0;
| Iterator<OSGiBundleState> it = resolvableBundles.iterator();
| while (it.hasNext())
| OSGiBundleState bundleState = it.next();
| if (bundleManager.resolveBundle(bundleState, false))
It iteratively tries to resolve the bundles through the MainDeployer by moving them to stage CLASSLOADER one by one. What's missing is an API that allows PackageAdmin to resolve the given bundles all at once.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267110#4267110
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267110