Resolving and services <was> Re: ServiceLoader.load* take 2

[Paul Sandoz]

Hi Tim,

Many thanks for the hints, it got me thinking about this more :-)


On Jun 18, 2012, at 9:06 PM, Tim Diekmann wrote:

> This kind of problem looks very familiar.
> 
> Has anyone taken a look at the OSGi Resolver lately? It has a solution for
> the resolution of resources with capabilities and requirements and the
> latest OSGi Spec R5 has made that a separate service.
> 

Do you mean look at an implementation of the Resolver Hook Service?

The OSGI core R5 spec is deliberately vague on resolving, specifying constraints, but not restricting the potential solutions that implementations may produce.
   
I looked at bit at section 6 "Resource API Specification" and there are indeed similarities between a requirement (a consumer of a service [*]) and a capability (a provider of a service), although i don't know enough about OSGi to ascertain if the requirements and capabilities can support an equivalent of JDK services.

In terms of resolving it is not specified when such resolution of requirements be performed [1].

It's hard to say when the JSR spins up what will be specified for resolution but i suspect it will walk a fine line as has the OSGI spec to not unduly handcuff implementations.

In this regard when Jigsaw services are resolved is potentially an implementation detail of the resolver. I can see advantages to why it may be useful specify that service dependencies are resolved after all other dependencies are resolved, but can also see why this may unduly restrict implementations.

Paul.

[*] Service in the sense of JDK service using ServiceLoader, not to be confused with the OSGi service layer.

[1] Section 6.4.2 Resolution

Requirements can be optional or mandatory, as specified in the resolution directive, which is only available on the Requirement. Optional Requirements do not have to be satisfied by the Resolver. Environments can be eager or relaxed in finding Resources to resolve optional Requirements. All mandatory Requirements of a Resource must be satisfied before that Resource’s Capabilities can be provided to the Environment.

The syntax of the resolution directive is therefore:

   resolution ::= ’optional’ | ’mandatory’

The default is mandatory. 




> Just a thought, trying to prevent the wheel being re-invented.
> 
>  Tim.
> 
> 
> 
> 
> 
> On 6/18/12 5:00 AM, "Paul Sandoz" <paul.sandoz at oracle.com> wrote:
> 
>> On Jun 12, 2012, at 5:03 PM, Paul Sandoz wrote:
>>> - Modify the resolver so that the permits clause does not affect
>>> resolution of a service provider module (and it's dependencies). This
>>> area is tricky. Rather than choices of service provider module optional
>>> dependencies being pushed on to the choice stack of each service
>>> consumer module this potentially could be done once per service
>>> interface (although will likely change what solutions are produced), but
>>> might be very tricky to implement given that service provider modules
>>> may also be service consumer modules. Good diagnostics are required to
>>> help track down why a service provider module is not being resolved.
>> 
>> Here is my latest thoughts on this:
>> 
>> 1) maintain a separate stack of Choice for service provider modules. When
>> the resolver comes across a service consume module add Choice instances
>> to that stack for all known corresponding service provider modules.
>> 
>> 2) when the main choice stack is null and is about to return true move
>> all the choices on the service stack to the current stack and keep on
>> processing.
>> 
>> To be experimented with soon...
>> 
>> Paul.
>