Niclas Hedhman <[EMAIL PROTECTED]> writes:

> I would.

I have Maven module in my project called "embedded-persistence." In
its POM, we reference the aforementioned JDBC driver, which I've
deployed to my local repository for reference as follows:

    <dependency>
      <groupId>org.sqlite.jdbc</groupId>
      <artifactId>pure-driver</artifactId>
      <version>3.3.0</version>
    </dependency>

Note that the JDBC driver project doesn't use Maven at present, so I
took the pre-built "pure" (as opposed to "native") JAR and gave it a
suitable name and version above.

In my Maven bundle plugin configuration, I had to accommodate a
package referenced somehow by the SQLite driver, but apparently never
used at runtime. It seems to be an artifact of the way the driver gets
built:

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
        <extensions>true</extensions>
        <configuration>
          <instructions>
            <!-- This one is discovered in the SQLite "pure" driver, but not 
needed: -->
            <Import-Package>!org.ibex.classgen,*</Import-Package>
            <Private-Package><!-- The SQLite JDBC driver: -->
                             org.sqlite.*,
                             org.ibex.nestedvm.*</Private-Package>
          </instructions>
        </configuration>
      </plugin>
    </plugins>
  </build>

Per the discussion here,

  http://groups.google.com/group/sqlitejdbc/browse_frm/thread/56d4de4a2e3bffec

I wrote a similar implementation of javax.sql.DataSource that calls
on java.sql.DriverManager to get connections from the SQLite JDBC
driver. This class is not to interesting; all I added to the example
code was a way to set the "databaseName" property and make suitable
JDBC URLs from it.

I implemented the ManagedServiceFactory in two parts: a base
AbstractManagedServiceFactory class and a derived
SQLiteDataSourceFactory that provides the parts specific to creating a
configuring the actual service instance. I'm still not sure I'm happy
with the abstract-base/concrete-derived relationship between these two
classes; this week I may change things so that the
ManagedServiceFactory holds a reference to an interface implementation
of the parts currently delegated to the derived class.

The AbstractManagedServiceFactory (with a generic type parameter
"Impl") delegates the following methods to a derived class:

   protected abstract Impl createService(Dictionary<String, Object> 
configProperties)
         throws org.osgi.service.cm.ConfigurationException;


   protected abstract void reconfigureServiceImplementation(Impl impl, 
Dictionary<String, Object> configProperties)
         throws ConfigurationException;


   protected Dictionary<String, Object> 
provideServiceProperties(Dictionary<String, Object> configProperties) {
      return null;
   }


AbstractManagedServiceFactory has nothing to do with SQLite; it just
takes care of the workflow of receiving updated() and deleted() calls
from the CM service, figuring out when it's a new versus existing
configuration, and helping to filter the configuration properties for
optional republication as service properties.

The SQLiteDataSourceFactory part is concerned with retrieving the
"database.name" configuration property, creating instances of
SQLiteDataSource and setting the database name appropriately, and
adding some service properties for publication.

If that's not the sort of stuff you wanted to hear about, let me know
what other aspects you'd like to me to detail here.

-- 
Steven E. Harris
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev

Reply via email to