Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Equinox » OSGi services:: version resolving issues
OSGi services:: version resolving issues [message #509770] Mon, 25 January 2010 06:02 Go to next message
thomas menzel is currently offline thomas menzel
Messages: 81
Registered: July 2009
Member
hi,

i have another question in regard to OSGi and services.

we all know how OSGi supports side by side deployment of the same bundle at diff. versions and how they are resolved when there are dependencies via require bundle or import statements in the manifest.mf.

the question in this thread is: how to deal with it in the presence of OSGi services?

i havent tried this out myself but the question popped into my head when i couldnt sleep and i need to get it off my chest.

suppose we have a bundle B at version 1.0.0 that exports a (declartive) service. now a later version of this bundle is installed which does exactly the same, except with version 1.2.0.

now, lets us also assume there is a bundle C that consumes the service and gets it via its interface name, e.g.
org.osgi.framework.BundleContext.getServiceReference("org.osgi.service.question.bundle.b.ServiceInterface")
.
the manifest of C constraints the version of bundle B to 1.0.0 and disregards version 1.2.0.

having looked/debugged recently some code of the equinox SCR i noticed that this lookup by typename is facilitated by a Map<String, service reference> where the string is the class name.

what i suppose happens is this:
both service references are in the registry and depending on their rank-value one of them gets returned. if i'm lucky this is the service ref. of bundle B @1.0.0 and all is fine.
if i'm not lucky, this is the service reference of version 1.2.0 and i get a class cast exception, b/c bundle C doesnt have bundle B @1.2.0 on its class path and even though the types are the same their classloaders are different.

the question i have:
a) is there some similar mechanism for getting services from the registry already supported by equinox but not part of the standard that honors somehow the version constraints or takes them into account
b) how to solve this concern otherwise.

one solution for b)
i suppose one way of doing this is to put the bundle version # as one of the service properties into the registry and use a filter when requesting the service.
having not worked much with those filters, i wonder if it is possible to have a custom impl. thoat would do an OSGi-style version comparison in respect to a given version string. e.g.

filter: bundle.version=0.0.0 -> get any version
filter: bundle.version=[1.0.0, 2.0.0) -> get any version between 1.0.0 and 2.0.0 excluding the upper bound


thomas menzel aka tom
Re: OSGi services:: version resolving issues [message #509827 is a reply to message #509770] Mon, 25 January 2010 09:38 Go to previous message
Thomas Watson is currently offline Thomas Watson
Messages: 419
Registered: July 2009
Senior Member
If bundle B v1.0 and bundle B v1.1 both export the same package (org.osgi.service.question.bundle.b) then the service implementations registered by bundles B v1.0 and B v1.1 will be using a different class space for the service implementation. You already explained how this would cause a cast exception if a client bundle was wired to one version of the package (from B v1.0) but got the service implementation from another bundle (B v1.1).

Fortunately for you the framework does this detection for you and will check which version of the package (org.osgi.service.question.bundle.b) bundle C is wired. Depending on which version (1.0 or 1.1) the framework will only return ServiceReference objects which should ensure a safe casting.

HTH

Tom.
Previous Topic:declarative services and junit tests :: how do i stall test execution till SCR has finished
Next Topic:P2 updates for Eclipse RCP applications
Goto Forum:
  


Current Time: Fri Jul 25 07:37:27 EDT 2014

Powered by FUDForum. Page generated in 0.01391 seconds