commit | d14019e300d69315c4f4c44a7ecd3f662efc62c6 | [log] [tgz] |
---|---|---|
author | Chetan Mehrotra <chetanm@apache.org> | Thu Jan 15 11:19:51 2015 +0000 |
committer | Chetan Mehrotra <chetanm@apache.org> | Thu Jan 15 11:19:51 2015 +0000 |
tree | d6c07a785bbe0b82ffdb48b7316a42513df3159c | |
parent | c94d00e9ce7ba066c4fe032b186449ccc233c74d [diff] |
SLING-4147 - Remove extensions from package name org.apache.sling.extensions.datasource.internal -- Dropping the coverage profile as parent pom has explicit support for that -- Reverting the version to 0.0.1-SNAPSHOT so at to attempt release again git-svn-id: https://svn.apache.org/repos/asf/sling/trunk@1652062 13f79535-47bb-0310-9956-ffa450edef68
DataSource provider bundle supports two type of DataSource
This bundle enables creating and configuring JDBC DataSource in OSGi environment based on OSGi configuration. It uses Tomcat JDBC Pool as the JDBC Connection Pool provider.
Loading of JDBC driver is tricky on OSGi env. Mostly one has to attach the Driver bundle as a fragment bundle to the code which creates the JDBC Connection.
With JDBC 4 onwards the Driver class can be loaded via Java SE Service Provider mechanism (SPM) JDBC 4.0 drivers must include the file META-INF/services/java.sql.Driver. This file contains the name of the JDBC driver's implementation of java.sql.Driver. For example, to load the JDBC driver to connect to a Apache Derby database, the META-INF/services/java.sql.Driver file would contain the following entry:
org.apache.derby.jdbc.EmbeddedDriver
Sling DataSource Provider bundles maintains a DriverRegistry
which contains mapping of Driver bundle to Driver class supported by it. With this feature there is no need to wrap the Driver bundle as fragment to DataSource provider bundle
org.apache.sling.datasource.DataSourceFactory
If Felix WebConsole is used then you can configure it via Configuration UI at http://localhost:8080/system/console/configMgr/org.apache.sling.datasource.DataSourceFactory
Using the config ui above one can directly configure most of the properties as explained in Tomcat Docs
Most of the JDBC driver jars have the required OSGi headers and can be directly deployed to OSGi container as bundles. However some of the drivers e.g. Postgres are not having such headers and hence need to be converted to OSGi bundles. For them we can use the Bnd Wrap command.
For example to convert the Postgres driver jar follow the steps below
$ wget https://github.com/bndtools/bnd/releases/download/2.3.0.REL/biz.aQute.bnd-2.3.0.jar -O bnd.jar $ wget http://jdbc.postgresql.org/download/postgresql-9.3-1101.jdbc41.jar $ cat > bnd.bnd <<EOT Bundle-Version: 9.3.1101 Bundle-SymbolicName: org.postgresql Export-Package: org.postgresql Include-Resource: @postgresql-9.3-1101.jdbc41.jar EOT $ java -jar bnd.jar bnd.bnd
In the steps above we
org.postgresql-9.3.1101.jar
While running in Application Server the DataSource instance might be managed by app server and registered with JNDI. To enable lookup of DataSource instance from JNDI you can configure JNDIDataSourceFactory
org.apache.sling.datasource.JNDIDataSourceFactory
If Felix WebConsole is used then you can configure it via Configuration UI at http://localhost:8080/system/console/configMgr/org.apache.sling.datasource.JNDIDataSourceFactory
Once configured JNDIDataSourceFactory
would lookup the DataSource instance and register it with OSGi ServiceRegistry
Once the required configuration is done the DataSource
would be registered as part of the OSGi Service Registry The service is registered with service property datasource.name
whose value is the name of datasource provided in OSGi config.
Following snippet demonstrates accessing the DataSource named foo
via DS annotation
import javax.sql.DataSource; import org.apache.felix.scr.annotations.Reference; public class DSExample { @Reference(target = "(&(objectclass=javax.sql.DataSource)(datasource.name=foo))") private DataSource dataSource; }