Service providers

[Richard S. Hall]

Hey Stanley,

Stanley M. Ho wrote:
> Richard S. Hall wrote:
>> Hello Stanley,
>> ...
>> I guess the addition of service-related concepts into the module layer
>> would be one example of feature creep for me. While I think it makes
>> perfect sense to figure out how the Service Loader stuff will work on
>> top of the module layer, pushing Service Loader concepts down into the
>> module layer doesn't make any sense to me at all.
>>
>> It should be sufficient for the Service Loader to probe the installed
>> modules and perhaps examine module metadata to determine if a module
>> provides a service or not. From there, the Service Loader can create
>> module instances and provider instances as necessary.
>>
>> If this is not possible in our current constructs, then we should
>> address these shortcomings rather than adding higher layer concepts into
>> the module layer.
>>
>> -> richard
>
> The current service provider strawman suggests a few changes in
> ModuleDefinition/Query classes, and you basically suggest that these
> changes could be eliminated if we have a more generic way to express
> services and service-providers in the module metadata and a generic way
> to examine the information from the module metadata, all without
> service-related APIs in the module layer.
>
> I think what you suggested makes sense, and I will look into this.

To me, this sounds like what we call the "extender model" for the OSGi
framework. The way it works is that bundles that want to participate in
certain scenarios simply include some metadata inside of themselves,
then some infrastructure can probe for this metadata and automatically
do work on their behalf. This is how Declarative Services works in the
R4 spec and also how Spring-OSGi works...it is becoming a very common model.

The benefit of this approach is that it doesn't push upper layer
concepts down into the modularity layer and keeps it simple. Off the top
of my head, I don't see a reason why the Service Loader couldn't use a
similar approach.

-> richard