You should keep in mind the different views of the service between the registrant and the consumer. On the registrant (service producing/implementing) side, it is perfectly reasonable for them to register a single service object under all the different service interfaces they implement. But I think Niel's point is on the side of the consumer bundle. I think it is far more simple for them to simply bind to each service (interface) that they require individually instead of trying to find a particular service which implements all the service interfaces they need at once and then casting that single service to the various interfaces it implements. As Neil points out this also couples a client to a particular type of implementation that must use a single service registration for all the service interfaces needed by the client.
Tom |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Tim Diekmann <[email protected]> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |"Equinox development mailing list" <[email protected]> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |11/16/2009 05:46 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Re: [equinox-dev] Registering two services in the same bundle | >--------------------------------------------------------------------------------------------------------------------------------------------------| Neil, one concrete example where the services need to be provided as a unit is the support for JTA (coming in the Enterprise Profile soon). In the JTA case, the provider is mandated to implement 3 services and register them, among them UserTransaction and TransactionManager. Since they come from the JTA spec, they cannot be easily combined. Tim. "In the end everything will be right. But since things are not right, we are not at the end yet!" -- Unknown On Nov 16, 2009, at 3:32 PM, Neil Bartlett wrote: David, While Thomas's suggestion is absolutely correct, I think you need to step back from the problem a little and ask if this is the right approach. If your consumer bundle needs the Interface1 service then it should simply bind to an instance of Interface1. If it also needs the Interface2 service then it should just bind to Interface2. The consumer should not *require* both services to be offered by the same object, because this will severely limit the ability of other producers to offer an alternative implementation for those services. In other words, you are coupling your consumer to an implementation detail of the producer which it shouldn't care about. On the other hand, if your API is such that these interfaces really should be published and consumed as a unit, then maybe you should just merge them into one interface, or declare a new Interface3 that extends both Interface1 and Interface2. Neil _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
