The way I look at it, OSGi already provides Service instance versioning out of the box. Unfortunately it is not clear form the spec, nor it is named 'version'. What I am talking about is Service 'ranking' attribute which you can use to deploy a service. For example: I can have Foo interface exported by Bundle A v1 (btw, I honestly don't treat bundle/package version as Service version... it is just a service definition version.. a strategy if you wish) Then i can have Bundle B v1 providing implementation of Foo and exporting it as an OSGi Service with ranking attribute 1 I can also have Bundle B v2 which provides a different (upgraded if you wish) implementation of Foo and exporting it as an OSGi Service with ranking attribute 2
Requesting a service Foo from OSGi service registry will give you the highest ranking one or you can specify ranking as a filter. You can also export service with a custom property called 'version' and filter on that when consuming such service etc... So I guess I agree that OSGi already provides everything that is needed to version Service instances. Regards Oleg On Dec 30, 2009, at 1:06 PM, Tommy M. McGuire wrote: > > Neil Bartlett wrote: >> Craig, >> >> Can you describe in more detail your use-cases for versioning of >> services, and why you feel they are not well supported at present? >> >> A service is versioned according to the exported package containing >> its interface. If you have services published under the >> org.example.api.IService interface, then you can version them by >> exporting different versions of the org.example.api package from >> different bundles. This allows for API evolution to occur while >> ensuring that clients get objects that are compatible with their >> expectations. There is no need to add versioning to service instances >> because clients should not be aware of the implementation class. >> >> Regards, >> Neil >> >> >> On Wed, Dec 30, 2009 at 3:12 PM, Craig Phillips >> <[email protected]> wrote: >>> I also separate API from IMPL, something I don't see happening officially; >>> Meaning, API bundles are their own separate entity with no service(s) >>> exposed; Speaking of which, where is versioning of services? I end up >>> having to put a version moniker in the service name to cover for this >>> deficiency in the spec [...] > > I cannot speak for Craig, but it sounds like he has the same issue I ran > across: deploying an updated service implementation bundle using the same API > bundle in the case where the API does not change. > > Once it was pointed out to me, the reason for not having a "version" on a > service made sense. I eventually decided to encode the implementation bundle's > minor and micro version numbers in the service ranking to avoid having to set > the ranking manually and to enforce a preference for the updated service. > > -- > Tommy M. McGuire > [email protected] > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
