Hi Stanley "Stanley M. Ho" <[EMAIL PROTECTED]> wrote on 14/06/2007 05:53:58 PM:
> 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. Fine. > > #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? Maybe it's just a matter of presentation in the strawman, but it confused me somewhat and the net effect was that I wasn't sure what pieces JSR 277 will be providing and what pieces are upgrades of existing facilities (since I'm not familiar with the existing service/service-provider model) to take advantage of JSR 277. 1. The opening paragraph of the Background section defines a service as "a well-known set of interfaces and (usually abstract) classes" - no mention of instances, 2. The third paragraph of the same section say "a service is represented by a single type ...". Again no mention of instances. 3. The requirements section talks about the module system making services available to the Java platform. This is using 'service' in the above sense, but I'm not sure what it means to make an interface "available to the Java platform" unless it means "available for modules to import". 4. Section 6 talks about an application module importing a service module if and only if there is at least one suitable service provider. I guess the rationale is to make the application module fail to resolve if it hasn't a (current) hope of obtaining the service it needs. But from my perspective this is odd. The service provider could be available without it being possible to obtain a service instance, which is the thing the application really needs. So rather than being an import-time check, the availability of critical services should be checked when the application module starts (for static applications that don't need to react dynamically to services coming online, that is). Glyn > > 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 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
