Interface ResolverHook

OSGi Framework Resolver Hook instances are obtained from the OSGi Framework Resolver Hook Factory service.

A Resolver Hook instance is called by the framework during a resolve process. A resolver hook may influence the outcome of a resolve process by removing entries from shrinkable collections that are passed to the hook during a resolve process. A shrinkable collection is a Collection that supports all remove operations. Any other attempts to modify a shrinkable collection will result in an UnsupportedOperationException being thrown.

The following steps outline the way a framework uses the resolver hooks during a resolve process.

1. Collect a snapshot of registered resolver hook factories that will be called during the current resolve process. Any hook factories registered after the snapshot is taken must not be called during the current resolve process. A resolver hook factory contained in the snapshot may become unregistered during the resolve process. The framework should handle this and stop calling the resolver hook instance provided by the unregistered hook factory and the current resolve process must fail. If possible, an exception must be thrown to the caller of the API which triggered the resolve process. In cases where the the caller is not available a framework event of type error should be fired.
2. For each registered hook factory call the ResolverHookFactory.begin(Collection) method to inform the hooks about a resolve process beginning and to obtain a Resolver Hook instance that will be used for the duration of the resolve process.
3. Determine the collection of unresolved bundle revisions that may be considered for resolution during the current resolution process and place each of the bundle revisions in a shrinkable collection Resolvable. For each resolver hook call the filterResolvable(Collection) method with the shrinkable collection Resolvable.
4. The shrinkable collection Resolvable now contains all the unresolved bundle revisions that may end up as resolved at the end of the current resolve process. Any other bundle revisions that got removed from the shrinkable collection Resolvable must not end up as resolved at the end of the current resolve process.
5. For each bundle revision B left in the shrinkable collection Resolvable and any bundle revision B which is currently resolved that represents a singleton bundle do the following:
   • Determine the collection of available capabilities that have a namespace of osgi.identity, are singletons, and have the same symbolic name as the singleton bundle revision B and place each of the matching capabilities into a shrinkable collection Collisions.
   • Remove the osgi.identity capability provided by bundle revision B from shrinkable collection Collisions. A singleton bundle cannot collide with itself.
   • For each resolver hook call the filterSingletonCollisions(BundleCapability, Collection) with the osgi.identity capability provided by bundle revision B and the shrinkable collection Collisions
   • The shrinkable collection Collisions now contains all singleton osgi.identity capabilities that can influence the ability of bundle revision B to resolve.
   • If the bundle revision B is already resolved then any resolvable bundle revision contained in the collection Collisions is not allowed to resolve.
6. During a resolve process a framework is free to attempt to resolve any or all bundles contained in shrinkable collection Resolvable. For each bundle revision B left in the shrinkable collection Resolvable which the framework attempts to resolve the following steps must be followed:
   • For each requirement R specified by bundle revision B determine the collection of capabilities that satisfy (or match) the requirement and place each matching capability into a shrinkable collection Candidates. A capability is considered to match a particular requirement if its attributes satisfy a specified requirement and the requirer bundle has permission to access the capability.
   • For each resolver hook call the filterMatches(BundleRequirement, Collection) with the requirement R and the shrinkable collection Candidates.
   • The shrinkable collection Candidates now contains all the capabilities that may be used to satisfy the requirement R. Any other capabilities that got removed from the shrinkable collection Candidates must not be used to satisfy requirement R.
7. For each resolver hook call the end() method to inform the hooks about a resolve process ending.

In all cases, the order in which the resolver hooks are called is the reverse compareTo ordering of their Service References. That is, the service with the highest ranking number must be called first. In cases where a shrinkable collection becomes empty the framework is required to call the remaining registered hooks.

Resolver hooks are low level. Implementations of the resolver hook must be careful not to create an unresolvable state which is very hard for a developer or a provisioner to diagnose. Resolver hooks also must not be allowed to start another synchronous resolve process (e.g. by calling Bundle.start() or FrameworkWiring.resolveBundles(Collection) ). The framework must detect this and throw an IllegalStateException.