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

<context:annotation-config/>

<osgi:service auto-export="all-classes" ref="greeterService">
<osgi:interfaces>
<value>com.apress.springenterpriserecipes.osgi.

➥

helloworld.service.GreeterService</value>

<value>com.apress.springenterpriserecipes.osgi. ➥

helloworld.service.GreetingRecorderService</value>
</osgi:interfaces>
</osgi:service>

</beans>

You can abbreviate the syntax by using an anonymous bean. An anonymous bean specified inside
of the osgi:service element allows you to avoid cluttering the namespace. The previoussalient pieces,
slightly changed to use an anonymous bean, look like this:

<osgi:service interface="com.apress.springenterpriserecipes. ➥

osgi.helloworld.service.GreeterService">
<bean class="com.apress.springenterpriserecipes.osgi.helloworld. ➥

service.GreeterServiceImpl"/>
</osgi:service>

Remember, as these beans are proxies, some may load asynchronously, or take a longer time to
register. This implies that you may have timing issues to resolve in configuring your service. For this,
Spring Dynamic Modules provides the depends-on attribute, which lets your bean wait for another bean.
Suppose our greeterService depended on a dictionaryService , which itself took a long time to load:

<osgi:service depends-on="dictionaryService"
interface="com.apress.springenterpriserecipes.osgi.helloworld. ➥
service.GreeterService">
<bean class="com.apress.springenterpriserecipes.osgi.helloworld.

➥

service.GreeterServiceImpl"/>
</osgi:service>

Interfacing With the OSGi Runtime
You can interact with the OSGi infrastructure in some interesting, more metaprogramming-oriented
ways. Spring surfaces a lot of this functionality if you want to use it. The first, most direct connection
to OSGi is the bean that's created on your behalf when you export a service. This bean, an instance of
org.osgi.framework.ServiceRegistration , is in turn a delegate to the Spring bean you have defined. You
can inject this instance if you want and manipulate it, just as with any other Spring bean. Define an id on
the osgi:service element to be able to reference it.
By default, beans created in a Spring application context are global to the entire OSGi runtime,
including all clients that use it. Sometimes you may want to limit the visibility of a service so that
multiple clients each get their own instance of the bean. Spring Dynamic Modules provides a clever use
of the scope attribute here, allowing you to limit beans exported as services to the client, or service
importer.