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
