You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Chetan Mehrotra <ch...@gmail.com> on 2014/04/15 06:10:11 UTC
Re: svn commit: r1587286 - in /jackrabbit/oak/trunk: oak-core/pom.xml
oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStoreService.java
oak-parent/pom.xml
Hi Julian,
On Tue, Apr 15, 2014 at 12:39 AM, <re...@apache.org> 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
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
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
3. DocumentNodeStoreService should only have a reference to DataSource
and use that
Chetan Mehrotra
[1] http://docs.oracle.com/javase/7/docs/api/java/sql/DriverManager.html
Re: svn commit: r1587286 - in /jackrabbit/oak/trunk: oak-core/pom.xml
oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStoreService.java
oak-parent/pom.xml
Posted by Chetan Mehrotra <ch...@gmail.com>.
For the record I have implemented a DataSource provider bundle [2]
(based on above flow) as part of SLING-3574. That bundle can be used
to configure a DataSource in OSGi env
Chetan Mehrotra
[1] https://issues.apache.org/jira/browse/SLING-3574
[2] https://github.com/chetanmeh/sling-datasource
On Tue, Apr 15, 2014 at 12:30 PM, Chetan Mehrotra
<ch...@gmail.com> wrote:
>> 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 <ju...@gmx.de> wrote:
>> On 2014-04-15 06:10, Chetan Mehrotra wrote:
>>>
>>> Hi Julian,
>>>
>>> On Tue, Apr 15, 2014 at 12:39 AM, <re...@apache.org> 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
>>
Re: svn commit: r1587286 - in /jackrabbit/oak/trunk: oak-core/pom.xml
oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStoreService.java
oak-parent/pom.xml
Posted by Chetan Mehrotra <ch...@gmail.com>.
> 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 <ju...@gmx.de> wrote:
> On 2014-04-15 06:10, Chetan Mehrotra wrote:
>>
>> Hi Julian,
>>
>> On Tue, Apr 15, 2014 at 12:39 AM, <re...@apache.org> 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
>
Re: svn commit: r1587286 - in /jackrabbit/oak/trunk: oak-core/pom.xml
oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStoreService.java
oak-parent/pom.xml
Posted by Julian Reschke <ju...@gmx.de>.
On 2014-04-15 06:10, Chetan Mehrotra wrote:
> Hi Julian,
>
> On Tue, Apr 15, 2014 at 12:39 AM, <re...@apache.org> 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