Package org.osgi.framework.hooks.resolver

Interface ResolverHook

  • @ConsumerType
public 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 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.

    See Also:
    ResolverHookFactory

    • Method Detail

      • filterResolvable

        void filterResolvable​(java.util.Collection<BundleRevision> candidates)
        Filter resolvable candidates hook method. This method may be called multiple times during a single resolve process. This method can filter the collection of candidates by removing potential candidates. Removing a candidate will prevent the candidate from resolving during the current resolve process.
        Parameters:
        candidates - the collection of resolvable candidates available during a resolve process.

      • filterSingletonCollisions

        void filterSingletonCollisions​(BundleCapability singleton,
                               java.util.Collection<BundleCapability> collisionCandidates)
        Filter singleton collisions hook method. This method is called during the resolve process for the specified singleton. The specified singleton represents a singleton capability and the specified collection represent a collection of singleton capabilities which are considered collision candidates. The singleton capability and the collection of collision candidates must all use the same namespace.

        Currently only capabilities with the namespace of osgi.wiring.bundle and osgi.identity can be singletons. The collision candidates will all have the same namespace, be singletons, and have the same symbolic name as the specified singleton capability.

        In the future, capabilities in other namespaces may support the singleton concept. Hook implementations should be prepared to receive calls to this method for capabilities in namespaces other than osgi.wiring.bundle or osgi.identity.

        This method can filter the list of collision candidates by removing potential collisions. Removing a collision candidate will allow the specified singleton to resolve regardless of the resolution state of the removed collision candidate.

        Parameters:
        singleton - the singleton involved in a resolve process
        collisionCandidates - a collection of singleton collision candidates

      • filterMatches

        void filterMatches​(BundleRequirement requirement,
                   java.util.Collection<BundleCapability> candidates)
        Filter matches hook method. This method is called during the resolve process for the specified requirement. The collection of candidates match the specified requirement. This method can filter the collection of matching candidates by removing candidates from the collection. Removing a candidate will prevent the resolve process from choosing the removed candidate to satisfy the requirement.

        All of the candidates will have the same namespace and will match the specified requirement.

        If the Java Runtime Environment supports permissions then the collection of candidates will only contain candidates for which the requirer has permission to access.

        Parameters:
        requirement - the requirement to filter candidates for
        candidates - a collection of candidates that match the requirement

      • end

        void end()
        This method is called once at the end of the resolve process. After the end method is called the resolve process has ended. The framework must not hold onto this resolver hook instance after end has been called.