Hello, OSGi, Part 2: Introduction to Spring Dynamic Modules

Build a service-oriented application using Spring and OSGi

1 2 3 4 5 6 7 Page 7
Page 7 of 7

Using a Spring DataSource

One of the strengths of the Spring framework is that it provides a set of readymade beans for handling common requirements. In this last section you'll learn how Spring DM allows you to access these readymade beans in your OSGI-based applications.

In this exercise, we'll change the ContactDAO bundle so that it connects to an RDBMS to interact with a contact table. We'll use the Spring DataSource (org.springframework.jdbc.datasource.DriverManagerDataSource) class for connection management. Note that Spring's DataSource is part of the org.springframework.bundle.spring.jdbc service bundle. I've used Apache Derby to test the application code for this exercise; you can use the database of your choice.

The first step in the exercise is to create a contact table in your database. You can use the DDL script in Listing 11 to create the CONTACT table.

Listing 11. DDL for the CONTACT table

   FIRSTNAME varchar(300),
   LASTNAME varchar(300)

We want to use Spring's DriverManagerDataSource bean for connection management. The problem is, the DriverManagerDataSource class is part of the spring.jdbc bundle, which needs to access your JDBC driver class in order to do its work. The easiest way to resolve the dependency is to import your JDBC driver JAR into the spring.jdbc bundle.

The first step, then, is to right-click on the org.springframework.bundle.spring.jdbc bundle and then click New --> Folder. Name this folder "JARs folder."

Next, right-click on the newly created JARs folder and click Import --> General --> File System. Under From Directory, the File System dialog should show the location of the directory that contains your JDBC driver JAR. In my case, the location is C:\software\db-derby-\lib. Select the location and it will display a list of JARs in the Select box. Select derbyclient.jar (assuming you are using Derby) and click Finish. Eclipse will import derbyclient.jar to your JARs folder.

The last step in importing the JDBC driver JAR is to add it in your bundle classpath. In order to do that, open the MANIFEST.MF file for the org.springframework.bundle.spring.jdbc bundle in the Plug-in Manifest Editor. Then go to the Runtimes tab and select jars/derbyclient.jar, as shown in Figure 3.

Adding derbyclient.jar to the bundle classpath.
Figure 3. Adding derbyclient.jar to the bundle classpath (click to enlarge)

(If you prefer you can manually update the bundle-classpath entry to: Bundle-ClassPath: spring-jdbc-2.5.jar, jars/derbyclient.jar.)

Now, we're ready to change the implementation of the ContactDAOImpl class by adding JDBC code to interact with the CONTACT table. If you want, you can import the ContactDAOImpl.java from the sample code for this article; or just take what you see in Listing 12.

Listing 12. ContactDAO implementation for RDBMS access - ContactDAOImpl.java

public class ContactDAOImpl implements ContactDAO {
    DataSource dataSource;
    public DataSource getDataSource() {
        return dataSource;
    public void setDataSource(DataSource dataSource) {
        this.dataSource = dataSource;
        public List getContactList() {
            List contactList = new ArrayList();
            try {
                Connection connection = dataSource.getConnection();
                Statement stmt= connection.createStatement();
                ResultSet rs =stmt.executeQuery("SELECT * FROM CONTACT");
                    int contactId = rs.getInt("CONTACTID");
                    String firstName = rs.getString("FIRSTNAME");
                    String lastName = rs.getString("LASTNAME");
                    Contact contact = new Contact(contactId,firstName,lastName);
            } catch (SQLException e) {
            return contactList;

You'll note a couple of changes to ContactDAOImpl.java in Listing 12:

  • First we've added dataSource as a Java bean property with corresponding getters and setters. The Spring framework will take care of creating a DataSource object and injecting it into ContactDAOImpl.
  • The getContactList() method gets connection from the datasource, then uses it to retrieve all the contact records from the CONTACT table. Note that Listing 12 is a partial listing of ContactDAOImpl.java; see the sample code for complete listing.

With the ContactDAOImpl bean ready, the last thing we need to do is change the contactdao-service.xml in the ContactDAO bundle, as shown in Listing 13:

Listing 13. Updating the Spring context file - contactdao-service.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean name="contactDAOService"
        <property name="dataSource"  >
            <ref bean="dataSource" />
    <bean name="dataSource"
        <property name="driverClassName"
            value="org.apache.derby.jdbc.ClientDriver" />
        <property name="url"
            value="jdbc:derby://localhost:1527/C:/derby_home/databases/ClientDB" />
        <property name="username" value="test" />
        <property name="password" value="test" />

Changes to contactdao-service.xml are as follows:

  • We've declared a dataSource bean pointing to org.springframework.jdbc.datasource.DriverManagerDataSource. This configures Spring to take care of database connection management for the application. (Be sure to use JDBC properties specific to your database in your own bean definition.)
  • Next, we've changed the definition of the contactDAOService bean to add a dependency to the dataSource bean.

With this the Spring DM-built HelloWorld service application is ready to go. When you execute the application in your Equinox container, it will print a list of contacts on the console at the time of application startup.

In conclusion

The OSGi specification introduces modularity and a dynamic service model to Spring application development. For developers already familiar with Spring programming and configuration, Spring DM presents an easier entry point to OSGi's dynamic, modular development specification, without having to learn the OSGi API. As you've seen in this article, Spring DM is an excellent platform for service-oriented application development in an OSGi container. Application modules written using Spring DM can be dynamically added, removed, and updated in a running system, and you can also deploy multiple versions of a given module simultaneously.

The final article in this series will be a hands-on introduction to modular, server-side Java development with OSGi. You'll learn the process of building pluggable, compenentized Web applications in an OSGi container, and also have the opportunity to explore servlet-container options for deploying your applications once they're built.

Learn more about this topic

Technology downloads


This story, "Hello, OSGi, Part 2: Introduction to Spring Dynamic Modules" was originally published by JavaWorld.

Copyright © 2008 IDG Communications, Inc.

1 2 3 4 5 6 7 Page 7
Page 7 of 7