Debugging applications - OSGi in Action - page 276

of the org.foo.hub package that includes a modified Message interface. You may
wonder what this package is doing in your spoke bundle—maybe you're experiment-
ing with a new design, or perhaps it was included by mistake. How it got there isn't
important. What is important is that you have a 2.0 version of org.foo.hub floating
around without a corresponding 2.0 version of the Spoke Service Provider Interface
( SPI ). Let's see how this affects the package wiring.
The hub extender and test bundles still have the original, restricted version range:

Import-Package:
org.foo.hub;version="[1.0,2.0)",
org.foo.hub.api;version="[1.0,2.0)",
org.foo.hub.spi;version="[1.0,2.0)"
They get Spoke and Message from the original API bundle, but your spoke bundle has

Import-Package:
org.foo.hub;version="1.0",
org.foo.hub.spi;version="1.0"
This means it gets the original Spoke interface from the API bundle and the updated
Message from itself. (Remember, the framework always tries to pick the newest version
it can.) Thus the Spoke interface and your implementation see different versions of
the Message interface, which causes the LinkageError in the JVM . Figure 8.12 shows
the mismatched wiring.
You must tell the framework that the various hub packages are related, so it can
stop this mismatch from happening. This is where the missing uses constraints come
in. Edit the chapter08/classloading/org.foo.hub/build.properties file and remove
this line from the bnd instructions:

-nouses: ${no.uses}
Removing this re-enables bnd support for uses constraints. If you run the example
again,

$ ./chapter08/classloading/PICK_EXAMPLE 4

org.foo.hub.spi.Spoke 1.0 org.foo.hub.spi.SpokeImpl

≠

org.foo.hub.Message 1.0 org.foo.hub.Message 2.0

Hub
extender

Hub
API/SPI

Spoke

org.foo.hub.spi 1.0 org.foo.hub.spi 1.0

org.foo.hub 1.0

org.foo.hub 2.0

Figure 8.12 Mismatched wiring due to missing uses constraints