OSGi and Spring - Spring Enterprise Recipes: A Problem Solution Approach - page 438

Exploring the Spring Dynamic Modules application context ( src/main/resources/META-INF/
spring/bundle-context-osgi.xml ), we see little that's different or unusual, except an osgi namespace.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=" http://www.springframework.org/schema/beans"
xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"
xmlns:osgi=" http://www.springframework.org/schema/osgi"
xsi:schemaLocation=" http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/osgi
http://www.springframework.org/schema/osgi/spring-osgi.xsd">

<osgi:reference id="greeterService"
interface="com.apress.springenterpriserecipes.osgi. ➥

helloworld.service.GreeterService"/>

</beans>

Here, we've imported a new namespace, osgi , which enables us to use the osgi:reference element.
The osgi:reference element proxies an OSGi service. The proxy manages awareness of whether the
service has been removed or not. This might happen, for example, if you unload the service to replace
it. If the service is removed and you make a call against the proxy, it will block, waiting for the service
to be reinstalled. This is called damping . Furthermore, the proxy itself can be referenced for standard
dependency injection into other beans. Remember: when we registered the service with OSGi in
the Activator for the greeter service, we passed in an interface as well as the implementation to the
bundleContext.registerService invocation. This interface is what we're using to look up the
service here.
Already, we've reaped the benefits of OSGi and Spring Dynamic Modules. This application is
infinitely more robust because, as a client to a service, it's immune to outages in the service itself and
because any number of other clients can now also use the service in the same way, without loading
duplicate versions of the jar.
In order for this example to run, we need to deploy all the dependencies of the client into Equinox
so that they can be managed. In this case, that implies that we have to install all the bundles for Spring
and all the dependencies that Spring itself has. In order to simplify this process, we'll have Equinox
automatically load the jars at startup. The simplest way to do this is to modify Equinox's config.ini file.
The file will be located under the configuration directory, under the eclipse/plugins folder. The folder
won't be present if you haven't run the console as explained in previous exercises. The configuration
folder is where Equinox keeps state between sessions. Create the file with a text editor. We're going to
reference the jars that are required by this project. In order to obtain those jars using the Maven project,
you can issue mvn dependency:copy-dependencies , which will place the jars in the target/lib folder of
the current project, where you can grab them. I would put them in a folder under the OSGi Equinox
directory so that you may reference them quickly, using relative paths. You can visit the source code for
this topic to see the exact Maven configuration I've used. Now that you've got the jars, modify the
config.ini file and list the jars. My config.ini looks like this:

osgi.bundles=spring/com.springsource.org.aopalliance-1.0.0.jar@start, ➥

spring/com.springsource.org.apache.commons.logging-1.1.1.jar@start, ➥

spring/helloworld-service-1.0-SNAPSHOT.jar@start, ➥

spring/org.osgi.core-1.0.0.jar@start, ➥