That's a slightly long-winded way of getting hold of a datasource from JNDI . It's too
long to fit on a single line in this topic, in fact! Enterprise OSG i gives you the tools to
do better than that. The osgi.jndi.service.name property is a special property that
tells the container to register the service in JNDI under that name. You can shorten
the JNDI name to just the namespace and the name you provided:
NOTE: APACHE ARIES LIMITATIONS For Apache Aries transactions wrappers
bundle versions 0.3 and below, the short-form JNDI lookup won't work, and
the long-form lookup should be used instead.
The osgi.jndi.service.name property works in both directions. Objects registered
in JNDI can be looked up as OSG i services using their interface name. As part of the
conversion, the container will set the osgi.jndi.service.name to the object's origi-
nal JNDI name.
THE DATASOURCE MANIFEST
Before the datasource can be deployed as an OSG i bundle, it will also need a manifest.
The manifest defines the bundle symbolic name, and it will also need to import some
packages. But wait—why does a bundle with no source code need to import packages?
Just because the bundle doesn't have any class files doesn't mean it's not doing
anything. The datasource bundle does a great deal, but does it declaratively with Blue-
print metadata. In this example, the Blueprint file refers to classes and interfaces in
the javax.sql and org.apache.derby.jdbc packages. These classes will be instanti-
ated by the Blueprint container on behalf of the bundle.
Think for a moment about what would happen if you tried to start the datasource
bundle in an environment where nothing provided the javax.sql or
org.apache.derby.jdbc packages. When the Blueprint container tried to instantiate
the EmbeddedDataSource class it would fail horribly with a ClassNotFoundException .
Not good. OSG i is all about avoiding these unpleasant runtime surprises by declaring
dependencies up front.
With those dependencies, the manifest is as follows:
Bundle-Name: Fancy Foods Datasource
CONFIRMING YOU HAVE A DATASOURCE—OR THREE
Build your JAR and drop it into the load directory. When you list the bundles with ss , you
should see your datasource bundle. If you get the bundle details with the bundle com-
mand, you'll see that your bundle is providing several datasource services (figure 3.4).
Not only do you have the two datasource services you registered, the container has
helpfully provided you with a third. The third service implements the DataSource