Strawman: Services and service-providers support

[Stanley M. Ho]

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