There are frequently situations where OSGi will return more than one instance of a service that satisfies
the interface, especially if you aren't able to specify which one you're looking for using the methods
discussed before. Take, for example, a deployment where you have multiple GreeterService s deployed
for various regions. Spring Dynamic Modules provides the set and list interfaces to retrieve multiple
references and populate a java.util.Set and java.util.List , respectively.
Note the cardinality element, which stipulates how many instances are expected. 0..N stipulates
that any number of references are expected. 1..N stipulates that at least one instance is expected. On a
single reference element, only two values for cardinality are acceptable: 0..1 , and 1..1 . This has the
effect of saying that fulfillment of the dependency for a reference is not mandatory ( 0..1 ) or that it's
mandatory ( 1..1 ).
You may fine-tune the collections returned to you. For example, you might specify a comparator
element or attribute to sort the collection returned. The bean you reference should implement
java.util.Comparator . Unless this logic is extraordinarily involved, it might be an ideal place for using
Spring's scripting support to inline the java.util.Comparator implementation in the Spring application-
context XML file.
cardinality="1..N" comparator-ref="comparatorReference" />
12-5. Publishing a Service Under Multiple Interfaces
Your bean implements many interfaces and you want those interfaces to be visible to clients of
Spring Dynamic Modules supports registering beans under multiple interfaces. It also provides extra
flexibility in auto-detecting the interfaces.
Spring Dynamic Modules creates a proxy for you based on the interface you specify. A side effect is
that the other interfaces your bean implements won't be visible. To be able to access a bean by other
interfaces, you may enumerate the other interfaces in the bean's registration, which will make it