Hi Glyn, The existing service/service-provider model has been used in various SE components for loading available providers from JARs in the installed optional packages and classpath. Since JSR 277 will define a set of repositories that allow multiple versions of modules to coexist and these modules may define services and/or service-providers, what the strawman describes is basically how JSR 277 will fit into this existing service/service-provider model and provide support for it.
While I agreed with you that enhancing the existing service/service-provider model is desirable (like #1 and #2 you pointed out), it is outside the scope of JSR 277 (i.e. JSR 277 is not chartered to change the service/service-provider model.) Therefore, I suggest we should focus our discussion on issues around how to support the existing service/service-provider model. #3 you mentioned is somewhat related to another topic I would like to bring up, and I will start the discussion in another thread. For #4, it is unclear to me what the issues are, could you elaborate? Thanks, - Stanley Glyn Normington wrote:
I am very concerned that the scope of JSR 277 is being expanded considerably without much attention being paid to the state of the art (particularly Spring-OSGi and Declarative Services). If we could implement good interoperation with JSR 291, we could delegate the complexities of supporting services to JSR 291 and technologies like Spring-OSGi that layer nicely on top of JSR 291. Apart from that, the support for services in the strawman has some obvious holes, so I don't think it is ready to be incorporated into the JSR 277 specification: 1. It seems to be lacking any form of dependency injection. 2. The namespace of services is global, but not partitioned by service interface version. The effect of this is that a module could import v1 of a service interface class and obtain an instance of the service that implements v2 of the service interface and get a class cast exception. 3. There is no support for dynamic updates of service providers and notification of service updates to service consumers. (This is consistent with JSR 277's static nature, but I point it out as this is an obvious future requirement based on our experience in OSGi.) 4. There seems to be some confusion in the strawman between loading of service interfaces/implementations and construction and publication of service instances. I wonder what other Expert Group members think of this strawman. Silence does not necessarily indicate happiness, so it would be good to have more feedback. Glyn
