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 Francesco Mari <ma...@gmail.com> on 2015/06/29 11:22:02 UTC
OSGi configuration lookup
Hi all,
I'm developing a fix for OAK-3022 reusing the code written for OAK-2962.
I figured out that there is a mismatch in how SegmentNodeStoreService
and DocumentNodeStoreService read configuration values. The
SegmentNodeStoreService reads from the component context first, and
from the bundle context next. The DocumentNodeStoreService, instead,
does the opposite.
Is it possible - or does it make sense - to make this behaviour
uniform across components?
Thanks,
Francesco
Re: OSGi configuration lookup
Posted by Francesco Mari <ma...@gmail.com>.
Hi all,
I would like to complete a patch for OAK-3022, but my work depends on
the patch I submitted for OAK-3048. Can somebody review OAK-3048?
Thanks,
Francesco
2015-06-30 9:45 GMT+02:00 Bertrand Delacretaz <bd...@apache.org>:
> On Tue, Jun 30, 2015 at 5:52 AM, Chetan Mehrotra
> <ch...@gmail.com> wrote:
>> ...if we need to do that for
>> Segment also then we should use a similar namespacing...
>
> And that should IMO be done with a utility class instead of duplicating code.
>
> -Bertrand
Re: OSGi configuration lookup
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Jun 30, 2015 at 5:52 AM, Chetan Mehrotra
<ch...@gmail.com> wrote:
> ...if we need to do that for
> Segment also then we should use a similar namespacing...
And that should IMO be done with a utility class instead of duplicating code.
-Bertrand
Re: OSGi configuration lookup
Posted by Francesco Mari <ma...@gmail.com>.
I attached a patch in OAK-3048. Can someone review?
2015-06-30 9:02 GMT+02:00 Francesco Mari <ma...@gmail.com>:
> I created OAK-3048 to track the implementation of the
> framework-first-component-next strategy. I will attach a patch to this
> issue shortly. I also opened OAK-3049 as a reminder to address the
> uniformity issue when reading configuration.
>
> 2015-06-30 8:35 GMT+02:00 Chetan Mehrotra <ch...@gmail.com>:
>> On Tue, Jun 30, 2015 at 12:00 PM, Francesco Mari
>> <ma...@gmail.com> wrote:
>>> I suggest to fix OAK-3022 maintaining exactly
>>> the same behaviour, and without changing the SegmentNodeStoreService
>>
>> Makes sense. They are two different issue
>>
>> Chetan Mehrotra
Re: OSGi configuration lookup
Posted by Francesco Mari <ma...@gmail.com>.
I created OAK-3048 to track the implementation of the
framework-first-component-next strategy. I will attach a patch to this
issue shortly. I also opened OAK-3049 as a reminder to address the
uniformity issue when reading configuration.
2015-06-30 8:35 GMT+02:00 Chetan Mehrotra <ch...@gmail.com>:
> On Tue, Jun 30, 2015 at 12:00 PM, Francesco Mari
> <ma...@gmail.com> wrote:
>> I suggest to fix OAK-3022 maintaining exactly
>> the same behaviour, and without changing the SegmentNodeStoreService
>
> Makes sense. They are two different issue
>
> Chetan Mehrotra
Re: OSGi configuration lookup
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Tue, Jun 30, 2015 at 12:00 PM, Francesco Mari
<ma...@gmail.com> wrote:
> I suggest to fix OAK-3022 maintaining exactly
> the same behaviour, and without changing the SegmentNodeStoreService
Makes sense. They are two different issue
Chetan Mehrotra
Re: OSGi configuration lookup
Posted by Francesco Mari <ma...@gmail.com>.
To keep things simple, I suggest to fix OAK-3022 maintaining exactly
the same behaviour, and without changing the SegmentNodeStoreService.
What do you think if we address the issue about different behaviours
separately?
2015-06-30 5:52 GMT+02:00 Chetan Mehrotra <ch...@gmail.com>:
> That can be done but some more details!
>
> When properties are read from framework properties then property names
> are prefixed with 'oak.documentstore.' kind of like namespaced as
> framework properties are flat and global. So if we need to do that for
> Segment also then we should use a similar namespaceing. For e.g. if
> the property name is 'cache' then when reading from fwk then
> 'oak.documentstore.cache' would be used
>
> oak.mongo.uri and oak.mongo.db are spacial cased though and not follow
> this rule.
> Chetan Mehrotra
>
>
> On Tue, Jun 30, 2015 at 2:55 AM, Francesco Mari
> <ma...@gmail.com> wrote:
>> So we should probably adopt this strategy instead. This means that
>> SegmentNodeStoreService is the one that should be modified.
>>
>> 2015-06-29 17:15 GMT+02:00 Chetan Mehrotra <ch...@gmail.com>:
>>> Looking at code flow now yes it differs. The thought behind reading
>>> from framework property first was to provide a simple way to override
>>> the config which might be packaged by default. For e.g. while
>>> launching Oak via Sling one can provide the framework property at
>>> command line (using -Doak.mongo.uri) which would supercede the one
>>> packaged by default. This simplifies the testing.
>>> Chetan Mehrotra
>>>
>>>
>>> On Mon, Jun 29, 2015 at 7:01 PM, Davide Giannella <da...@apache.org> wrote:
>>>> On 29/06/2015 10:22, Francesco Mari wrote:
>>>>> ...
>>>>>
>>>>> Is it possible - or does it make sense - to make this behaviour
>>>>> uniform across components?
>>>>>
>>>> I think it's a good idea to uniform this aspect. Maybe we could put it
>>>> down as a guideline by setting up a new page on the doc site:
>>>> code-conventions.md. Somewhere beside:
>>>> http://jackrabbit.apache.org/oak/docs/dev_getting_started.html
>>>>
>>>> Personally I'd go for component first and bundle then, but I'm not too
>>>> religious about it :)
>>>>
>>>> Anyone against it?
>>>>
>>>> Davide
>>>>
>>>>
Re: OSGi configuration lookup
Posted by Chetan Mehrotra <ch...@gmail.com>.
That can be done but some more details!
When properties are read from framework properties then property names
are prefixed with 'oak.documentstore.' kind of like namespaced as
framework properties are flat and global. So if we need to do that for
Segment also then we should use a similar namespaceing. For e.g. if
the property name is 'cache' then when reading from fwk then
'oak.documentstore.cache' would be used
oak.mongo.uri and oak.mongo.db are spacial cased though and not follow
this rule.
Chetan Mehrotra
On Tue, Jun 30, 2015 at 2:55 AM, Francesco Mari
<ma...@gmail.com> wrote:
> So we should probably adopt this strategy instead. This means that
> SegmentNodeStoreService is the one that should be modified.
>
> 2015-06-29 17:15 GMT+02:00 Chetan Mehrotra <ch...@gmail.com>:
>> Looking at code flow now yes it differs. The thought behind reading
>> from framework property first was to provide a simple way to override
>> the config which might be packaged by default. For e.g. while
>> launching Oak via Sling one can provide the framework property at
>> command line (using -Doak.mongo.uri) which would supercede the one
>> packaged by default. This simplifies the testing.
>> Chetan Mehrotra
>>
>>
>> On Mon, Jun 29, 2015 at 7:01 PM, Davide Giannella <da...@apache.org> wrote:
>>> On 29/06/2015 10:22, Francesco Mari wrote:
>>>> ...
>>>>
>>>> Is it possible - or does it make sense - to make this behaviour
>>>> uniform across components?
>>>>
>>> I think it's a good idea to uniform this aspect. Maybe we could put it
>>> down as a guideline by setting up a new page on the doc site:
>>> code-conventions.md. Somewhere beside:
>>> http://jackrabbit.apache.org/oak/docs/dev_getting_started.html
>>>
>>> Personally I'd go for component first and bundle then, but I'm not too
>>> religious about it :)
>>>
>>> Anyone against it?
>>>
>>> Davide
>>>
>>>
Re: OSGi configuration lookup
Posted by Francesco Mari <ma...@gmail.com>.
So we should probably adopt this strategy instead. This means that
SegmentNodeStoreService is the one that should be modified.
2015-06-29 17:15 GMT+02:00 Chetan Mehrotra <ch...@gmail.com>:
> Looking at code flow now yes it differs. The thought behind reading
> from framework property first was to provide a simple way to override
> the config which might be packaged by default. For e.g. while
> launching Oak via Sling one can provide the framework property at
> command line (using -Doak.mongo.uri) which would supercede the one
> packaged by default. This simplifies the testing.
> Chetan Mehrotra
>
>
> On Mon, Jun 29, 2015 at 7:01 PM, Davide Giannella <da...@apache.org> wrote:
>> On 29/06/2015 10:22, Francesco Mari wrote:
>>> ...
>>>
>>> Is it possible - or does it make sense - to make this behaviour
>>> uniform across components?
>>>
>> I think it's a good idea to uniform this aspect. Maybe we could put it
>> down as a guideline by setting up a new page on the doc site:
>> code-conventions.md. Somewhere beside:
>> http://jackrabbit.apache.org/oak/docs/dev_getting_started.html
>>
>> Personally I'd go for component first and bundle then, but I'm not too
>> religious about it :)
>>
>> Anyone against it?
>>
>> Davide
>>
>>
Re: OSGi configuration lookup
Posted by Chetan Mehrotra <ch...@gmail.com>.
Looking at code flow now yes it differs. The thought behind reading
from framework property first was to provide a simple way to override
the config which might be packaged by default. For e.g. while
launching Oak via Sling one can provide the framework property at
command line (using -Doak.mongo.uri) which would supercede the one
packaged by default. This simplifies the testing.
Chetan Mehrotra
On Mon, Jun 29, 2015 at 7:01 PM, Davide Giannella <da...@apache.org> wrote:
> On 29/06/2015 10:22, Francesco Mari wrote:
>> ...
>>
>> Is it possible - or does it make sense - to make this behaviour
>> uniform across components?
>>
> I think it's a good idea to uniform this aspect. Maybe we could put it
> down as a guideline by setting up a new page on the doc site:
> code-conventions.md. Somewhere beside:
> http://jackrabbit.apache.org/oak/docs/dev_getting_started.html
>
> Personally I'd go for component first and bundle then, but I'm not too
> religious about it :)
>
> Anyone against it?
>
> Davide
>
>
Re: OSGi configuration lookup
Posted by Davide Giannella <da...@apache.org>.
On 29/06/2015 10:22, Francesco Mari wrote:
> ...
>
> Is it possible - or does it make sense - to make this behaviour
> uniform across components?
>
I think it's a good idea to uniform this aspect. Maybe we could put it
down as a guideline by setting up a new page on the doc site:
code-conventions.md. Somewhere beside:
http://jackrabbit.apache.org/oak/docs/dev_getting_started.html
Personally I'd go for component first and bundle then, but I'm not too
religious about it :)
Anyone against it?
Davide