Java Reference
In-Depth Information
</service-properties>
</service>
Expose XA bean as
DataSource service
<service
ref="derbyXADataSource"
interface="javax.sql.XADataSource">
<service-properties>
<entry
key="osgi.jndi.service.name"
value="jdbc/xafancyfoodsdb" />
</service-properties>
</service>
Use distinct
JNDI name
</blueprint>
The first thing that's interesting about this Blueprint is that the classes that are being
instantiated for the bean (
B
and
D
) aren't ones from the datasource bundle itself.
This is different from what you were doing in chapter 2, where you were wiring
together your own classes. It turns out the origin of the class doesn't matter at all. As
long as the class can be loaded and has a public constructor, then Blueprint can create
it and set properties on it. Even constructors that take arguments can be accommo-
dated with Blueprint's
<argument>
element.
In this case, the essential property is the name of the physical database. You want
to get up and going quickly, so you'll opt for an in-memory database by prefixing
memory:
to the database name. (It should be obvious that this is great for testing but
not recommended for long-term business use!) For convenience, the datasource
should automatically create the database, which can be achieved by setting the
createDatabase
property
C
.
With those properties set, you'll have good transactional and nontransactional
datasources that come with free autocreated databases. The next step is to make these
datasources available to be connected to.
SERVICES, SERVICE PROPERTIES, AND FILTERS
For this, you'll use another feature of Blueprint: the ability to set
service properties.
Ser-
vice properties are a general
OSG
i concept. When it's registered in the Service Regis-
try, any service can have arbitrary properties set on it. Unlike bean properties, the
service properties aren't for the benefit of the service. In fact, the service doesn't even
get to see them. Instead, the service properties tell the rest of the world a bit more
about the service, so that they can decide between multiple possible matches. See fig-
ure 3.3.
Services can be looked up using the interface name, or extra criteria can be speci-
fied. These extra criteria are set using
OSG
i
service filters
. The filter syntax is based on
LDAP
syntax. It can take a bit of getting used to all the ampersands and parentheses,
but filters are actually straightforward. If you'd like to brush up on the finer points of
filters, we've got more examples in appendix A.
The most important thing to remember about filters is that they're directly related
to service properties; if it can be set using a service property, it can be queried using a
