On Apr 18, 2008, at 4:59 , Niclas Hedhman wrote:
A: Export-Package : foo;version=1.1
D: Export-Package : foo;version=1.2
C: Import-Package: foo, bar
B: Import-Package: foo;version=[1.1,1.1]
Export-Package: bar
Now, foo for B will be resolved to A, and foo for C resolved to D.
A: Export-Package : foo;version=1.1
D: Export-Package : foo;version=1.2
C: Import-Package: foo, bar
B: Import-Package: foo;version=[1.1,1.1]
Export-Package: bar; uses:=foo
Now, foo for B will be resolved to A, and foo for C resolved to A.
True. In the first case, C will be resolved to D because it provides
the highest version of foo; this is due to the algorithm used for
resolving packages, it's somewhere in the spec.
For some extra idea of 'what is it good for', consider a situation in
which package foo contains some interface Foo, and that for versions
1.1 and 1.2 they are different (they don't need to be, but for the
sake of argument, assume they are).
Now, let's say that bundle B publishes a service of its bar, and C
uses this (the imports are already correct for this). If package bar
would contain some interface Bar which has a method
Foo getFoo();
we see the need for uses constraints: in the first situation above,
this getFoo() would return a foo from package 1.1, but C assumes it
to be from package 1.2; hence, a classcastexception on assignment.
This would even happen if the interfaces were identical, since they
come from different classloaders; 1.1 comes from A, 1.2. comes from D.
This mechanism works through on the service level. Let's say A, D and
B all provide a service of Foo, using the package they are wired to.
In bundle C, we can ask for (service) instances of Foo using
getServiceReference(...); to prevent aforementioned
classcastexceptions, the framework will already filter on 'stuff you
can use or not' (that is, you only see instances which are assignment
compatible to the definition you have).
With the first manifest above, only the Foo published by D would be
visible. With the second manifest, the services from B and A will be
visible.
If necessary, you can get all service references for the class with a
given name using getAllServiceReferences(...) .
Hope this helps (in stead of confuses :) )
Angelo
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
