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

available under all of those interfaces. Note that it's illegal to specify both the interface attribute and
the interfaces attribute: use one or the other.

<?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"
xmlns:context=" http://www.springframework.org/schema/context"
xsi:schemaLocation=" http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans -2.5 .xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context -2.5 .xsd
http://www.springframework.org/schema/osgi
http://www.springframework.org/schema/osgi/spring-osgi.xsd">

<context:annotation-config/>

<bean id="greeterService"
class="com.apress.springenterpriserecipes.osgi.helloworld.service.GreeterServiceImpl"/>

<osgi:service 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>

This is powerful in its own right, but Spring Dynamic Modules can help even more. The service
element supports an auto-export attribute, which starts auto detection of interfaces on the bean and
publishes them under the detected interfaces. There are four options: disabled , interfaces , class-
hierarchy , and all-classes .
The first option, disabled , is the default behavior. It works with whatever interfaces you've
explicitly configured on the bean using the interfaces element or the interface attribute. The second,
interfaces , registers the service using the interfaces implemented by a bean, but not its super classes or
the implementation class. If you want to include all super classes as well as the current implementation
class, use class-hierarchy . If you want everything: super classes, implementation class, as well as all
interfaces on the implementation class, choose all-classes .
Having said this, you should probably stick to explicitly specifying the interfaces of your bean. The
auto detection may overexpose your bean, revealing crucial private implementation knowledge. More to
the point, sometimes it may not expose enough. Perhaps you forgot that the functionality that you're
trying to export is specified on an interface on a super class? Don't risk either, and instead prefer explicit
configuration.