Figure 3.3 Properties can be set for both beans and services using Blueprint. Bean properties are used
by the bean's business logic. Service properties are invisible to the object implementing the service, but
they're visible to consumers of the service.
filter. This means service lookups can be general—“give me anything that implements
this interface”—or very, very specific—“give me a service with this interface that also
has this property set to that value but also doesn't have this other property set to some
How does that relate to datasources? In section 2.4, we explained how our Aries
stack helpfully publishes services to JNDI . Like a web container, most JPA implementa-
tions weren't originally written with enterprise OSG i in mind, and they rely on JNDI to
find their datasources. Luckily, any Blueprint service can be looked up in JNDI . The
lookup name is the interface implemented by the service, javax.sql.DataSource in
this case. Anything can look up the datasource for your fancyfoodsdb database using
the JNDI name osgi:service/javax.sql.DataSource .
This works nearly perfectly. JPA can be pointed to the JNDI name for the datasource,
and it can look it up and use it as intended. The problems happen when the server has
more than one datasource. Which one is returned from a service lookup of the
javax.sql.DataSource interface? Well, it depends, but it's probably not the one you
were hoping for. Because each datasource is closely associated with a particular data-
base, a datasource isn't the sort of service where any arbitrary implementation will do!
This is where service properties and filters come to the rescue. Service properties
can be added to the service, and then any JNDI lookup can filter on those properties.
In listing 3.1 you specified a service property for the datasource:
This service can be looked up from JNDI using the following name:
Specify the osgi:service namespace, and then the interface name, and then you can
add on any filters you like.
Search WWH ::