Java Reference
In-Depth Information
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:
osgi:service/jdbc/fancyfoodsdb
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:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Fancy Foods Datasource
Bundle-SymbolicName: fancyfoods.datasource
Bundle-Version: 1.0.0
Import-Package: javax.sql,
org.apache.derby.jdbc
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
