> Register a DataSource where? DataSource would be registered with OSGi ServiceRegistery
> Does this work in an OSGi context? Yes it should work in OSGi context. Would try to implement the approach by end of week if time permits > How does it get the DataSource? Per JNDI? The DataSource would be obtained from OSGi service registry just like it currently obtains the BlobStore instance Chetan Mehrotra On Tue, Apr 15, 2014 at 12:00 PM, Julian Reschke <[email protected]> wrote: > On 2014-04-15 06:10, Chetan Mehrotra wrote: >> >> Hi Julian, >> >> On Tue, Apr 15, 2014 at 12:39 AM, <[email protected]> wrote: >>> >>> - >>> <Embed-Dependency>commons-dbcp,commons-pool,h2,json-simple</Embed-Dependency> >>> + >>> <Embed-Dependency>commons-dbcp,commons-pool,h2,json-simple,postgresql,db2,db2-license</Embed-Dependency> >>> <Embed-Transitive>true</Embed-Transitive> >> >> >> I believe this is a temporary change and would not be required for >> final implementation? Would be helpful if we add a TODO/FIXME there >> such that we remember to remove this later > > > OK. > > >> Instead of embedding all such types of drivers/dbcp/pool etc within >> oak-core it would be better to decouple them. For example one approach >> can be >> >> 1. Have a bundle which embeds common-dbcp and required dependencies. >> It would be responsible for registering a DataSource > > > Register a DataSource where? > > >> 2. Driver bundle would be fragments to the bundle #1 as host. With >> JDBC 4.0 the Driver classes are provided as part of >> META-INF/services/java.sql.Driver [1]. For such cases fragment bundles >> can be avoided by having #1 monitor for such drivers and register them >> programatically > > > Does this work in an OSGi context? > > >> 3. DocumentNodeStoreService should only have a reference to DataSource >> and use that > > > How does it get the DataSource? Per JNDI? > > Best regards, Julian >
